Talk:UNITPOS.DAT
Just a note:
Bullets fired from large units always go from the primary quarter - i.e. the very first unit in unitpos - or the top-left quarter of the unit (relatively speaking, the top most quarter on your screen).
I think the bullet origin is higher than the unit's hit-box (to mimic firing from a turret) or is at least offset so that it doesn't strike its other quarters.
Until more information is gathered, I don't think the bitflags that flag sometimes for tanks would determine where the bullet is fired from. Sorry, yet another bit to identify... oh well.
NKF 02:04, 15 Oct 2005 (PDT)
I just compared two unitpos.dat files. One was where a Chryssalid was not spotted. The other was after the Chryssalid was spotted. The only difference between the two files was offset 10 (column 11). Unspotted: value of 34 (100010), spotted: value of 35 (100011). Not sure how that fits in the offset 10 description in the article page so I dumped this info here for now. Someone with more knowledge of bytes, hex, dec and bin please look this over and try and incorporate it into the text. -Zombie 23:59, 29 September 2006 (PDT)
Unexpected terminology. XCOM units always have the bit with significance 1 (bit 0) set, so equating "spotted" with "visible" makes the article summarize this without changes. --Zaimoni 10:23, 1 Oct 2006 (CDT)
- Agreed. The lowest bit is a flag for visible/spotted. I never noticed that that's where it was stored (and not in Unitref) until now... I'll add a little more text to the page so it stands out a little better (for slow folks like me!). Good work with FC, Z. P.S. You can delete all this after reading, if you want. --MikeTheRed 10:23, 1 October 2006 (PDT)
Comparing end-of-turn saves with the consecutive begin-of-turn saves: in patrol-mode AI with no X-COM units spotted during the turn, only position bytes are updated during patrol mode AI when no X-COM units are spotted. The other bytes aren't changed simply by expending energy on the next turn, either.
In particular, the visible/spotted bit (significance 1) isn't reset. Not worth updating until whether this bit can reset is inducted properly.
--Zaimoni 16:21, 1 Oct 2006 (CST)
Offset 8
Ok I did some comparing of offset 8 in saves. I seem to have confirmed what BB has said only that XCom units are set to 255 at the beginning of combat, and aliens are set to 1. As I placed in the article this seems to be a counter that increases every turn the unit goes unseen per se. Even if you 'sneak' up on an alien facing away from you, both counters will be reset (yours and the aliens). I'm not sure if an alien sneaks up on you if the counters reset or not. (I won't be shown the movement so I can't confirm)
I'm about 90% sure that even if a soldier cannot 'see' the other alien (out of sight range), but fires and hits the alien, including with AoE that soldier's counter is reset.
Now for my theory:
I think this has to do with the intellegence value in UNITREF.DAT offset 73. If this counter is greater than the value at offset 73, then they will not know where the unit is. Hence why all human soldiers have 'intelligence' set to 0, else you would know the location of aliens after they have moved out of your sight, and why their counters are set to 255 at first otherwise the aliens would know where you were to begin with.
Also, I think I might have noticed the AI run a bit faster once my soldiers were above their 'intelligence' value, the turns ran much faster when some of my soldiers hit the 6-8 mark. Thus maybe the AI only processes soldiers that fit this condition.
I remember reading somewhere about the aliens knowing where you are from the start, but I can't remember the details. Pi Masta 20:26, 14 February 2007 (PST)
I'm pretty sure you're right; I never tested to see what this value did over time, I just noticed it reset when you spotted something. I never twigged that it'd be to do with the intellegence byte as I only noticed it change when I spotted aliens (as opposed to when they spotted ME!).
The rumor goes that if the aliens know where one of your units is, they know where ALL of them are until they "forget". This has to be that counter byte. The only question I have is when it increments (when you have your turn, when the aliens have theirs, or both).
I suspect the byte is somewhat redundant in the case of aliens, as a seperate "visibility" flag (see offset 10) is used so you can keep track of enemies. Still, it might be interesting to boost one of your own units intellegence somewhat and see what happens.
- Bomb Bloke 03:15, 25 April 2007 (PDT)
Offsets 4-7
Looks like it's a raw memory pointer to unitref data. For big units, the 4 parts seems to points to the same data.
- Seb76
O_O
You've gotta be right; the values increment by 124 (the UnitRef record size).
(Could you please sign your Talk comments? Just stick in four consecutive tildes (~), the Wiki'll convert that to the time/date/username info).
- Bomb Bloke 20:01, 9 February 2008 (PST)
Is this the only reference tying UNITPOS and UNITREF together, aside from the position on disk/in memory? I'm guessing after the file is reloaded, they step through UNITREF, and use something there to determine whether or not there are 1 or 4 UNITPOS records associated and update this pointer correctly. But then how are UNITPOS records updated while the game runs? They must either have some internal memory-only linkage that isn't saved, or are always updating/using UNITREF from the state of UNITPOS? Having to search every UNITPOS's pointer to find the UNITPOS from the UNITREF record's side would be rather expensive if it has to be repeated :S
An additional thought occurred to me: there's 80 of these, and 80 of UNITREF, yet there could be as many as 320 UNITPOS records for a set of 80 large units in UNITREF. Could the crashes relating to overstuffed base defense missions have something to do with there being too many UNITPOS entries for the UNITPOS array? Perhaps in XCOM's early stages, UNITPOS and UNITREF were 1:1 and large units were added later?
~ Renegrade 12:02, 22 August 2010 (EDT)
- Yes, it's reasonable to assume large units were added later. The game should be smart enough to always count a large unit as 4 UNITPOS slots, but I'm not sure how much pre-release playtesting XCOM actually received. [The free manufacturing bug would have been pretty easy to spot by a systematic testing regime.] -- Zaimoni 23:47, 22 August 2010 (CDT)
- I think the easier way to look at it is that UNITPOS is what they work off primarily, then offset the index reference to UNITREF as necessary based on what sort of units are in the list. The UNITPOS entries do identify if they are large units or otherwise, and which segment they are. When you issue a move order, the game updates the first segment (the primary quarter, which is also the only one they seem to base almost all of their collision detection on), then just updates the position of the next three segments accordingly. Not sure why they ended up using this system as it would have been easier to handle one line of data for all units rather than several for a single unit. This is just conjecture, but one of the possible reasons for this may be to speed up rendering the units on the isometric map. By having the dummy units in UNITPOS, the game just has to check through UNITPOS for each tile it's rendering and simply draws the unit that it comes across that is occupying the tile. If they only had one record per large unit, each tile that is redrawn would have to go through UNITPOS/UNITREF to check if it's a small or large unit and draw it if it's on the same tile. If it's a large unit, check if any of its projecting sides are in the current tile. I imagine all that overhead would've made the rendering a bit slower. Especialyl on the x80286/386 machines that this game was built to run on. Again, that's just guesswork on my part.
- I'm sure there are a heck of a lot of bad programming practices used back then which are not acceptable with today's standards in programming. However, for something that was basically started by two guys in their garage (that could be an exaggeration, of course!), we still ended up with a fairly decent game. Would be nice if we ever got the opportunity to debug the source code. -NKF 03:43, 23 August 2010 (EDT)
Flag field 10 (0x0a)
Actually this is 32bit value, but used only first byte. And bits 3-4 (mask 0x18) isn't a bitfield, it's rather offset to corresponding part of bigunit.
So in memory there are 4 small unit for each bigunit:
0x00 0 top-left subunit 0x08 1 top-right subunit 0x10 2 bottom-left subunit 0x18 3 bottom-right subunit
When finding very first "sububit" of any selected part of bigunit: first_subunit = subunit - (subunit.flag >> 3) & 3;
bit 7 (mask 0x80) used for reaction fire (changed in runtime). Normally reaction fire works only for enemy units within viewsector. But when this flag is set, your unit become _revealed_ even for reaction fire of units turned away (who have this flag). This flag is set when unit got hit by someone (even from friendly fire or explosion). Presumably this bit mean reaction bonus, like "waking up" or extra cautious. --Volutar 05:31, 10 April 2011 (EDT)