Talk:UNITREF.DAT

Anyone who has it - can we get listings of values for various aliens on the Unitref page, for some of the variables found in both Unitref and the Geoscape Alien stats? E.g. energy recharge (Unitref[35]), energy loss [45]... like what Danial did for Height. Some of it might go to NKF's redesigned Soldier page. I am trying to flesh out the Geoscape data so I know what everything is there (and can then extend it across difficulty levels). It has unlabelled fields with values, some of which I know must be these values... but there's no list for me to compare against. Thanks if you can help! ---MikeTheRed 19:37, 25 Nov 2005 (PST)

P.S. We probably should clean up this Discussion some time. I will if I find the time to make sure everything has made its way to wherever it should go.

---

Offsets 0x30 & 0x34

I've chopped out the majority of this page as it is no longer required. I'm keeping the heights chart in case it is required - I've also changed the "H-F" field to "H+F", as this actually makes sense.

               [49] [51] "Tall" [48]  | [49] [48]    
  Class         Ht.  Flt   H+F  Wide  |  Ht. Wide Area
  ---------     ---  ---  ----  ----  |  --- ---- ----
  Sectoid       16    0    16    2    |   16   2   32     Area=Ht.*Wide
  Celatid       12    6    18    3    |   12   3   36
  Hovertank*    12    6    18    4    |   12   4   48     
  Silacoid      10    0    10    5    |   10   5   50 
  Snakeman      18    0    18    3    |   18   3   54 
  Zombie        18    0    18    3    |   18   3   54
  Cyberdisc     15    2    17    4    |   15   4   60
  Ethereal      20    0    20    3    |   20   3   60    All Hover/Tanks in their
  Chryssalid    21    0    21    3    |   21   3   63    class assumed to be same
  Civilian      21    2    23    3    |   21   3   63    altho not tested yet
  Floater       21    2    23    3    |   21   3   63
  Muton         21    0    21    3    |   21   3   63
  Tank*         16    0    16    4    |   16   4   64
  Soldier       22    0    22    3    |   22   3   66
  Reaper        23    0    23    4    |   23   4   92
  Sectopod      23    0    23    4    |   23   4   92

Anyway, unitref[48] and unitref[52] remain somewhat of a mystery. Thus far we've assumed them to be the unit's width. Today I tried tinkering with [48] to see of this was correct. As I cranked it up, I found no change in my accuracy, or as to how the Sectoid target blocked line of fire to the tiles behind it.

When it reached the value of 37, however, the alien disappeared! I could not view it regardless of distance. In fact, I could even fire right through the tile it was standing on with no obstruction. The only sign that the alien was still there was the fact that my unit could not stand on the same square.

I lowered [48] a bit and tried viewing the alien from different distances, and found that it appeared in the same way as it usually would, regardless of the value used. It's simply the case that going to 37 or above makes the alien invisible.

I also tweaked [52] a bit, but found that it seemed to have no similar effects, if any at all.

Although I haven't tested this any further as yet, it might be possible to use this effect in reverse - Create an 'invisible' X-Com unit, and use it to observe how aliens act when they think we're not looking.

- Bomb Bloke 00:44, 31 July 2006 (PDT)

---

I have a strong belief that offset 48 is nothing else but the loftemps.dat entry used for collision checking with bullets. A first check is done against the unit height (taking into account floating height, terrain height, kneeling). If the check is OK, the loftemps entry is then used as a final check (effectively treating the unit as a cylinder). I'll try to decypher the code further. If others want to have a look, the code is around here:

.text:004116AE 8B 15 5C 28 4A 00       mov     edx, pUnitPos
...

Seb76 13:24, 10 April 2008 (PDT)

---

I'm inclined to agree with you, though I'm not much good at reading through executable code. :( I hit on the same idea on my talk page... I've got some notes in there about how I think the firing system works, if you could find code to back it up I'd be a happy boy.

It's something of a long winded work-in-progress ramble, and I'm sure some parts are confusing and/or dead wrong, but with any luck you can make some sort of sense of it. :) - Bomb Bloke 18:34, 11 April 2008 (PDT)

---

I mentionned it earlier but got no real feedback so I'm adding a new section for it ;)

It looks like it is the loftemps entry used for collision detection with bullets. The main page says that setting it to 37 make the shots go right through the guys. If you have a look at the entry, you'll see why... The interesting thing is that the big units do not have special entries (unitref is common for all 4 parts so it would not have been possible to do otherwise) so a shot should be able to go through them (between the 4 parts). However, for the shot to be almost horizontal (or vertical) and traveling at the frontier between tiles (to go between the 4 "collision" circles), the shot should come from far far away so it is not likely to happened. Also depending on how the visibility check is performed, it may explain why alien suddenly disappeared when messing with the value (see discussion upper in this page). I suspect it is done using some kind of raytracing between the center of the 2 tiles (between the current unit and the target); so if the loftemps entry for the target has a "hole" in its center, it may become invisible. Seb76 07:00, 1 June 2008 (PDT)

---

I just edited unitref 048 and 052 of all my soldiers to 0 and the aliens never tried to shoot at me. When I edited 048 to 0 for all the Sectoids on a mission, my soldiers couldn't see them anymore (only takes effect the following round if edited in unitef.dat, but surprisingly aliens remain visible to you during their movement phase). Since loftemps 0 is an empty cell, the results make perfect sense. A value of 76 (both 48&52) makes aliens disappear too. I'm not sure what the threshold is for disappearing, but a 3x3 block (loftemps 1) is still enough to be seen. --Zombie 15:08, 17 August 2008 (PDT)

---

Am I understanding correctly... for purposes of shots hitting, we're all "barrels" with a specific diameter (i.e. LOFTEMPS.DAT 2-5), height ([49]), and distance (float) off the ground ([51])? Right or wrong, it sounds like this is finally pretty sown up, excellent work. We could update the page's entries. I wonder why they repeated this value twice (i.e. [48] and [52] always the same)... maybe they once considered the possibility of a unit whose diameter can change from turn to turn? If so, some other heretofore unfathomable UNITREF bit or byte may have been intended to dictate whether they're currently using the diameter at [48] or [52]. -MikeTheRed 17:06, 17 August 2008 (PDT)

---

While I've no problem believing [48] is a LOF template reference, I hadn't added it to the main page because I wanted to be sure as to it's relationship with [52].

See, at present, all we know about [52] is that it's the same as [48]. We haven't seen any effects from changing it.

What I suspect is that one offset might be used for shots traveling along an angle parallel to the target, and one offset might be used for shots traveling perpendicular. This would basically allow units to be effectively oval shaped (or it would, if [48] and [52] weren't the same for all units).

Just one of those things that I never got around to finishing the testing on. Would be dead easy to check, though.

There's still a little more to be researched before the entirety of the firing system is understood (see my talk page for a rambling explanation as to what IS known), but that's pretty much the basics of it.

- Bomb Bloke 19:51, 17 August 2008 (PDT)

---

BB and others, see my edits for [48]. Does it make sense? In particular, I estimated pixel width from that little LOFTEMPS .png by magnifying it a ton. Any and all comments or edits welcomed. It's interesting that the silacoid has the highest width, but a low cross-section - did anyone see the Star Trek TOS show with the very short, wide silicon aliens? -MikeTheRed 22:53, 23 August 2008 (PDT)

---

Yes, you got the LOF widths correct. Though as you mentioned, they're only accurate assuming you're firing head on at your targets (as the templates aren't perfect circles, their width varies from other angles).

I threw in the kneeling soldier stats and made a note concerning large units.

- Bomb Bloke 22:21, 24 August 2008 (PDT)

Offset 0x3C

I have a gut feeling it is related to the panic/berserk status of the unit... Any volunteer for testing? Seb76 10:36, 22 March 2008 (PDT)

---

Made a save where all soldiers had no morale. Ended turn, most of them panicked etc. Saved the game but that offset still came up as 0. Might only be flagged at runtime.

- Bomb Bloke 18:01, 26 May 2008 (PDT)

---

I checked and indeed the game sets and clears it in the same turn so it is always 0 in a savegame and hence there is no 'black box' way of confirming it. I can provide disassembly screenshots if you want proofs however ;) Seb76 05:45, 28 May 2008 (PDT)

Actually after some thinking, it _might_ be possible... If you set the value to 3 for all entries, everyone may go berserk, with 2 they should run in fear and 1, they'll just crap their pants in place... Seb76 07:09, 28 May 2008 (PDT)

---

I tried it, and indeed my units did exactly that (at the start of their next turn - not that of the aliens).

- Bomb Bloke 21:08, 28 May 2008 (PDT)

Offset 0x71

Hmm, the code checks this offset before applying stun damage... It looks more like an 'immune to stun damage' flag then. Strange... Seb76 13:48, 7 April 2008 (PDT)

---

By memory, the only things that use this are X-Com HWPs (which shouldn't have stun applied). It does toggle inventory access as described though it wouldn't surprise me if it also toggled stun damage.

- Bomb Bloke 05:46, 8 April 2008 (PDT)

OK, I located the check and it is exactly what happens. BTW, if you want to try something, try to patch this with nops (0x90):

.text:00412A20 A8 40                   test    al, 40h
.text:00412A22 0F 85 00 02 00 00       jnz     exit                            ; default

It should enable inventory screen for memory controlled units (could not test since I have no save files with psy units...) Seb76 11:37, 8 April 2008 (PDT)

So, to be clear, is this the location of the inventory screen check for mind controlled alien units? And here you are disabling the check by overwriting it with NOPS? Is there a nearby section of code that does the same check for tanks? I would like to be able to override this tank inventory check in order to play with Tank mods. It looks like NOPing the check logic is the right way to do it, since if instead I toggled the 0x71 flag for the tanks, they would than also become vulnerable to Stun? Though I also I think read somewhere that if you get to the inventory screen of a tank, the game crashes. It doesn't crash if you get to the inventory screen of an Alien large unit via the Alien Inventory or Alien Pets hacks (not sure which) in your UFOExtender. I was able to arm Reapers with dual Heavy Plasma or dual Blaster Launchers. (Unpleasant. They have 0% FA so they have to run up to you and spray with the Heavy Plasma. Not a problem with the Blaster Launcher.) Spike 13:59, 20 August 2009 (EDT)

Offset 0xB

The value is used together as an offset to MCDData offset 39 (describing TUs required to cross a tile walking/flying/sliding) so it most likely represent the way the unit moves. Still needs testing. Seb76 13:27, 23 May 2008 (PDT)

---

I took a look at it for Snakemen and Silacoids, it's still 0 (same as it is for everything else).

But that doesn't mean it remains at 0 when the game's running. Do you mean to say that the value here + 39 = the offset in the MCD array that says how many TUs were required to move past any given obstacles in the current map location?

(That is, you'd expect to see a 2 there for sliding units?)

- Bomb Bloke 05:14, 25 May 2008 (PDT)

---

Yep, exactly like that. Also it checks if the value is 0xff and prevent movement in that case. I'll try a live check with a debugger when I encounter snakemen. Maybe it's a part of code that was implemented but not put into usage. Seb76 05:20, 25 May 2008 (PDT)

Did the check and the value is indeed zero even for snakemen... BTW, is the movement type really working? I mean has anybody ever checked that e.g. snakemen really use different TU amount for tiles where TU usage is not the same between crawling and walking? Seb76 06:43, 25 May 2008 (PDT)

---

Truth be told I don't remember reading of anyone doing the tests, so I had a go myself.

I tried first with the Avenger ramp, stuck it up in the air and had soldiers walk/fly onto it. Made no effect to their TU usage.

Next I rigged a Snakeman mission in the arctic, stuck one of them in the middle of a pond. It wouldn't move on it's own, and I couldn't move it under mind control.

So then I set 0xB to 2 just for that unit, and hey presto! Suddenly it was able to move freely, either under my control or otherwise. That's certainly the movement type flag... It's just not set in practise.

Still, now I'm wondering if 2 really was for sliders... It doesn't make sense that "fliers" (which I guess was supposed to include the likes of CyberDiscs, which "hover" even when on the ground) wouldn't be able to cross water, yet Snakemen could. Perhaps it should be the other way around?

- Bomb Bloke 19:22, 25 May 2008 (PDT)

---

Note that there are some tiles that have 0 MP cost for sliders. - Zaimoni 22:28, 25 May 2008 (CDT)

Yeah, I guess that puts the clincher on it. Only fliers would really be totally unhindered by ground rubble. I've tweaked the MCD details page accordingly. - Bomb Bloke 05:25, 26 May 2008 (PDT)

---

Hehe, I knew it couldn't be anything else but movement type. Yet another entry for known bugs ;) I'll check if it's possible to reenable the feature. It'll depends if it's a bug or if it was voluntarily removed I guess... Seb76 04:37, 26 May 2008 (PDT)

Did a quick check and can confirm what is said in Alien Stats page. Offset 0xB is filled with the 3rd "unknown" value of alien stats. It is set to 0 for all entries. Could not find any other place where it could possibly be set to another value. Seb76 05:17, 26 May 2008 (PDT)

---

So it's just a matter of tweaking that for all relevant units, then. However, I reckon it was left unused intentionally - I doubt the map files really contain enough variety to make it worth including.

- Bomb Bloke 05:25, 26 May 2008 (PDT)

---

Since TFTD was done later with the same engine, perhaps it makes use of this? However, given that a different team made it (Terror from the Deep was developed by Microprose using code licensed by Mythos), developers may not have known the feature was available... Seb76 07:25, 28 May 2008 (PDT)

---

I took a quick check, and sure enough found a Hallucinoid (the big flying squid thing) set to 2.

- Bomb Bloke 21:31, 28 May 2008 (PDT)

Offset 0x47

The only use I could find is that of updating mobile light sources (or something like that) when the unit dies/is rendered unconscious. Could not find anything else about this flag. Seb76 05:24, 29 May 2008 (PDT)

Good work there. As a general statement, can I say - I've been waiting for somebody to disassemble XCOM :) -MikeTheRed 21:18, 30 May 2008 (PDT)

I sat down to do some tests with this, but didn't bother too read to closely... I was selecting/moving units around when I probably shoulda been shooting at them.

Oh well. For the record:

Moving a unit causes a light check to be done on all your units. You may not see this light if one of your units is standing in a fog-of-war covered zone (say you just mind controlled an alien and haven't selected it yet).

Selecting a unit does a fog-of-war check concerning what it can see, but does not do a light check.

Whatever this offset is has no effect on the light produced by your units, or the aliens units. Your active guys ALWAYS fully illuminate their tile (even if this is 0) and the aliens provide no illumination at all. Will have to do some tests concerning what happens when you shoot them, but it seems odd: If a unit is dead I'd expect a full light check to be done, since the unit isn't "active" it won't produce light, so I don't see how this offset is helpful there... You can't just remove the light values for this one unit because you might interfere with other nearby light sources, so you really have to calculate them all from scratch.

But likewise it seems MCD[58/3A] is similar; a street lamp is set to 1, a normal lamp to 10, but they both provide maximum illumination.

Perhaps the programmers changed their mind about the lighting system at some point? Dunno.

- Bomb Bloke 07:03, 20 June 2008 (PDT)

Some of your note reminds me of what I wrote at Night_Missions#Personal_lighting ... does that help any? (probably not) -MikeTheRed 16:01, 20 June 2008 (PDT)

On Fire Flag or Timer ?

Do we have any idea where a flag is set to show the unit is on fire? This is persistent between saved games so it must be stored in a file somewhere. Possibly UNITPOS.DAT? It could be a flag, but more likely is either a countdown timer for turns remaining on fire, (values 1-5?), or a "what turn do I stop being on fire" timer value (like a grenade timer).

I have uploaded a saved game file with a burning Aquatoid if anyone wants to take a look. I just don't have the right diff tools. Maybe with the Hex Workshop template... Spike 19:05, 10 March 2009 (CDT)

Offset 114 in Unitref holds that data. --Zombie 19:15, 10 March 2009 (CDT)

Sorry I did not read the article carefully enough. It's in there. Spike 19:16, 10 March 2009 (CDT)

114 / 72: If not 0, then unit is on fire, and will burn for this amount of turns.

Floating Civilians

Civilians float 2 units off the ground, like Floaters and Cyberdisks. Soldiers don't. Should we consider this to be a bug? Spike 13:41, 20 August 2009 (EDT)

Probably. I really doubt it's an intentional feature. --Zombie 23:09, 20 August 2009 (EDT)

Remembering morale vs health and pain killers

The game remembers whether a health loss has or has not been used to regain morale via pain killers. Presumably this is stored somewhere in UNITREF.DAT? Spike 10:30, 5 September 2009 (EDT)

TFTD Support

It appears the name string starts at the same point in TFTD save points, which leads me to believe that the extra bytes are probably just appended at the end of the file, without much changing in the first 124 bytes per entry, anyone know what these extra 8 bytes might represent?