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.
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)
MTR - re: death of units. If I'm not mistaken you also need to set a flag in UNITPOS.DAT to make sure that the unit is dead.
- NKF
Indeed, you need to flag offset 10, bit 2 to false (0). Health and the like has no effect on the matter.
Easiest way is to just use my editer. ;)
- Bomb Bloke 05:50, 6 November 2006 (PST)
Let me give it a shot, BB. Is there a link to your editor? (Where'd the link to Utilities go since the Main Page was reorganized?)
So, that one UNITPOS bit is the only thing needed to kill someone dead? And they'll already be dead, with none of the Morale effects I saw? That was so odd, how they die twice if you set UNITREF Current Health to 0.
Gah, somehow I totally missed your work on Width (above). I've been blithely writing about it at GEOSCAPE.EXE offsets [22] and [23]. Wow, that's extremely odd... UR[48] at >36 makes them disappear, but no accuracy change? And [52] at >36 doesn't do that, nor anything at all apparent? How so very odd. I wonder if [48] and [52] are interdependent somehow... [52] might make them disappear, depending on [48]. Just a thought.
As an "area" calculation (height X width in table above), 37 doesn't make sense... since Sectoids are 16 high, it would need a width of 16 to become "bigger than 255", not 37. But then, the area calculation is total conjecture.
I see from LOFTEMPS.DAT that tiles are of pixel dimensions X 16, Y 16, Z 12. However, that's for terrain. I can't seem to find pictures of aliens per se - or are they simply sprites with no actual LOFT (Line Of Fire Template) pixel grids, per se? If they do have pixel grids, maybe the dimensions could help suggest what these Unitref values do?
- MikeTheRed 08:00, 6 November 2006 (PST)
A dead unit is one that isn't in play. This can be the case regardless as to whether they have health or not. You can find the editer on StrategyCore.
Re the area calculation, even if the result was higher then 255, UFO is noted for just looping back around to 0. Also note that a tile has a height of 24 units. Although there are only 12 loftemps entries per tile, they each cover 2 layers.
So far, there isn't any evidence to suggest that units use loftemps, though it wouldn't surprise me if they do. Well already know how to affect their height, at least.
- Bomb Bloke 14:15, 6 November 2006 (PST)
Thanks for the LOFT notes, BB. More to think about.
Arg, I get an error when trying to open your bb_mapedit3.zip ... is it just me? (is there a new version of zip??)
Does your Editor only edit a given savegame? (Was that just the custom uniform mod you were talking about with Zombie that mods other things?) I don't want to muck with anything but a savegame without knowing about it (thrice burnt by XcomUtil!).
By the way, I am doing Firing Accuracy testing and seeing some interesting but odd numbers. Remember that ultra cool numeric tileset you made for explosion testing? I could really use something like that, but with a twist. Particularly I need some walls (in addition to ground) that reflect damage. Just a simple north wall is enough. The point is to see the spread of misses. I seem to recall there's only so much terrain storage space... I expect a lot more hits on the walls than ground; maybe a 9:1 ratio. It's also ok if the numbers "wrap around" because this will only happen in a heavily hit area, making it clear where it transitioned. What I'm after is a "silhoutte" of misses (including ones that hit ground). Start the counting with 1 and go as far as you can. If you want more details before starting, just ask.
If you don't have the time to do it, I understand totally. I'll still have plenty of results... there just won't be as much understanding of why they are the way they are.
- MikeTheRed 17:12, 7 November 2006 (PST)
Most likely your download got corrupted. Try it again. I haven't spotted any updates to the ZIP format in years, though you could try an update if all else fails.
Neither the uniform mod or the editer changes anything besides save files. Both however add the files MAN_A.SPK through to MAN_N.SPK, and modify save files so that they get used.
The tileset already contains walls for you to use. To implement them, either use my editer on one of your savegames which uses the tileset, or run Diashiva's Map Editer on the MAP files. In addition, you'll find the file "desert.exe" in your terrain folder, which allows you to easily modify the armor values of the tiles.
The walls aren't numbered, however, but they don't need to be if all you're testing is where the shots go. Set the armor to 1, and if the wall gets destroyed, you know it was a hit. Also keep in mind that the chances of the ground being hit depend on how high the shooter is in relation to the target.
- Bomb Bloke 23:34, 7 November 2006 (PST)
Your editor opens fine now, and I see my previous download was too small... apparently I didn't notice an incomplete download (blush). Thanks for the note re: what your apps change. Almost nothing except the savegame... good deal.
What I'm asking is specifically whether you might be able to make numbered walls. Like you did for ground. So that I can see not just whether they're hit, but how often. (I meant a distribution spread, sorry.) Having both numbered walls and ground would be best. Walls only would be best, if only one can be done. But I repeat, it's not critical. Basically it will probably help in making a precise formula governing in-game accuracy... but it won't change the actual results, which are more than enough to see how it works in general. (Actual accuracy can be very different from the stated accuracy, in complex ways.)
- MikeTheRed 15:13, 8 November 2006 (PST)