Difference between revisions of "Talk:UNITPOS.DAT"

From UFOpaedia
Jump to navigation Jump to search
Line 64: Line 64:
  
 
- [[User:Bomb Bloke|Bomb Bloke]] 20:01, 9 February 2008 (PST)
 
- [[User:Bomb Bloke|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
 +
 +
~ [[User:Renegrade|Renegrade]] 12:02, 22 August 2010 (EDT)

Revision as of 16:02, 22 August 2010

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

~ Renegrade 12:02, 22 August 2010 (EDT)