Why would Missions and Kills be signed? You're never going to have negative values. Shouldn't they be unsigned??
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.
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 - 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 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 when battle begins, but UnitRef/ 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)
My fault, but problems like these could easily be avoided with a readme file indicating what modifications are made to the game files. Never thought that an editor had modding chunks tossed in. That'll teach me a lesson.
Changing the armor field in soldier.dat ( or  or whatever the darn offset is), changes the image sprite in the battlescape without too many problems, but running through your unit list in the equip screen will crash the game if the number here is greater than 3 as there aren't any MAN.spk images to refer back to. Like you mention, the actual armor attributes are garbage (albeit consistent garbage as the numbers do not change). Just for giggles I did a couple dry runs with varying values to see what would happen to the death item and armor attributes. This may or may not be useful.
I couldn't find out what item the Cyberdisc "unit" gives up when it dies, as the explosion happens even with Stun Bombs. I assume it's Elerium-115 as it follows the normal item list. The male civilian is a tough nut to crack also. I saw a death item of a Laser Rifle and a Small Rocket a few times - it's probably random or semi-random. Still, you can't stand over the "corpse" and pick up the item as it is invisible in the equip soldier screen. The Zombie is also strange as it cannot be killed by incendiary, most likely a hacked armor value will make the game assume you are wearing a suit of armor greater than Personal and apply the 0% modifier. A value of 23 will crash the game if you try and kill the unit so it's just an assumption that the death item is a Floater corpse.
I should also mention that some of the invisible units higher up on the list are probably tanks as the sound usually correlates to image. This doesn't hold for units lower in the list as I heard a movement noise of a Pistol or Rifle shooting rapidly for one of them! Strange stuff, but it can probably all be tied together once we know where the pointers are going.
That's an easy one at least. As you mentioned, they follow the normal item list when turning into death items. Simply put, a unit will turn into object X, where X is 31 + Soldier. That is to say, by default, a unit with no armor (value 0) will turn into a normal corpse (31). But if you crank the value up to, say, 19 (an illegal value), you get a sectoid corpse (31 + 19 = object 50). Pointers to items in the list that were never implemented in the game create weird results.
As for why the floater crashes when dying, perhaps it uses an illegal death scream or something. The corpse value seems legal enough.
The units which sound like tanks, aren't. The reason they makes those noises is because each unit has it's own movement sound set, which is determined by some value in UnitRef. It's one of the values I've been meaning to hunt down but never got around to...
Furthermore, some units slide, and some units walk. This is another value I've yet to hunt down, but it's important, because sliding units (snakemen, tanks) sound the same regardless of the terrain they're moving over. They also incur different TU costs as per MCD-.
So obviously one or both of those values are also being determined by Soldier. That'll make them easier to find in UnitRef.
Remember that a soldier is a soldier whether he's in armor or out of it. His armor does change the way he appears, and a few other things, but he's still a soldier at the end of the day. That said, a mod could easily be made that turns units wearing certain (hacked) armor types into aliens when combat begins, hence allowing you to easily deploy them at will. But there's no way it can be done just by tweaking values in save files, I'm afraid.
- Bomb Bloke 14:45, 6 November 2006 (PST)
As I was tinkering around with some files, namely for my Python XCOM 'editor' I noticed that on some of my soldiers the base reference was set to a crash site in loc.dat. So I'm thinking it got mislabled as a base referense when it should be a current location reference.
I haven't completely verified this yet, but just wanted to throw it out there. -Pi Masta 20:13, 6 February 2007 (PST)
Book of the Dead
So after reading this excellent XCOM thread I was reminded I'd like to have some way of logging the names of who actually died in a mission. You forget the rookies so quickly...and there's all those letters to write. After a while you even forget your heroes, custom names or no. This would keep track of the names for the memorial.
I can see one way of doing this would be to just compare SOLDIER.DAT (or UNITREF.DAT) in two different saved games, pull out the names of the dead soldiers (along with rank, missions, kills info), and append it to a text file. Is a record in SOLDIER.DAT changed when the soldier dies, or what's the best way to determine who has died? Any advice from the experts? I see a bit in UNITREF.DAT but that's only for Battlescape saves, right?
Maybe later this could be linked to the DOS game's batch file, so every transition between Battlescape and Geoscape updates the Book of the Dead. --JellyfishGreen 08:47, 7 May 2008 (PDT)
I'm sure that with a little bit of tweaking, Bomb Blokes logger could be programmed to do this. It might be a bit of work, but it's certainly possible. --Zombie 09:07, 7 May 2008 (PDT)
Yes. SOLDIER.DAT is updated without destroying most of the information (not quite sure what is lost as I don't have a savegame with dead soldiers on hand), think rank is lost (first two bytes reset to FF FF) but soldier value and missions are not lost so that can be recalculated for non-hacked games). The kill count won't include any kills on the mission before being killed.
Hiring a new soldier will overwrite all of this.
--Zaimoni 13:39, 7 May 2008 (CDT)
In a technical sense it's easy enough, the main problem is when the logging should be done...
My first thought would be to do it at the end of combat (by checking UNIREF2.DAT and UNITPOS.DAT (MISSDAT)), but the problem with doing that is that if the players save then quit mid-mission (with the intention of resuming later), most of their squad would mistakenly be listed as MIA. It gets even messier should the game crash.
On the other hand, doing the check when the player quits the game entirely is even harder to swing, because how does is know which save games to check?
Perhaps prompting the user whenever combat ends as to whether they wish to log or not? This isn't exactly transparent, but it's the best I can think up. Any thoughts?
- Bomb Bloke 02:27, 8 May 2008 (PDT)
To test Seb76's theory I wounded 4 soldiers on a mission (close range pistol shots in the Skyranger) and flew straight back to base. From a save file taken as soon as they were back at base, all 4 soldiers showed positive wound recovery time, offset 4 = FF FF, offset 6 = FF FF. So apparently no record of what craft they were in unfortunately. Spike 14:19, 12 November 2008 (CST)
- This is quite unfortunate indeed because the code is crytal clear: offset 4 is copied into offset 6 before being cleared (offset 0xc is set inbetween but it is a detail) :( Maybe there is a bug in the game and the craft is already cleared elsewhere? What happens when the soldiers recover, do they get back to their original craft? Seb76 14:37, 12 November 2008 (CST)
Maybe something changes between tactical.exe and geoscape.exe, I'll go back and check. By the time they get back to base, the wounded soldiers are indistinguishable from other unassigned soldiers, apart from Offset 0xC (wound recovery time). - No, in the tactical save, the offset 4, 6 and 12 values are unchanged from what they were pre-mission. So the update to these fields is done at the end of combat - as you have probably found out. I will check if I'm using XcomUtil, that might be interfering with the files somehow. Also, I checked and recovered soldiers don't get reassigned to a craft, they are assigned to NONE. This does sound like you have discovered the intended behaviour, but it's failing due to a bug. There would be a logical difficulty - if the craft is already full when you try to re-assign a recovered soldier to that craft, how would the game handle that situation? (I made sure I had enough free slots on my craft but still no re-assignment). Spike 15:07, 12 November 2008 (CST)
Hmm. Even if I hack the craft value (copied from the unwounded soldiers) into offset 6 of the wounded soldiers, they still don't re-assign back to the craft once they are recovered from their wounds. Spike 15:23, 12 November 2008 (CST)
Oops! It was XcomUtil that was interfering with the behaviour you deduced. Probably Scott Jones did not understand this behaviour? When I remove XcomUtil (actually I used a virgin re-install), I can see the changes you are reporting in Soldier.Dat - offset 6 is set to the craft number, offset 4 is FFFF. I've used different craft to confirm it is the craft number that gets written to offset 6. However, when the soldier recovers from wounds, they are still assigned to NONE - they don't get reassigned to the previous craft. Even with the correct values in offset 4, placed there by the game, there doesn't seem to be any behaviour that uses that data. So it seems like this is a half-implemented feature? Spike 16:18, 12 November 2008 (CST)
- They probably removed it because it is too error prone: as you mentionned, if the craft is full when the soldier comes back, it must not be reassigned to the ship. Also the ship may no longer exist (the entry could even be reassigned to another craft, which could be fighter only or worst: a UFO). That must be why the feature was not kept. Seb76 16:45, 12 November 2008 (CST)
Offset 64/0x41 Promotion flag
This generally flags as 1 if the soldier was last promoted in the last combat.
I was just checking a soldier listing and had a rookie with this field flagged. Does this field get flagged if the soldier was eligible for promotion even though there was no room? -NKF 08:46, 19 July 2009 (EDT)
- Sounds reasonable: the flag could be a signal for geoscape.exe to promote the soldier, rather than a flag that tells whether or not a soldier was promoted after his last mission (which really is useless information).FrederikHertzum 17:22, 24 January 2011 (EST)
the NAME field
I've just been testing with TFTD, and ran the same tests here.
The NAME field is a cstring, or "ASCIIZ" field. Care must be taken not to overwrite the last character of the name with anything but a 0 (NUL) character, otherwise the game will happily continue loading and rendering bytes past that point. Fortunately, the transfer fields (which follow name) are usually 0 as the soldiers are not usually transferring, so those usually act as a terminating null.
Thus, although one can get away with using that last byte, it's definitely not 'best practice' in any way.
Meh..forgot to sign. ~ Renegrade 07:40, 16 August 2010 (EDT)