Primary Skill Increases

[epiceuropean]

I'm running the Steam version, using UFO Extended (that is, UFOLoader.exe), pointed at the CE Version (UFO Defense.exe).

 

For some reason, my soldiers aren't getting any increases to firing accuracy, despite the fact that they've made dozens of hits. I've had one who, so far, has had a one-point increase in reactions. However, I've double-checked this anomaly by looking at the raw soldier data with xcomed, and sure enough, *nobody* has had *any* increase in firing accuracy or throwing accuracy. All secondary stats (TUs, Health, Stamina, Strength) and psi strength increase just fine. But I've had guys with way more than 3 hits in one mission, yet no increases.

 

I suppose there's the possibility I've just had blindingly bad luck, but ... Seriously? I've killed a lot of aliens and done at least a dozen missions with just this crew alone. I haven't yet poked around unitref.dat thoroughly to check whether each hit is being recorded properly, but I loaded up one of my tactical saves in BombBloke's battlescape editor and, sure enough, soldiers had a hit counter.

 

Any ideas? Am I just not training them correctly? According to the wiki, hitting 3 times in one battle gives you a minimum increase of 1, and even just one hit should, maybe not this battle or the next, but eventually, get you a point of increase.

[Zombie]

I suppose there's the possibility I've just had blindingly bad luck, but ... Seriously? I've killed a lot of aliens and done at least a dozen missions with just this crew alone. I haven't yet poked around unitref.dat thoroughly to check whether each hit is being recorded properly, but I loaded up one of my tactical saves in BombBloke's battlescape editor and, sure enough, soldiers had a hit counter.

I'd take a look in Unitref.dat to see if the FA experience counter is incrementing. If it isn't, something is fishy.

 

- Zombie

[epiceuropean]

Well, this one's totally weird.

 

I peeked at the FA experience counter, and compared multiple saves, where each save I made one more successful hit with a laser pistol on a group of sectoids I had gathered. As you might expect, each hit did properly increment the FA experience counter by one. In the process I got to see my psi use counter go up properly.

 

What's weird is that after combat, the FA stat did not go up. Secondary stats went up: TUs, Stamina, Health, Strength went up. Psi Skill went up by an appropriate amount, that is 2-6.

 

So, I did some more testing and found that Throwing Accuracy and Reactions suffered from the same problem. I remembered that I had changed the stat caps for soldiers in the UFO Extended config file, and figured that this must be a failure of the hard-coded stat progression formulas. The Secondary stat formulas seem to operate fine with a different cap, since they essentially vary their roll range after combat "back from the cap" -- that is, the further away a cap is, the more increase you're likely to have.

 

Any reasonable implementation of this code would first check whether the current stat level was higher than the cap -- and then it hit me. Despite the fact that all base stats and stat points gained through experience are stored as unsigned bytes everywhere else, in the particular case of the stat cap increase function, the caps for Firing Accuracy, Throwing Accuracy, and Reactions *ONLY* are stored as unsigned bytes. Not Psi Skill, for some inexplicable reason -- changing that cap to 255 has no undue effects. Furthermore, the current stat values are read properly as unsigned values -- a stat cap of 127 and current stat >127 (0 or negative when read as signed) does not increase, as logic would dictate.

 

I wonder if this can be fixed...

[Zombie]

Interesting. So FA, TA and Reactions are stored as signed bytes? Odd why the programmers chose this variable type over an unsigned byte, but it probably was an imposed limit due to the introduction of caps themselves.

 

I wonder if this can be fixed...

You could ask Seb76 about it. Most likely it can.

 

- Zombie

Edited January 11, 2010 by Zombie

[[NKF]]

Or rather the actual data is unsigned, but the cap itself is signed. I guess that since the cap is set to 120, it doesn't really matter either way.

 

By the way, what were you using to change the caps? I'm just wondering if that is is writing it as a signed value rather than an unsigned.

 

- NKF

Edited January 11, 2010 by NKF

[epiceuropean]

Or rather the actual data is unsigned, but the cap itself is signed. I guess that since the cap is set to 120, it doesn't really matter either way.

 

By the way, what were you using to change the caps? I'm just wondering if that is is writing it as a signed value rather than an unsigned.

 

- NKF

 

That is actually a great point. I was using Seb76's UFO Extender, aka UFOLoader.exe, available here.

 

I guess it would depend on how the cap modifications are implemented? If Seb's using a code hook to run a workaround function, then this could be a bug in UFO Extender itself. If he's overwriting the cap values when they get loaded into memory and letting the original function do its work, then it's all Microprose. I think it would actually take a fair bit of work to change how the program interprets a byte (aka signed or unsigned) by hacking assembly. As in, far more than just overwriting the data. As in, you'd probably have to do it intentionally.

 

That being said, the magic that is codehooks is not my forte. Don't take my word as law.

 

EDIT: Yeah, looks like the game handles FA, TA, MA, and Reactions differently. After looking through Seb's code, he isn't changing how the game increases stats at all, just what the caps are. Line 1765 in patches.cpp, if you care to look.

Edited January 11, 2010 by epiceuropean

[Seb76]

Or rather the actual data is unsigned, but the cap itself is signed. I guess that since the cap is set to 120, it doesn't really matter either way.

 

By the way, what were you using to change the caps? I'm just wondering if that is is writing it as a signed value rather than an unsigned.

 

- NKF

 

That is actually a great point. I was using Seb76's UFO Extender, aka UFOLoader.exe, available here.

 

I guess it would depend on how the cap modifications are implemented? If Seb's using a code hook to run a workaround function, then this could be a bug in UFO Extender itself. If he's overwriting the cap values when they get loaded into memory and letting the original function do its work, then it's all Microprose. I think it would actually take a fair bit of work to change how the program interprets a byte (aka signed or unsigned) by hacking assembly. As in, far more than just overwriting the data. As in, you'd probably have to do it intentionally.

 

That being said, the magic that is codehooks is not my forte. Don't take my word as law.

 

EDIT: Yeah, looks like the game handles FA, TA, MA, and Reactions differently. After looking through Seb's code, he isn't changing how the game increases stats at all, just what the caps are. Line 1765 in patches.cpp, if you care to look.

Maybe another option is causing the problem? (no funkers and the like). Do you experiment the problem when you turn off the caps option?

Seb

PS: BTW, I did not see if the faulty stats were already above 127. If that's the case then it is indeed a signed/unsigned issue. I can change the jge's to jae's and it should fix the problem.

 

Edit: I uploaded a test version here. Can you give it a try?

Edited January 11, 2010 by Seb76

[epiceuropean]

Edit: I uploaded a test version here. Can you give it a try?

 

Seems to work. Stat caps of 250 are a go. Any higher and you risk wrapping around to zero.

 

I tried turning off No Funkers, and it had no effect. Turning off custom caps makes everything work normally, hence we don't run into the signed/unsigned "bug". I put that in quotes because I think having a max accuracy of 120 is intended behavior, and tuning it past that is what breaks it. Still, I think it's good to have the capability.

 

Thanks, Seb! Impressive work.