Difference between revisions of "User talk:MikeTheRed"

From UFOpaedia
Jump to navigation Jump to search
(→‎Secondary "Steps": added graph and finished discussion)
Line 5: Line 5:
  
 
My observations under [[Experience#How_Experience_Points_Are_Applied|Experience]] are getting incredibly long-winded. And at the same time, I am doing yet <i>more</i> research on it. So I've made this space to put levels of detail that are way more than a casual player is interested in. I will probably move some stuff out of Experience and over to here as I polish the info.
 
My observations under [[Experience#How_Experience_Points_Are_Applied|Experience]] are getting incredibly long-winded. And at the same time, I am doing yet <i>more</i> research on it. So I've made this space to put levels of detail that are way more than a casual player is interested in. I will probably move some stuff out of Experience and over to here as I polish the info.
 +
 +
== My Test Setup ==
 +
 +
For my testing, I have a MS Access VBA module that sucks in a savegame and compares it to another one (from before the combat). I [[HackerTools|edit]] experience counters (offsets 80-85 in [[UNITREF.DAT]]) and soldier stats (bytes 43-62 in [[SOLDIER.DAT]]) from a savegame ready to be ended (a Muton base with 16 soldiers standing in the entry area). Although it took weeks of futzing with Access to get it set up nicely, now that it's done, I can generate each combat-mission skill-point result in as quickly as I can load a savegame, end the mission, and then savegame on the geoscape (approx. 15 seconds). As of this writing, I have 4,544 individual soldier results (a.k.a. 284 savegame results at 16 soldiers each). This was for 11 different configurations of experience counters and soldier stats, as I zeroed in on different questions to ask (an average of about 25 savegames per configuration).
 +
 +
[[Image:XcomPsiLabIncreases.gif|right|Psi Lab end-of-month increases vs. Psi Skill]]FWIW, the [[Psi_Skill#Improvement|Psi Lab training]] tests were way easier than combat-mission experience-vs.-skill-point tests. For three reasons: 1) I only had 16 soldiers in my base combat-mission scenario, whereas I could use all 250 soldiers when testing the Lab. (It took a lot of manual Soldier.Dat hacking, though!) 2) The Psi Lab results were much more simple and clear vs. combat results, as the wiki shows. Finally, 3) only one stat was being looked at, whereas combat results can affect 9 stats, each of which has to be examined in its own way. For the Psi Lab tests, I quickly generated 8,500 datapoints (34 savegames) and within just two different savegame configurations, it's behavior was [[Psi_Skill#Improvement|crystal clear]]. (I didn't include these 8,500 results in the 4,544 counts I mentioned for combat results, of course.)
 +
 +
I'm happy to share my MS Access setup with anybody that wants it; just send [[User:MikeTheRed|me]] an email. But you are warned - it's all home grown code. I'll walk you through it, but you have to do it exactly right... there ain't no user manual or Help routines for this baby! You coders know what I mean. Also, just so you know... the <i>only</i> thing it does relative to game files, is read Soldier.Dat. It doesn't touch any other file, and it doesn't write to anything (except itself, of course). I did all my Soldier and Unitref hacking by hand.
 +
 +
FWIW, at first I used [[HackerTools|Hex Workshop]] to hack Soldier and Unitref (thanks Danial!), but lately I've only been using EDIT... I couldn't figure out a way to make HW "remember" where to place its structure overlays, and it's a hassle to place them back on all 16 soldiers every time I use it. (If anybody knows a way to get HW to remember where they should be placed, let me know!) In the long run, I find it easier to just scroll through Soldier or Unitref with EDIT. Either way is real work, but at least with EDIT, it's "just show me the #$@!$ bytes!" I also wish HW had a wider data view (with smaller fonts for it) and would let you re-arrange the fields shown in the structure overlay in whatever order you want (i.e., one that makes more sense for my purposes than their somewhat scattered layout).
  
 
== Non-Randomness ==
 
== Non-Randomness ==
Line 10: Line 20:
 
This section <i>only</i> applies to [[Experience#Primary_Stats|primary]] skill increases:
 
This section <i>only</i> applies to [[Experience#Primary_Stats|primary]] skill increases:
  
When I've talked about experience rolls, I've made it sound like you always get the average (halfway between the ranges). But this is definitely not the case, especially when there are very few experience points (EPs) in [[UNITREF.DAT|UNITREF]] offsets 80-85. Specifically, when there are only 1 or 2 primary actions - the first 'step' for primary skill points - I saw <i>very</i> weird, non-random stuff. Example: I would set up 16 soldiers, with only 1 or 2 EPs for each soldier. When I ended the combat, the skill point range was undeniably 0-1. But far more often than not, the 16 soldiers in my test crew would <i>all get 0 skill points, all across the board</i>. Then every now and then <i>they would all get 1 skill point, all across the board</I>. And even less often, there would be a mix of 0s and 1s in the results. The <i>actual</i> average increase was about <b>0.2</b> points, <b>not</b> the 0.5 points I wrote in [[Experience#Primary_Stats|Experience]]. To this day, I cannot get a handle on what is triggering them to all be 0 or 1. My best guess is that it is based on some high-level bit mask over the system clock... it seems to come and go in unpredictable spurts. (If this is true, it's possible that my [http://dosbox.sourceforge.net DosBox] wrapper is messing with the results. But then, it would be for anyone using DosBox.) I did my testing by reloading and combat-ending approx. 20 different hacked combat-mission savegames (as I zeroed in on issues to test) hundreds of times in sum total, so I can never be sure my problems weren't caused by the simple fact that I was reloading a few games many times, instead of racking up experience points <i>au natural</i>, where some unknown randomness seed might be being kept somewhere.
+
When I've talked about experience rolls, I've made it sound like you always get the average (halfway between the ranges). But this is definitely not the case, especially when there are very few experience points (EPs) in [[UNITREF.DAT|UNITREF]] offsets 80-85. Specifically, when there are only 1 or 2 primary actions - the first 'step' for primary skill points - I saw <i>very</i> weird, non-random stuff. Example: I would set up 16 soldiers, with only 1 or 2 EPs for each soldier. When I ended the combat, the skill point range was undeniably 0-1. But far more often than not, the 16 soldiers in my test crew would <i>all get 0 skill points, all across the board</i>. Then every now and then <i>they would all get 1 skill point, all across the board</I>. And even less often, there would be a mix of 0s and 1s in the results. The <i>actual</i> average increase was about <b>0.2</b> points, <b>not</b> the 0.5 points I wrote in [[Experience#Primary_Stats|Experience]]. To this day, I cannot get a handle on what is triggering them to all be 0 or 1. My best guess is that it is based on some high-level bit mask over the system clock... it seems to come and go in unpredictable spurts. (If this is true, it's possible that my [http://dosbox.sourceforge.net DosBox] wrapper is messing with the results. But then, it would be for anyone using DosBox.) I did my testing by reloading and combat-ending about a dozen different hacked combat-mission savegames (as I zeroed in on issues to test) hundreds of times in sum total, so I can never be sure my problems weren't caused by the simple fact that I was reloading a few games many times, instead of racking up experience points <i>au natural</i>, where some unknown randomness seed might be being kept somewhere.
  
 
Anyway, I kept the main wiki summary simple, and just strongly advised people to try to get at least three primary actions. Although 1-2 actions was weird, by 3 actions I saw little non-randomness. More precisely, I saw <i>some</i> non-randomness, such as all stats getting the exact same result for several tests in a row. But, when summarized across any larger <i>n</i> (20+ tests), the summary stats were always close to the average of the range. So, there was a little bit of weirdness at 3+ actions... but it was nothing like at 1-2 actions.
 
Anyway, I kept the main wiki summary simple, and just strongly advised people to try to get at least three primary actions. Although 1-2 actions was weird, by 3 actions I saw little non-randomness. More precisely, I saw <i>some</i> non-randomness, such as all stats getting the exact same result for several tests in a row. But, when summarized across any larger <i>n</i> (20+ tests), the summary stats were always close to the average of the range. So, there was a little bit of weirdness at 3+ actions... but it was nothing like at 1-2 actions.

Revision as of 15:19, 9 October 2005

Here be more detail than you ever wanted to know. Please put comments/question in italics. If you want an email reply, either be a regular of here or xcomufo.com, make a User page, or just type in yer email addy.

The Experience of Experience

A.K.A. more details than you ever wanted to know, about testing XCOM:UD 1.4 experience counters versus stat increases

My observations under Experience are getting incredibly long-winded. And at the same time, I am doing yet more research on it. So I've made this space to put levels of detail that are way more than a casual player is interested in. I will probably move some stuff out of Experience and over to here as I polish the info.

My Test Setup

For my testing, I have a MS Access VBA module that sucks in a savegame and compares it to another one (from before the combat). I edit experience counters (offsets 80-85 in UNITREF.DAT) and soldier stats (bytes 43-62 in SOLDIER.DAT) from a savegame ready to be ended (a Muton base with 16 soldiers standing in the entry area). Although it took weeks of futzing with Access to get it set up nicely, now that it's done, I can generate each combat-mission skill-point result in as quickly as I can load a savegame, end the mission, and then savegame on the geoscape (approx. 15 seconds). As of this writing, I have 4,544 individual soldier results (a.k.a. 284 savegame results at 16 soldiers each). This was for 11 different configurations of experience counters and soldier stats, as I zeroed in on different questions to ask (an average of about 25 savegames per configuration).

Psi Lab end-of-month increases vs. Psi Skill

FWIW, the Psi Lab training tests were way easier than combat-mission experience-vs.-skill-point tests. For three reasons: 1) I only had 16 soldiers in my base combat-mission scenario, whereas I could use all 250 soldiers when testing the Lab. (It took a lot of manual Soldier.Dat hacking, though!) 2) The Psi Lab results were much more simple and clear vs. combat results, as the wiki shows. Finally, 3) only one stat was being looked at, whereas combat results can affect 9 stats, each of which has to be examined in its own way. For the Psi Lab tests, I quickly generated 8,500 datapoints (34 savegames) and within just two different savegame configurations, it's behavior was crystal clear. (I didn't include these 8,500 results in the 4,544 counts I mentioned for combat results, of course.)

I'm happy to share my MS Access setup with anybody that wants it; just send me an email. But you are warned - it's all home grown code. I'll walk you through it, but you have to do it exactly right... there ain't no user manual or Help routines for this baby! You coders know what I mean. Also, just so you know... the only thing it does relative to game files, is read Soldier.Dat. It doesn't touch any other file, and it doesn't write to anything (except itself, of course). I did all my Soldier and Unitref hacking by hand.

FWIW, at first I used Hex Workshop to hack Soldier and Unitref (thanks Danial!), but lately I've only been using EDIT... I couldn't figure out a way to make HW "remember" where to place its structure overlays, and it's a hassle to place them back on all 16 soldiers every time I use it. (If anybody knows a way to get HW to remember where they should be placed, let me know!) In the long run, I find it easier to just scroll through Soldier or Unitref with EDIT. Either way is real work, but at least with EDIT, it's "just show me the #$@!$ bytes!" I also wish HW had a wider data view (with smaller fonts for it) and would let you re-arrange the fields shown in the structure overlay in whatever order you want (i.e., one that makes more sense for my purposes than their somewhat scattered layout).

Non-Randomness

This section only applies to primary skill increases:

When I've talked about experience rolls, I've made it sound like you always get the average (halfway between the ranges). But this is definitely not the case, especially when there are very few experience points (EPs) in UNITREF offsets 80-85. Specifically, when there are only 1 or 2 primary actions - the first 'step' for primary skill points - I saw very weird, non-random stuff. Example: I would set up 16 soldiers, with only 1 or 2 EPs for each soldier. When I ended the combat, the skill point range was undeniably 0-1. But far more often than not, the 16 soldiers in my test crew would all get 0 skill points, all across the board. Then every now and then they would all get 1 skill point, all across the board. And even less often, there would be a mix of 0s and 1s in the results. The actual average increase was about 0.2 points, not the 0.5 points I wrote in Experience. To this day, I cannot get a handle on what is triggering them to all be 0 or 1. My best guess is that it is based on some high-level bit mask over the system clock... it seems to come and go in unpredictable spurts. (If this is true, it's possible that my DosBox wrapper is messing with the results. But then, it would be for anyone using DosBox.) I did my testing by reloading and combat-ending about a dozen different hacked combat-mission savegames (as I zeroed in on issues to test) hundreds of times in sum total, so I can never be sure my problems weren't caused by the simple fact that I was reloading a few games many times, instead of racking up experience points au natural, where some unknown randomness seed might be being kept somewhere.

Anyway, I kept the main wiki summary simple, and just strongly advised people to try to get at least three primary actions. Although 1-2 actions was weird, by 3 actions I saw little non-randomness. More precisely, I saw some non-randomness, such as all stats getting the exact same result for several tests in a row. But, when summarized across any larger n (20+ tests), the summary stats were always close to the average of the range. So, there was a little bit of weirdness at 3+ actions... but it was nothing like at 1-2 actions.

Secondary "Steps"

In the wiki on secondary stats, I said that there is an even slope for secondary skill point gains, from an average of 4 (range 0-8) at (hacked) secondary level 0, to an average of 1 (range 0-2) at Cap-1. That was a simplification, to keep the wiki short. In actuality, it's like this:

The three stats TUs, Health, and Strength have a maximum range that increases by 1 at every increment of 10, working backward from the cap. Stamina - that high-winded beast - increases at multiples of 15. This follows the usual X-COM approach of defining a range and rolling randomly within it. So a graph of the maximum range of points possible vs. current stat level looks like this:

Maximum point ranges secondary stat increases

Thus e.g. TUs has a range max of 2 from stat level 71-79 (80 is the cap), 3 from 61-70, 4 from 51-60, etc. TUs, Health, and Strength work backward in increments of 10, but Stamina has steps 15 stat points wide. So it has a range max of 2 from stat level level 86-99, 3 from 71-85, etc.

(All secondary skills have a range minimum of 0 across their span; it's entirely possible to not get an increase in a secondary skill after a combat. So on average, you expect to get half the range maximum.)

Interestingly, at (hacked) stat level=0, Stamina and Health can get 8 points assigned (like I said in the wiki), but Strength can get 9 points, and TUs can get 10. Then all of them quickly drop the range to 1 point less, at level=1 (except Stamina, working backwards in steps of 15).

So this step function means that the "even slope" I talked about is not quite correct, nor are the averages that I put in that table for each level (those are based on a linear slope equation instead of half of that step's range maximum, which is what the true case is). Still, it's a very good simplification, especially when you're talking about the average number of CMs to go from e.g. Recruit Max to Cap. So I kept the wiki shorter by not going into the level of detail shown here.