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)
I'm sorry, but this is one thing the game engine won't let me pull off. The reason is that when a tile is hit with a projectile, it takes a random amount of damage - 25% to 75% of the weapons capabilities.
The "armor" of each wall would need to be at most equal to that 25% mark, to ensure that each and every shot made a mark. However, if the dice roll comes out at 75%, then the tile will switch three times, not just the once - Making it impossible to get any trustworthy results after the very first shot had been made!
In case that that doesn't make any sense, I'll simplify it somewhat: At best, tile counters will go up by a random amount, from 1 to 3, with each shot. Therefore, to get any accuracy, you'd need to make a shot, then reload the map, and repeat - Making any shot counter system that counts above one, redundant.
I've crafted a suitable map, and the logger will be the work of just a few minutes. However, I'm stumped as to which format to use to save the results. Usually, I go for comma seperated data, but in this case the data is in the form of co-oridinates...
If there's some sort of 3D vector program that would be suitable to display the lines of fire, then it'd be great if I could get hold of the file format. Otherwise, I'll just dump the co-ords any old how, and write a program to show minimum/maximum/average/etc firing angles after.
- Bomb Bloke 20:42, 10 November 2006 (PST)
Hmm, well, I had been thinking of using weapon strength 1 and wall armor strength 1... the wall would take a hit half of the time, and I'd just take into account that I was only seeing half the hits, on average. It's much better than nothing, even if it's not a perfect counter.
What I want to see is things like, how wide the shots miss by, whether misses are equally spread from farthest left to farthest right (like, a simple random roll for the angle for misses), or whether they're concentrated near the intended target, or what. There appear to be two components to accuracy, shots that are rolled as hits, and shots that are rolled as misses; the question is the degree to which a miss roll actually hits because it's random-miss angle happens to intercept the target anyway. So the equation for predicting hit percent has at least two terms, and may need more... there may also be percent of rolled hits that actually miss, in addition to this apparent percent of rolled misses that actually hit. All of which varies by distance, of course.
For this, then, I would've liked a "wall counter" map, even if it's not perfect. By the way, I really doubt I'd need to count to more than 100 for any given tile or wall, given my setup of ammo count etc. If you can do the wall, I'd still be very interested in it.
I'm intrigued by you other suggestion, but am not sure exactly what your logger will be counting. Anything that would require me to save and reload after each shot would greatly increase the testing time, though. If it did require that, is there a way to entirely automate it, including the save / reload / fire? For my testing, I'm usually firing 2,000 shots per variation on distance and final firing accuracy... and there are a lot of variations I want to test. If you could explain more that's fine - or just let me give it a whirl and it ought to explain itself, eh? Even if it does require reloading, there may be instances where I'm checking one particular min or max sort of extreme, where even low numbers will be ok (like when we tested the floor and ceiling for psi attacks; this needed less repeats than testing within the "attack curve" itself).
I can import results data from a .CSV, if that's something you were saying.
You can email it to mikestar at speedfactory.net or upload it to SC.
Thanks for anything you can do! - MikeTheRed 07:13, 11 November 2006 (PST)
Weapon and wall strength of 1 doesn't work. Remember, the weapon can only deal a maximum of 75% of it's rated damage, so with that setup the gun'd never make a mark.
You could set the weapon strength to 2, and the wall strength to 1. That'd give you 50% accuracy. But that's just not good enough when you can record 100% of shots made so much more easily. Sure it slows things down a little, but in my view that's irrelevant. Accuracy is everything.
It's still difficult to tell whether a shot that hits the target was perfectly aimed or not. One way might be to create some special tiles using the maps in LOFTEMPS.DAT to partially mask the alien, which would prevent anything but an exact shot from reaching the target. That'd take a little while to do, so I'll leave that idea for now.
The idea of the logger is to simply record where each shot ends up. If you know where the shots were made from, then this can easily be used to work out what the angle of each shot was, with a decent (but still limited) amount of accuracy. Though there's no reason why the logger can't work out the angles and record those, too, so I'll just scribble something up tonight to spit out those with the co-ords.
And yeah, full automation is my intention. I wouldn't do it any other way. ;)
- Bomb Bloke 22:09, 11 November 2006 (PST)
Sounds great, man. Right, a weapon strength of 2 is no problem. My brain was still thinking in terms of explosion damage, laugh.
In lieu of questions, let me see what you've got... it sounds real intriguing. In the meantime - hoping for a goodie from ya - I've been working on a boundary question for which numbered tiles (and probably your util) are irrelevant. Specifically, the lowest final accuracy that guarantees a hit, vs. distance. It's almost done.
Standing by! - MikeTheRed 22:20, 11 November 2006 (PST)