Talk:SOLDIER.DAT
Why would Missions and Kills be signed? You're never going to have negative values. Shouldn't they be unsigned??
- Danial
You would think that, wouldn't you? At least that's what I would've done in their place. You can't owe a few kills or missions!
But if you enter values of 0xFFFF into each, the base screen shows -1. Hence why they're signed.
- NKF
Zombie, I've changed back your recent change to offset 63, as you've been mislead a bit by corrupt data...
The files MAN_A.SPK through to MAN_N.SPK do not exist in a normal install of UFO, I'm afraid, and it was never intended for Soldier.Dat to point to them. They are simply the file names I chose when I coded my custom uniform mod, so that aliens wouldn't display as troopers in the inventory screens anymore. I later added the same effect to my map editer as well. This affected the inventory screens and nothing else, by tweaking UnitRef[1] - The installation of either of my programs obviously adds the required MAN files to your game (as referring to any MAN file that does not exist causes a crash).
On the other hand, modifying Soldier[63] apparently changes the way the unit appears in the battlescape display, as well as what it turns into when it dies! This means that it is not only used to determine UnitRef[1] when battle begins, but UnitRef[0]/[38] as well, and most likely others...
That is to say, this byte gets set when you give a trooper armor. Armor dictates how a unit appears. However, it also indicates a units defensive values, and what item it will turn into when it dies. You didn't mention defense in your edit, but I would assume it also gets set to garbage when you fiddle with this offset.
I'll check this with a byte comparer when I get the time. With any luck, this'll also show me any remaining UnitRef offsets that are affected by this one. I'll update the article when I get some results.
- Bomb Bloke 05:41, 6 November 2006 (PST)