Since Aldorn asked about this being a possibility / how difficult this would be
in this post, I decided to investigate that for a bit.
Turns out that it wouldn't be all that hard from a coding standpoint.
However, it is a bit more challenging to come up with what values exactly to set in the ruleset, so that we can
a) match exactly the original / current calculation of stat gains.
and
b) give modders all the freedom they need wrt. changing the behavior.
This is what I have come up with for now (feedback appreciated):
statGain:
primary:
bravery:
requirement: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11]
chance: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11]
chanceDivisor: 11
valueMin: 10
valueMax: 10
reactions:
requirement: [1, 3, 6, 11]
valueMin: [0, 1, 1, 2]
valueMax: [1, 3, 4, 6]
firing:
requirement: [1, 3, 6, 11]
valueMin: [0, 1, 1, 2]
valueMax: [1, 3, 4, 6]
throwing:
requirement: [1, 3, 6, 11]
valueMin: [0, 1, 1, 2]
valueMax: [1, 3, 4, 6]
enablesSecondary: false
psiStrength:
requirement: [1, 3, 6, 11]
valueMin: [0, 1, 1, 2]
valueMax: [1, 3, 4, 6]
psiSkill:
requirement: [1, 3, 6, 11]
valueMin: [0, 1, 1, 2]
valueMax: [1, 3, 4, 6]
melee:
requirement: [1, 3, 6, 11]
valueMin: [0, 1, 1, 2]
valueMax: [1, 3, 4, 6]
secondary:
tu:
requirement: [1]
valueMin: 0
valueMax: 2
remainderShareMin: 0
remainderShareMax: 0.1
stamina:
requirement: [1]
valueMin: 0
valueMax: 2
remainderShareMin: 0
remainderShareMax: 0.1
health:
requirement: [1]
valueMin: 0
valueMax: 2
remainderShareMin: 0
remainderShareMax: 0.1
strength:
requirement: [1]
valueMin: 0
valueMax: 2
remainderShareMin: 0
remainderShareMax: 0.1
If I am not mistaken, this set of values should suffice to emulate the original xcom / current
* behavior, while at the same time allowing modders all the freedom with regards to how exactly experience gain translates to stat gain. Note that it is not possible to change WHAT actions cause the experience gain in for one category; that would be a different topic altogether. Only the translation from experience (= successful actions taken) to stat gain is.
* there actually is a slight deviation in current trunk code to what ufopaedia has to say about original xcom calculation.
Code says:
return (int)(tier/2.0 + RNG::generate(0.0, tier));
... where tier can be either of 1.0, 2.0, 3.0, or 4.0. Zhis will result in the following chances:
edit - I missed some facts.. turns out the code is off even more than I thought.
Keep in mind that double->int conversion is rounding DOWN, not rounding to nearest int.tier 1: random between 0.5 and 1.5 -> 50% for each of 0, 1
tier 2: random between 1.0 and 3.0 ->
50% for each of 1, 2tier 3: random between 1.5 and 4.5 ->
1/6 for 1, 2/6 for 2, 2/6 for 3, 1/6 for 4tier 4: random between 2.0 and 6.0 ->
25% for each of 2,3,4,5(note that rounding is done after the random number generation, not to both the min and max value)
I don't know if this is deliberate or an oversight while coding.
It strikes me now that this may also be case in original xcom, just not explained so well in the wiki.
In this case I may revise the ruleset variables for primary stats a bit more...
edit: I once more thought about the code above and think now that it's most definitely a bug.
For example for tier 2 (3-5 successful actions), a random number is generated between 1.0 and 3.0. It is then converted to int (=rounded DOWN), which results in 1 in 50% of the cases and 2 in the other 50%. To be precise there is (maybe) a tiiiiiny tiny chance that the RNG hits
exactly 3.0, but that's near impossible. So this code definitely needs a fix.