Talk:UNITREF.DAT

From UFOpaedia
Revision as of 05:12, 30 May 2015 by Zombie (talk | contribs) (→‎Offset 0x4A (74))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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 0x02 - 0x09

It's obvious from unit drawing functions (reversed ones) it's a PCK and TAB spritepack reference address (DWORD). 

 _pck = (int)unitref_addr->pck_ref;
 _tab = (int)unitref_addr->tab_ref;
 ...
 if ( (_WORD)handob != 255 )
   xc_BF_Draw_Battlescape_shaded_Sprite((char)v18, (int)vf_handob_pck, (int)vf_handob_tab, v21, v23, shade);
 xc_BF_Draw_Battlescape_shaded_Sprite(sprite_num1, _pck, _tab, y0, x0, shade);

--Volutar 09:43, 20 February 2011 (EST)

So you're saying these values point to where the PCK/TAB files used by the unit in concern have been loaded into RAM, similar to how UnitPos[4-7] points to where the UnitRef record is? -  Bomb Bloke (Talk/Contribs) 17:56, 20 February 2011 (EST)
Exactly. They are simple 32bit pointers to RAM location where exact unit PCK/TAB loaded (I don't know how they worked for DOS version - I guess the same way). You could notice the lowest bytes (2th and 6th) are aligned to 4, as for all memory locations. --Volutar 01:13, 21 February 2011 (EST)
Since the saves are interchangeable between the Dos and Window versions, and since the Dos version uses the Dos4gw engine to handle the exapanded memory, it could very well be a 32-bit pointer.
Still, memory pointers? That would mean these values are used at run-time only and these are just dumps of whatever it was at the time the save was made. Since whatever memory allocation function they used back then (I'm guessing malloc() ) would be storing the graphics at different offsets each time the tactical engine boots up, these would have to be replaced anyway. -NKF 02:00, 21 February 2011 (EST)


 .text:004178EC
 cur_unitref_addr = vf_unitref_dat;
 i1 = 80;
 do
 {
   if ( cur_unitref_addr->unitType != -1 )
   {
     unittype_offset = 8 * cur_unitref_addr->unitType;
     pck_addr = *(a_allocated_pck_array_dword_4ADE40 + unittype_offset);
     tab_addr = *(a_allocated_tab_array_dword_4ADE44 + unittype_offset);
     cur_unitref_addr->pck_ref_off02 = pck_addr;
     cur_unitref_addr->tab_ref_off06 = tab_addr;
   }
   cur_unitref_addr = (cur_unitref_addr + 124);
   --i1;
 }
 while ( i1 );
This called each time after setting up or loading UnitRef table. So according this code you can wipe these bytes without any effect, since these values overriden each time.--Volutar 03:13, 21 February 2011 (EST)
The save games contain a lot of stuff that's only relevant at runtime, on the basis that it was easier just to write (and then later read) these arrays straight to/from disk then it was to reformat them each time (sorta like how the entirety of MISDATA.DAT gets saved/loaded despite most of it being irrelevant most of the time). I'd been suspecting these to be pointers ever since Seb found the one in UnitPos, but I had no idea what they were pointing at, and I doubt I'd've ever worked it out. -  Bomb Bloke (Talk/Contribs) 07:11, 21 February 2011 (EST)

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)

Loftemps.png

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)

According my investigations Field52 refers to loft table to determine traced fire line collision, while Field48 used as "unit radius" when probing unit tile for sight or fire possibility, and it should be located inside of loft crossection. If its value will be beyond loft, LOF and LOS will fail at probing of unit "surface" (only central voxel could be aimed). --Volutar 23:58, 18 April 2011 (EDT)

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 0x4A (74)

It seems to be some kind of AI mode, which has 4 phases - 0,1,2 and 3. Code at .text:004016C0 (CE version) shows its range. --Volutar 02:00, 21 February 2011 (EST)

While taking a browse through the pre-release game executable, I found these strings listed together in a clump:

  • Patrol
  • Sniper
  • Combat
  • Escape
  • Guard
  • GoUfo
  • Finding Route
  • Set Patrol Point
  • Moving
  • Firing
  • Evaluating Mode
  • Final Facing
  • Attack Attempt
  • Find Fire Point
  • Select Target
  • Find Cover
  • Partial Cover

It struck me that the first few could relate to AI modes. Some aliens are known to choose a route node and stick with it (gaurding), and when unarmed, they'll usually run away (escaping); aliens will patrol when they don't know the location of X-COM units, though this seems to halt when turn 20 passes. Presumably these activities can be mapped to the four values. -  Bomb Bloke (Talk/Contribs) 09:20, 6 February 2011 (EST)

That's a great find, BBloke. I never looked at the demo exe. While the debug fonction was deleted in the release, it permits to locate the basic AI fonctions in the code. So we have: AI_patrol_mode (0x4A = 0) at 0x0407D60, AI_Sniper_mode (0x4A = 1) at 0x04081A0, AI_combat_mode (0x4A = 2) at 0x0408430, AI_escape_mode (0x4A = 3) at 0x04067F0 and even the AI_evaluation_mode at 0x0408430, which fills offset 0x4A when it is equal to something else. Other functions can be found as well with the debug info. Fantastic. Now we could try to make AI take cover from time to time, instead of making a stupidly exposed target.--Kyrub 06:02, 13 April 2011 (EDT)

Definitely a great find. Having 5 AI modes makes sense and looking at the other text I think it lists actions/moves/options for each mode: Patrol (Set Patrol Point, Finding Route, Moving), Combat (Attack Attempt, Find Fire Point, Select Target, Firing, Find Cover), Sniper (Evaluating Mode, Final Facing), Escape (Moving, GoUfo, etc.) and Guard.
I'm trying to correlate this info with the /ROUTES files, especially the entry called 'flag' - I remember a post a long time ago that those values determined the rank of the aliens that could use them. What I'm wondering is if there's a relation between the map location (and node 'flag' value) and the value found on UNITREF.DATHobbes 10:47, 26 January 2012 (EST)
The values and modes are this: 0=patrol,1=sniper,2=attacking,3=escaping,4=guard,5=returning to UFO. At least that's what I'm coming up with. --Zombie (talk) 01:12, 30 May 2015 (EDT)

Offset 0x6F

This offset seems to be corresponding for runtime "Attacking" state, not final /0 for unit name. When 1 units drawn with weapon helded in fire position, when 0 - ordinary.--Volutar 17:15, 26 February 2011 (EST)

Well spotted. :) -  Bomb Bloke (Talk/Contribs) 00:43, 27 February 2011 (EST)

Offset 0x70 (112)

It seems to be used in realtime only as "already acted" flag for civilian and alien units...--Volutar 09:19, 27 March 2011 (EDT)

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 0x77

This isn't field at all. It just ain't even initialized anywhere, so it's obviously a garbage field. I haven't found even one place where it be used...--Volutar 06:52, 27 March 2011 (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

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? - Hatfarm

They are indeed appended. My battlescape editor deals with TFTD's UnitRef by just adjusting for the larger record size, and then ignoring the extra bytes completely - didn't need to do anything else to make it all match up. I've yet to actually look at some sample values in order to work out what they might be for.

Incidently, you can insert signatures into your postings using four tildes (~~~~). - Bomb Bloke 21:48, 20 January 2010 (EST)

TFTD's extra bytes

It appears that byte 126 is a bit flag array of some sort as I have mostly seen values of 1 and 0 for it, but others have appeared. I saved a single mission at several different times and each one had 0 or 1, but a terror mission save had some different values for this, Like 0x20 and 0x4F. I tried adjusting it and checking the saved game, but nothing seemed to change...

Byte 124 I've seen values of 0,4,6,7,0x0A and 0x0E. No idea what these mean, and changing them did not do anything for me.

They appear to only be for Soldiers as well, none of the aliens in any of my saved games have values for these. Hatfarm 15:16, 5 June 2010 (EDT)

124 may have something to do with the air-bubbles that trickle up from soldiers when they're underwater - an animation counter, similar to offset 8 of SMOKREF.DAT, but with a higher range (0-15, probably). Granted, there's no real reason to keep track of bubbles when saving the game, but they have to be tracked somewhere at run-time, and this seems to be the logical place (the save files are just raw dumps of RAM anyway).

In theory, if you set this to the same value for all soldiers (say 5), on loading the game, they'd all have identical air bubbles over their heads. - Bomb Bloke 22:26, 5 June 2010 (EDT)

You're right, I set them all to 5 and they were all in the same place bubble wise,. However, they don't all "rebubble" at the same time. Good call BB. Hatfarm 02:16, 12 June 2010 (EDT)

I'd guess they "rebubble" randomly, though it may be a rather more elaborate setup - bubbles might appear more often for soldiers with lower stamina levels, maybe, to indicate they're out of breath.

Unfortunately, I can't think of anything else TFTD adds that would warrant using those extra bytes at the end of the file. - Bomb Bloke 05:20, 12 June 2010 (EDT)

I'm guessing it's a 2 byte count at least, which would account for the 124 and 125 bytes. If I think of anything for the others, I'll let you know. Hatfarm 01:07, 13 June 2010 (EDT)

Offset 0x2B (43)

This value is set for some % of alien units at map initialization stage (depending on mission type, alien craft type, and alien rank). If this field set to 1, the unit is spawned at "zero" (scout) point, otherwize appropriate rank spawn points are used. Though, if all rank points being occupied - every next unit spawned at any "zero" point. This value also used for choosing AI patrol path.

Apparently it can be called "AI_Wanderer_Flag" or something like that. --Volutar 04:40, 26 September 2011 (EDT)

You say it is also used for choosing AI patrol path. Does it mean that once a unit is assigned as a "scout" it will keep patrolling only on scout ranked nodes for the rest of his life? Does it also work the other way around, if a unit is not marked with this flag, it is not allowed to patrol on scout nodes? --Daiky 05:56, 6 January 2012 (EST)
Yeah, someone mentioned something about that a long time ago on the xcomufo.com forums. Certain aliens are 'flagged' for something at the beginning. But this can be merely a way for the engine to ensure that certain aliens remain outside, and not related to the AI.Hobbes 18:20, 8 January 2012 (EST)

From what I have been able to uncover about this offset: when this byte is set, which is determined by comparing the value of offset 5 of the loadout table against a random % number, the alien cannot be killed by a UPS explosion, if within the blast radius of one.

.text:0041F0E0 mov al, [ebp+2Bh] ; set by alien loadout byte 5 vs random %, ebp=current alien unitref offset
.text:0041F0E3 mov word ptr [esp+3Ch+var_28], cx
.text:0041F0E8 test al, al
.text:0041F0EA jz short loc_41F0F5
.text:0041F0EC mov [esp+3Ch+var_28], ebx
.text:0041F0F0 mov esi, 6
.text:0041F16E cmp si, 6
.text:0041F172 jnz short loc_41F19E
.text:0041F174 mov edx, [edi-0Eh] ;edi=next unit in OBPOS byte 0Ah after the one being evaluated
.text:0041F177 mov eax, 0FFFFFFFDh
.text:0041F17C and edx, eax ;this sets bit 2 of the unit's 0A byte to 0
.text:0041F17E mov cl, dl
.text:0041F180 mov [edi-0Eh], edx

Since the alien is marked as disabled, it is skipped in the routine to apply explosion damage to victims. Since its items are still assigned to it in OBPOS, they are skip by the item destruction routine. ESI is either set to 6 as determined by the value of 2Bh or will increment up along another pathway. Tycho 12:27, 18 March 2013 (EDT)

Retrieved from "https://www.ufopaedia.org/index.php?title=Talk:UNITREF.DAT&oldid=64762"