[EXE][WIP] OpenXcom Highly Advanced (OXCHA)

[Xtendo-com]

OpenXcom Highly Advanced (OXCHA) based on latest openxcom nightly (commit b7f1b13, May 13, 2016 )

The main purpose of that fork - make as many advanced options for geoscape and battlescape, as possible in order to satisfy the different tastes posted in suggestions.
That fork is not ruleset wise. If you want more rulesets options, try OpenXcom Extended or OpenXcom Extended+ instead. If you want some options merged to their forks, ask authors or merge yourself using a feature branch.

SpoilerAdvanced options implemented by community:

Advanced scanner
Description from game: Locations of enemies, uncovered by motion scanner, will be marked as red boxes on the battlefield.

Aliens shoot blindly
Description from game: Aliens can shoot to spotted x-com operatives without visual contact.

Alternate clip consumption
Description from game: Reduce inefficient calculation of clip consumption after statistic screen if clip is almost full. If that option disabled, clip counts as consumed if there are not enough bullets to fill clip completely.
More details: if you don't understand the short description, open a link higher.

Show blast radius
Description from game: Shows blast radius for every weapon that have a blast radius (grenades, high explosive, rocket launchers, etc).

SpoilerNew advanced options:

Increase survivability of x-com soldiers
Description from game: Healthy soldier with high morale and bravery has a chance to lose consciousness instead of dying after a mortal hit. Soldiers with high bravery are more likely to survive a mortal hit.
More details: In vanilla if HP reaches 0, your soldiers dies. When that option enabled, if HP reaches 0 and less the game calculate a chance to survive by losing consciousness instead and recovers 10% HP from max HP. Chance based on HP overkill, on a morale and bravery.

Extend civilians behaviour
Description from game: Makes civilians more valuable with possibility to save them without stun. Beware, every death of civilians affect a morale and in unconscious state civilian lose pulse and can die.
More details: Completely breaks vanilla behaviour of civilians:

• You can save civilians when you abort missing
• Civilians sit quietly and tries to break line of sight instead of walking around except when they panic
• Civilians can lose a morale. They lose a morale after noticing an enemy at start of civilian's turn, lose a morale after every death of humans.
• You can control civilians manually when x-com operative is nearby (7 tile away)
• Civilians lose less morale under player control
• Civilians under player control never panic when x-com operative is alongside (2 tile away)
• Civilians lose a pulse in unconscious state, so never stun civilians without a special reason
• Changes turn priority to: Player, Civilians, Aliens. So in first turn civilians can break line of sight

No pulse in unconscious state
Description from game: Human lose pulse in unconscious state and lose HP to death. You need to use stimulators from medikit in that case.
More details: That rule applied to x-com operatives and civilians, aliens not affected. Human in unconscious state can't regain consciousness without external help. Stunlevel overdose for humans resets every turn, so you don't need a lot of stimulators (more than 3).

SpoilerSource codes:

OpenXcom Highly advanced (branch: OXCHA)
Advanced scanner (branch: adv_advanced_scanner)
Aliens shoot blindly (branch: adv_aliens_shoots_blindly)
Alternate clip consumption (branch: adv_alternate_clip_consumption)
Extend civilians behaviour (branch: adv_extend_civilians_behaviour)
Increase survivability of x-com soldiers (branch: adv_increase_survivability)
No pulse in unconscious state (branch: adv_unconscious_no_pulse)
Show blast radius (branch: adv_show_blast_radius)

SpoilerUsed source codes & credits:

OpenXcom by SupSuper, Daiky, WarBoy1982, hmaon, Karvanit, l2uriel, volutar and etc.
OpenXcom Extended by Yankes
OpenXcom Extended+ by Meridian
Advanced scanner by redv
Alien Snipers by psyHoTik
Bullet saving patch by Arthanor
Manual control of civilians by yrizoud
Show chance to hitting and the throw trajectory by redv

Links to binary:
Windows binary
Linux binary

[ivandogovich]

Hmmm... from the OP title, I thought you were creating a mod with increased HE damage, rather than just a different port with a compilation of exploratory features.   I'm not sure, but maybe there might be a more accurate name somewhere.

[Xtendo-com]

Hmmm... from the OP title, I thought you were creating a mod with increased HE damage, rather than just a different port with a compilation of exploratory features.   I'm not sure, but maybe there might be a more accurate name somewhere.

Thanks, changed title to more accurate name.

[Xtendo-com]

New Build:
changelog

• Synced code to latest openxcom nightly.
  
• Added "High morale increases survivability". Healthy soldier with high morale have a chance to survive from a mortal hit.
• Fixed "Aliens shoot blindly" when aliens can still shoot blindly to old spotted x-com operatives without scouting.
• "Advanced scanner" don't shows you a floor of scanned unit.

[Arthanor]

Hi! So I'm going through your commits to implement the advanced scanner and I noticed on this commit that there was a line of code related to the autoequip that disappeared in src/Engine/Options.cpp.

I expect that's not intentional?

[Xtendo-com]

I expect that's not intentional?

My mistake, sorry about that.

Also If you want to port advanced scanner to extended, you can watch changelog directory > advanced scanner by redv. I made a list of changed files in readme.txt and a unique comment that allows you to find needed line of code.

--- posts merged - Solarius Scorch ---

I'm thinking about improving ability to easily merge a specific interested advanced option for other developers by reducing a manual works and improving visual diff. Currently you may found a specific advanced option by unique comment in source with included changed file lists in changelog directory but you need to do a lot of manual SEARCH/COMPARE/COPY/PASTE/ actions and also fix conflicts. I want to reduce manual works to minimum so you need to fix only conflicts instead.

I found two ways:
1) Include also a diff patch in changelog directory for every advanced option. Diff made from fresh openxcom nighty.
2) Make new branch from fresh openxcom nighty for every advanced option and use in github site a function to compare branch.

May be openxcom community may offer better ways?

[Arthanor]

I just used git to find all the commits that related to the scanner, and picked the code changes related to that, to see what to implement. It wasn't too hard. Now I just have to figure out if it worked or not

I initially made git patches for it, but the amount of conflicts (language files are different, code version is different because OXCE is pretty far behind by now) was just too much. It was much easier to just reproduce the changes. I think if you could have all your work on one feature be one branch that is then merged in your master (or at least if you want to work directly on your master branch, have all the commits related to a given feature in a row), it would make things easier as we wouldn't have to search in the logs for all the commits, but otherwise it works fine.

[Xtendo-com]

wasn't too hard.

Not many commits, but hundreds of commits will really make it more harder...

have all the commits related to a given feature in a row

How it's really possible without conflicts? For example I decided to fix something related to advanced option feature after hundreds of commits. I can't make this without breaking commit history.

I think with git features that is not possible to do it with convince without making crutches. With git is comfortable to revert change and start new branch, but I didn't notice any features that allows me easily group commits for specific advanced option feature.

[Arthanor]

I think the "proper way" of using git is:

1- create your master branch, with origin/master being the oxc code
2- For every new feature, create a new branch and work exclusively on that feature when on that branch
3- When satisfied with a feature, merge the branch into your master branch. Do not delete the branch
4- When finding a bug in a feature, go back into that feature's branch and fix it, then merge the branch again.

That way, you will always have all the commits of a feature together. This is how some people offer features to openxcom: They make a branch, and then they submit a pull request to the master code.

So if I want one of your features, I can just get the branch on which you developed it and I will get all the work you have done on it. This is far superior to working directly into your master.

It is also the way to work with multiple people on the same code: You all work on a different feature on different branches, and when you think you are done, the code master will merge your branch into the master code, thus adding the new feature. Meanwhile, others who are still working on their feature can keep their branch as is instead of suddenly getting their code updated.

[Xtendo-com]

Arthanor
Thanks! That thing stops for me implementing/porting other advanced options since it's difficult to pickup interesting advanced option. Later I will remake my git fork entirely that will use branch instead of commits with random positions.

[DoxaLogos (JG)]

I think the "proper way" of using git is:

1- create your master branch, with origin/master being the oxc code
2- For every new feature, create a new branch and work exclusively on that feature when on that branch
3- When satisfied with a feature, merge the branch into your master branch. Do not delete the branch
4- When finding a bug in a feature, go back into that feature's branch and fix it, then merge the branch again.

That way, you will always have all the commits of a feature together. This is how some people offer features to openxcom: They make a branch, and then they submit a pull request to the master code.

So if I want one of your features, I can just get the branch on which you developed it and I will get all the work you have done on it. This is far superior to working directly into your master.

It is also the way to work with multiple people on the same code: You all work on a different feature on different branches, and when you think you are done, the code master will merge your branch into the master code, thus adding the new feature. Meanwhile, others who are still working on their feature can keep their branch as is instead of suddenly getting their code updated.

+1 great synopsis of git workflow

[Meridian]

So if I want one of your features, I can just get the branch on which you developed it and I will get all the work you have done on it. This is far superior to working directly into your master.

So much for the theory... with which I 100% agree.

In reality, if you make more than 10 or 20 features, sooner or later they will depend on each other.
If you make more than 100, everything will depend on everything (I'm exaggerating now to make a point).

And I'm not even talking about any refactoring yet... which can break everything.

For example, if you want feature A from my OXCE+ branch, you'll most likely need feature B on which feature A depends; and also feature C, which is required for feature B.

Unless forks are periodically merged (or even better merged with cherry-pick strategy) upstream, they will eventually go their separate ways... rather sooner than later.

One example for illustration: yesterday I implemented a tiny feature (really just a few lines of code) for displaying accuracy and TUs for melee weapons in ufopedia... even such a tiny change cannot be used in OXC "as is", because it depends on (unknown number of) changes in OXCE.

[Arthanor]

Yes, well, maybe I missed one step of #4:

When encountering a bug, go back to that branch, merge master into it to update it with all the new stuff developed until now, then fix the bug and merge the branch back into master.

You might say: But once you merge master into the feature branch, then all the commits are mixed! Yes.. if you type "git log" and no.. if you type other commands (not 100% sure on the command line way) or use GitHub. git remembers which branch the commits were performed on and can list them for you. An example here where redv has multiple commits, including a merge and conflict fixes, which still shows only his commits.

Whenever you want a new feature, you checkout the most up to date version of master, and build your new feature on whatever is in master (including all the features that have been previously merged into it). Granted, if you use code from previous features, it will not be possible to just take that branch and merge it into some other repo that doesn't have the "basis features", but it will still be much easier than if you worked directly on your master since the merger can:

1 - Try to merge your branch
2 - Fail because it depends on another feature
3 - list all changes done to a file in which there is a conflict, to see what else was done
4 - figure out which feature is required and try to merge that (and so on until you reach "basic features" that don't depend on anything)

That's a lot of work, but it more manageable than trying to figure out what is happening when every commit is tagged as being done in master since you have extra information: what branch/feature each commit belongs to and you can approach the problem using branches/features instead of individual commits.

[Xtendo-com]

New version:
changelog
Remade github commits. Now I use one branch for one advanced option. I will try to do my best to group commits related to one feature/issue/fix and etc.
Fixed a bug in advanced scanner that prevents to draw a scan result in lower floors if scanned unit was in higher floor.
"High morale increase survivability" was renamed to "Increase survivability of x-com soldiers"
"Increase survivability of x-com soldiers" don't give you a granted chance to survive a mortal hit anymore even with high morale and health.
"Increase survivability of x-com soldiers" takes into a consideration a bravery stats, so your soldier are more likely to survive with high bravery stats.
"Increase survivability of x-com soldiers" takes into a consideration an overkill damage, so your soldier are less likely to survive with huge overkill.

[Arthanor]

Nifty! I noticed that scanner bug but hadn't gotten around to reporting it. I hadn't realized how it worked and expected it to be because I somehow had LoS to that level. I'm looking forward to the fix.

Great work on the git reorganization too!