UFOpaedia - User contributions [en]

Talk:OBDATA.DAT

2012-10-14T13:39:38Z

Zaimoni:

Would anyone know how to change the TUs needed to work the psi-amp? I don't see anything in OBDATA (all its TU fields are set to 0). It would be helpful to [[MTR_Psi_Testing|psi testing]]. NKF? ---[[User:MikeTheRed|MikeTheRed]] 16:29, 7 September 2006 (PDT)

:In case someone is still interested, I located these pieces of code that may be related to psi attacks (note that 25 = 0x19) :
.text:0041F163 8B 15 88 3E 4A 00 mov edx, currentUnit_pUnitRef
.text:0041F169 80 7A 0C '''19''' cmp byte ptr [edx+0Ch], 25 ; current TUs
.text:0041F16D 0F 82 94 01 00 00 jb loc_41F307
:and
.text:0041F230 A1 88 3E 4A 00 mov eax, currentUnit_pUnitRef
.text:0041F235 80 40 0C '''E7''' add byte ptr [eax+0Ch], -25 ; consume TUs
:(-25 = 0xE7).
:You may want to change the values I hilighted and see what happens when you try to panic a unit ;-)
:Same for mind control:
.text:0041EE89 80 7A 0C 19 cmp byte ptr [edx+0Ch], 19h
:and
.text:0041EF55 80 40 0C E7 add byte ptr [eax+0Ch], 0E7h
Have fun! [[User:Seb76|Seb76]] 14:39, 28 April 2008 (PDT)

IT WORKS. Seb76, you're a genius. TUs for MControl and MPanic, tested. Just one glitch, the pop-up menus show the old values. Could you please tell us what more should be changed? --[[User:Kyrub|Kyrub]] 16:44, 30 August 2008 (PDT)
----

Unfortunately obdata doesn't store all weapon stats. Unique actions like the costs for priming grenades, throwing stuff, mind probe, psi amp, etc are tucked away in tactical.exe. Hmm, I'm positive that they can be located, but there are so many iterations of similar values that it could take a long while to discover them.

What could make thi worse is the possibility that these in-built actions (perhaps even the in-built alien melee attacks) will not be clustered together near each other.

- [[User:NKF|NKF]]

----

Arg. Well it's not a real big deal. The psi equations are now known quite well; it'll be posted shortly. Reducing psi-amp TUs would make it easier to ultra-tune the psi equations, but it wouldn't make any difference to players. Don't knock yourself out, but if you can find it, that'd be nice! Thanks for the reply ---[[User:MikeTheRed|MikeTheRed]] 18:40, 8 September 2006 (PDT)

==Lazar Blastas!!1==
It occurs to me that I have no idea what it is that allows the laser weapons to fire without a clip. At first I thought simply giving them a base power rating (something other weapons don't have) was the key, but apparently giving a clip a power of 0 doesn't render it useless...

Can someone provide some details on this?

-[[User:Bomb Bloke|Bomb Bloke]] 03:32, 4 October 2007 (PDT)

-----

Just a quick gaze at obdata, it seems that the laser's three clip types appear to be set to 255 (or -1 if we think in terms of signed values) to mark that they're not used and the item has a power rating. Apart from that, I can't see anything terribly out of the ordinary. - [[User:NKF|NKF]]

-----

To make a weapon clip-less and ammo-less you must set the clip references all to 255 like NKF mentioned. Make sure to set a power rating in [022] (if you want the weapon to do damage that is, this field is not a requirement for a laser-type weapon) and don't forget to switch the damage type in [031] from 255 to a valid number. That combination should create a laser-type weapon without ammo or clips. Hope that's what you were looking for. --[[User:Zombie|Zombie]] 20:02, 4 October 2007 (PDT)

-----

That sounds about right. Thanks guys. :)

- [[User:Bomb Bloke|Bomb Bloke]] 20:10, 4 October 2007 (PDT)

----

For clipless weapons, it might be enough just to set the ''first'' clip type to xff/255 - the game then doesn't look for the 2nd and 3rd clip type. I think. I did that by accident and I didn't check it terribly rigorously. [[User:Spike|Spike]] 19:39, 22 November 2008 (CST)

== Damage Type Hacking ==

A lot of the damage type behaviour seems to be hardcoded. For example here was some of my experience. (Maybe I made some mistakes, please check for yourselves.)

* If you hack a ranged weapon's damage type to Stun, it automatically becomes a Stun Explosion (area effect), like the Small Launcher Stun Bomb. (Tested 4 weapons)
** (To implement a non-area ranged stun weapon, give it weapon power 5 so it will never affect outside its target square. Give it high ammo and low %TUs - fire continuously!)
* If you hack a non-IN weapon to IN, it doesn't create a fire effect. (Tested AutoCannon - but as a laser-style clipless weapons as per previous section)
* If you hack a Grenade to Stun, it still does normal damage (no Stun) and it still destroys objects on the ground

This is a shame because I wanted to implement a Flamethrower or Tank/Flamethrower - an Incendiary weapon with a weapon power of about 10 IN, but %TUs/shot of 1% and infinite ammo. Oh well! I guess I can still do it using AC-IN and giving it low %TUs, high ammo capacity.

On the other hand, these things work as expected:

* Hacking a non-IN ammo type to IN seems to work. So I could hack AC-AP, AC-HE to IN. Both started IN-type fires. The hacked AC-HE did not damage objects.
* I could hack AC-IN to AP and it did not retain any area affect (or fire effect).
* I could hack all HC- ammo types to Stun and they did not produce fire, nor damage to objects, nor permanent health damage.

So maybe only ''ammo'' types (not weapon types) are allowed to generate area effects? (apart from Stun, as discussed immediately above).

[[User:Spike|Spike]] 19:39, 22 November 2008 (CST)

:It would be real fun if the blaster bomb could be turned into a huge area-of-effect ''stun'' bomb. :) -[[User:MikeTheRed|MikeTheRed]] 13:22, 24 November 2008 (CST)

== Fields 29 and 30 ==
They were mixed up with each other. Actually only value of field_29 matter, I haven't found any references for field_30 in the game code. And I don't know why field 30 was declared as "used". Alien corpse objects have different fields 29 and 30,and field30 always seems to be 0x0F or 0x0E which are rifle clip and grenade objects... . --[[User:Volutar|Volutar]] 13:01, 5 April 2011 (EDT)

== Field 0x2D (45) ==

This field used by AI for "Worth to take" estimation (function at address .text:004043E0). This value meant to be ''max_distance+5''.

worthtotake = obdata_addr->field_2D;
...
return (worthtotake - xc_BF_Get_Distance(v_Selected_Unit_Xpos, v_Selected_Unit_Ypos,
a_ObPos_DAT[obj_num]->x, a_ObPos_DAT[obj_num]->y)) > 5;

I've patched ObData.Dat file (replaced all field_2d values of 0x01 with 0x10) and observed AI picking up dropped items. I don't know why this field was disabled, though I can presume it could be heavily used as "bait" like cheat because this estimation function cannot "skip" items if AI unit already has attacking weapons and clips (maybe this "taking" function ain't even called if unit is fully equiped - I didn't check that). Probably it wasn't finished... Which is weird. --[[User:Volutar|Volutar]] 08:07, 26 March 2011 (EDT)

Firstly it fills some buffer (maximum length is 50 elements) with items, having flag field (+0x0c) with bit1 set (& 0x02). Then it calculates most worthy item as maximum of ''worthToTake/(distance+1)''. And only after that it will try to pick this item up if distance is less than ''worthToTake-5''. So this value is matter when AI choosing object to pickup. And of course when AI sees some attacking options, it chooses most effective. When estimating grenade efectiveness it thinks that 1 friendly unit equal 2 enemy. So if there will be 1 friend with 2 enemies at very close distance, AI won't even try to blow them up.--[[User:Volutar|Volutar]] 12:55, 1 April 2011 (EDT)

:This is really good news that you found this function for aliens to pick things up . Finding a way to activate it could eliminate the silly problem of unarmed aliens who won't pick up weapons. You are right there is a risk of a "item bait" tactic being used. The trick would be to make sure that item pickup is only used by aliens who are unarmed or (better) for aliens who lack a weapon that is effective against X-Com, to pick up a weapon that ''is'' effective. [[User:Spike|Spike]] 17:28, 28 March 2011 (EDT)

As far as I tested it, this pickup function ain't used when alien have some attacking weapon. So there are no ways to use it as bait cheat. And actual code doesn't require any patching, only "obdata.dat" does. I wish to know the reasons why they made insufficient this "AI combat value" for attacking objects, because I don't see any. --[[User:Volutar|Volutar]] 21:59, 28 March 2011 (EDT)

:So if I understand correctly, if you set this ''worthtotake'' field to any value above 5, the alien will move to pick it up, if the alien is unarmed, and the (worthtotake of object - distance to object) is greater than 5? Excellent. [[User:Spike|Spike]] 15:19, 29 March 2011 (EDT)

If you set this field 10, maximum ''worth distance'' will be 5 (10-5), value of 20 will become 15 tiles (very valuable weapon, like blasterlauncher). Value of 5 will be ignored and 6 mean, alien willtake item only if he stands over it (occasionaly, or just dropped due to panic)...
The only presumable reason of disabling this AI feature is - it makes "panic unit" a bit obsolete, because there are small chances they won't take dropped weapon back...
Apart from this "worth distance" AI has another conditions for taking weapon from ground, so if you set this field to 200, they won't be ALWAYS running all over for weapon if they haven't one. When I set this field 10, about 70% of aliens were taken dropped weapons back at first turn, and about 90% at second...

:So two questions that come up are, 1, Who will do this mod?, and 2, what values to set?
:Seb76 has said that he "doesn't do" data file fixes in his Loader, which is a shame. That means that we would want to prevail on BladeFireLight, the new maintainer of XComUtil, to incorporate this fix into a release of XCU. I do think it's fair to consider this a bug fix, though fixing it also doubtless "makes the game harder" (another category for XCU mods). At the moment, a Panicked alien is almost your ideal result in combat, at least against weapon-only aliens, because they are permanently disarmed and harmless. You can then use them for target practice, capture them, do what you like with no risk.
:In my [[Talk:Alien_Inventory_Use#AI_Weapon_Preferences_Table|research on alien weapon preferences]], when their main weapon is missing or out of ammo, they select weapons out of their inventory more or less in priority of the base damage of the weapon (highest first). So it would be consistent, and simple, just to copy the base damage value into this field 24. Question: if there are multiple weapons out in the open, does the Alien go for the nearest one, regardless of the field 24 value, or will it go for a more distant weapon, if the 0x24 value is significantly higher? If there's no difference in behaviour, then it makes no difference, you might as well just set all the value to 0x10, as in your tests. If it does make a difference, then it might be best to set the 0x24 value to something like the Firepower Factor of the weapon, to help the Alien make the 'right' choice of weapon. Most of the time, the weapon with the highest base damage IS the best weapon to use against XCom, especially as XCom is often heavily armoured. It's not clear if the AI recognises that auto weapons and HE weapons are more effective than their base damage alone suggests. So you could tweak the 0x24 values to reflect that. [[User:Spike|Spike]] 06:15, 1 April 2011 (EDT)

:: If we can agree on the details of the fix, I can try to splice it into my Python-based editor suite. [[User:Zaimoni|Zaimoni]] 00:02, 2 April 2011 (CDT)

::: OK, well my initial suggestion would be use the standard damage, field 0x16 (decimal 22) of the weapon (or of the clip loaded into the weapon). These values would work well given that the ranking of 'most worthy' is done by dividing by range+1. That means the unarmed alien will go a little further to pick up a Blaster Launcher.
:::Valutar, does the code check whether the weapon is loaded or empty? If not, that might be one of the reasons the developers abandoned this code. Also, can you tell if the AI uses any modifiers in selecting a weapon to attack with from out of the alien's current inventory? Does it add some % for HE weapons, subtract some % for Stun weapons, add some % for Auto weapons? If the AI uses any rule like that for selecting a weapon to attack with out of its inventory, we should use the same rule for selecting a weapon to pick up off the ground. [[User:Spike|Spike]] 15:24, 2 April 2011 (EDT)
:::: So this needs balancing. At least the formula is known, so an educated guess can be made before testing, but I'm not sure how to do a reasonable test. [Ideally we'd use a borg, but the effort required to write one would be awesome.] [[User:Zaimoni|Zaimoni]] 00:33, 3 April 2011 (CDT)

:::: Code does check 1) if '''ground weapon''' has ammo loaded, or 2) if alien already has ammo for '''empty ground weapon''', or 3) if '''ground clip''' fits to weapon he already has (to take extra clips for weapon with depleted ammo), and this is ONLY if he has free inventory slots to pick it up. And I don't know if alien will take weapon AND all clips for it if he stands over dead body with "full set"... Probably he will.--[[User:Volutar|Volutar]] 02:11, 3 April 2011 (EDT)

::::: That covers the worst cases where this could be exploited by the human. As long as only unarmed aliens will walk toward dropped weapons, and as long as the dropped weapons are actually viable to attack with, I think this is balanced and makes the game more realistic, and makes it harder, not easier. One more question - do we know if an alien that has built-in weapons, or active Psi, will attempt to pick up a weapon? This would be bad. Another question - will an alien pick up a weapon or clip if the alien has a weapon, but the weapon is empty and the alien has no spare ammunition in its inventory? If the answers to these questions are not known then I guess they could be discovered through testing. By the way, I think this patch would be a very good candidate for [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions|"Standard X-Com"]]. [[User:Spike|Spike]] 13:36, 3 April 2011 (EDT)

:::::: Only Sectoids, Snakemans, Ethereals, Mutons and Floaters are capable of taking weapon from the ground. Another answer is already given: ''"3) if '''ground clip''' fits to weapon he already has (to take extra clips for weapon with depleted ammo)"--[[User:Volutar|Volutar]] 14:07, 3 April 2011 (EDT)

: (Reset indent level). Sorry I missed that answer about completely depleted ammo. Your answer about which races will pick up weapons means there is the possibility that an alien with strong Psi capability would get killed by coming out into the open to collect a weapon that it doesn't really need. That would be a backward step. Maybe we could test for that. [[User:Spike|Spike]] 14:21, 3 April 2011 (EDT)

:: Another thing discovered, which could make you slightly happy. This "picking up" scanning function takes only objects in account, appeared on ground when it wasn't XCOM turn. It means player cannot force aliens to take them as bait. If alien killed some XCOM he could pick up his weapon as trophy. So, this is not the subject to concern about. By the way, when discovering this I found that ObjPos flagfield_10 was treated wrong: bit 0 flags those objects, which were dropped on player's move and bit 1 means aliens were the reason of objects appeared on the ground. --[[User:Volutar|Volutar]] 13:37, 5 April 2011 (EDT)

::: Just did a light test of this (setting the AI worthiness of weapons to their damage). Note that weapons carried by aliens stunned during X-COM's turn are ignored even if there are no agents covering the alien on recovering, so it's very likely the flaky field settings were not testably different than the designed behavior. --[[User:Zaimoni|Zaimoni]] 13:37, 13 October 2012 (CDT)

:::: This is maybe not a bad thing. Otherwise an XCOM sniper with a Stun Launcher (or a brave soldier with a Stun Rod) could potentially set up and stake out a perpetual killing ground. [[User:Spike|Spike]] 22:23, 13 October 2012 (EDT)

::::: Remember, the object chase code should only apply to disarmed aliens -- no perpetual killing ground without end-game psionics (at which point there are so many abuses it isn't funny). As I see it, the problem is that the AI can't have much mental state in the DOS version because of the memory model (64K per byte-addressable segment max). It wouldn't have been practical to calculate the patrol paths, etc. based on the map. --[[User:Zaimoni|Zaimoni]] 8:30, 14 October 2012 (CDT)

::::: That is: I don't think that an alien that just wakes up after being shot badly, should run away from the weapons it dropped because it was shot. It should pick them up immediately, at least if picking up items costs TUs (this doesn't use energy so it should not trigger reaction shots). The tactic seems to work well in Extender's Alien Pets mode. --[[User:Zaimoni|Zaimoni]] 8:39, 14 October 2012 (CDT)

Talk:OBDATA.DAT

2012-10-14T13:31:14Z

Zaimoni:

Talk:OBDATA.DAT

2012-10-13T16:21:59Z

Zaimoni:

Talk:WORLD.DAT

2012-08-23T08:05:29Z

Zaimoni:

== Terrain ==

// World.Dat = World Map Terrain

typedef struct worlddat
{
short QuadData[4][2]; // Coordinates of quadrilateral
unsigned long texture; // Terrain texture of quad
} WorldDat;

#define MaxQuads 768 // Observed values, XCOM = 666, TFTD = 733

QuadData/8 = realworld latitude and longitude numbers.

if QuadData[3][1] = -1 then the shape is a triangle and that entery is not used. (for you non programers QuadData[0] is the first so [3] is the forth.)

This may not be usefull for the wiki but I once wrote a program to detect what world.dat entry a givin ship was located in and therefor what texture/terrain file used to create the battlescape map. I have the function if anyone is interested in the math.

--[[User:BladeFireLight|BladeFireLight]] 21:24, 20 January 2007 (PST)

----

Gah, I just spent the last 20 minutes or so figuring this file out, wish I would have seen this before.

Wonder how it defines the countries since this file only seems to designate terrain types. Maybe indexed all the polygons in this file? Be tough to find it then...

Oh, and one thing. When QuadData[3]['''0'''] is -1 when it designates a triangle (and actually QuadData[3][1] is 0 as well).

I'll probably put this info on the page article here soon though. --[[User:Pi Masta|Pi Masta]] 19:42, 5 April 2007 (PDT)

----

Pi Masta, can you post an overlay of the TFTD world map? My first thought was that it was a representation of the quad's depth, but that doesn't seem entirely right either. Or perhaps it's a combination of terrain and height in the single byte? - [[User:NKF|NKF]]

----

Yeah it definitely holds terrain data. the TFTD map took a bit to recognize (aka make sure I was rendering it correctly) as it defines the oceans and not the land. I don't remember the depths that TFTD had, but didn't it also have missions on land as well? With differing land types? I never got into TFTD so my knowledge is limited.

I probably should upload a wire-frame version of the TFTD map, where you can see some of the overlaps. Well, I assume they are overlaps, otherwise they are really really small triangles.

This file is a bit of a pain to render as the points will cross the prime meridian thus X values will go from say 6 to 2700 to 2750 to 200, etc. in the same polygon line. I broke them up and split polygons when the difference was large and for TFTD it worked great. It was XCOM that was a problem and eventually I just excluded the troublesome polygons from being split (still rendered).

--[[User:Pi Masta|Pi Masta]] 15:34, 10 April 2007 (PDT)

----

TFTD has four depth levels, one of which is "surface". However the game only puts polygons on the water so presumably this file would only cover three levels (all land missions are terror sites).

For UFO, I did some value tweaking and came up with these referrences on battlescape terrain:

0 - Jungle
1 - Farm
2 - Farm
3 - Farm
4 - Farm
5 - Mountain
6 - Jungle
7 - Desert
8 - Desert
9 - Polar
10 - Jungle
11 - Jungle
12 - Polar

This does more or less match the [[TEXTURE.DAT|imagery]], but the problem here is that even with multiple missions on each terrain type I couldn't get a forest to appear. My thought is it has something to do with the position on the globe as all the missions I did were in the one area (south pole).

Values above 12 seemed to all use jungle as well, and looped through the usual texture images (oddly enough, I still had to add images to the set to prevent a crash).

- [[User:Bomb Bloke|Bomb Bloke]] 21:29, 1 January 2008 (PST)

----

If I'm not mistaken, the game picks between forest and jungle terrain depending on which part of the hemisphere you're on. Everything north of the Equator uses forest terrain while everything south of the Equator goes with jungle terrain.

- [[User:NKF|NKF]]

----

Is there any place in the article that we can elaborate that the 2880/1440 values makes for a resolution of 00°07'30"? I know it's not neccessary to the data file, but I think it's a nice little real-world statistic. --[[User:Danial|Danial]] 22:41, 29 January 2008 (PST)

----

Thank ye kindly NKF. :)

Ok, so I've gone and thrown all that stuff in the wiki page and nerfed the content re depth (as after quite a bit of testing I wasn't able to affect mission depth with WORLD.DAT values at all).

It might be a while before I play with this file again (mostly I mess with the battlescape data), so while it's fresh in my mind a few other points:

Where regions are located does seem to be controlled by this file... Kinda. For example, I got the impression that polygons 0 to 20 might be "America", polygons 21 to 35 might be "Russia", and so on and so forth. Move the polygons and you move the regions. As for which polygons are assigned to each region, that's gotta be in the executable (the border map you see by pressing space (or other buttons) is probably also in the executable, and is likely only cosmetic). If I get the time (and the right level of boredom) I'll try and create a list of which polygons point where.

I mentioned any TFTD location could produce a "Seabed Rubbish" or "Coral" mission, but I didn't mention the odds of these two turning up for any given polygon. Yeah, I didn't do enough tests for that... Polygons 0 and 8 could actually be set to use one of those two terrains (making one more likely to appear then the other).

By comparing the terrain lists to offset 10 in [[GEODATA.DAT]], I came up with these strings:

?? 01 01 01 01 07 ?? 06 06 08 ?? ?? 08 (UFO)

?? 01 02 03 04 05 06 07 ?? 07 06 01 04 (TFTD)

I was able to find the first one in the [[GEOSCAPE.EXE#Battlescape Terrain List|executable]], but TFTD's version eludes me...

- [[User:Bomb Bloke|Bomb Bloke]] 02:20, 31 January 2008 (PST)

== Borders data ==

FYI, in my UFO Defense Gold Edition executable (495 616 bytes), country borders data starts at offset 74AD4:
0xFFFF indicates the start of a new polyline, then each pair of words is a coordinate.
0xFFFE indicates the end of border data.

It looks like this (in my favorite tool ;-) ):
.data:00474AD4 GeoBordersData dw 0FFFFh ; DATA XREF: GeoDrawBorders+3�r
.data:00474AD4 ; GeoDrawBorders+C�o
.data:00474AD6 dw 221h
.data:00474AD8 dw 0FF43h
.data:00474ADA dw 238h
...
.data:00474DF4 dw 0FE71h
.data:00474DF6 dw 0FFFEh
HTH -[[User:Seb76|Seb76]], 31 January 2008

:Hey Seb76, you posted the information above. By any chance, did you also find borders for continents? XCOM must track them, because it tells you where you are when you start to make a new base. It could help Zombie and me relative to posting the percent of area devoted to different terrain types, because southern continents use jungle and northern ones use forest, for the same terrain code in WORLD.DAT. -[[User:MikeTheRed|MikeTheRed]] 20:38, 30 April 2009 (EDT)

The continents data is located at 0x474F38. Each entry represents a quad (4 values of 2 bytes) and a continent (2 bytes):

.data:00474F38 18 06 87 09 D0 FD 47 FE 00 00+geo_globe_zones structGlobeZone <618h, 987h, 0FDD0h, 0FE47h, 0>; 0
.data:00474F38 30 07 87 09 48 FE 0F FF 00 00+ ; DATA XREF: GetWorldZoneFromPos+10�o
.data:00474F38 80 07 5F 09 10 FF AF FF 00 00+structGlobeZone <730h, 987h, 0FE48h, 0FF0Fh, 0>; 1
.data:00474F38 00 00 3F 0B 30 FD CF FD 01 00+structGlobeZone <780h, 95Fh, 0FF10h, 0FFAFh, 0>; 2
.data:00474F38 00 00 3F 0B E0 01 D0 02 02 00+structGlobeZone <0, 0B3Fh, 0FD30h, 0FDCFh, 1>; 3
...
.data:00474F38 28 00 B8 01 40 01 DF 01 0D 00+structGlobeZone <0A28h, 27h, 78h, 1DFh, 0Dh>; 29
.data:00474F38 B8 01 2F 02 88 FF 4F 00 0E 00+structGlobeZone <28h, 1B8h, 140h, 1DFh, 0Dh>; 30
.data:00474F38 30 02 CF 02 D8 FF 4F 00 0E 00+structGlobeZone <1B8h, 22Fh, 0FF88h, 4Fh, 0Eh>; 31
.data:00474F38 B8 01 47 03 50 00 DF 01 0E 00 structGlobeZone <230h, 2CFh, 0FFD8h, 4Fh, 0Eh>; 32
.data:00474F38 structGlobeZone <1B8h, 347h, 50h, 1DFh, 0Eh>; 33

At 0x475090, the country data starts (using the same format).
HTH [[User:Seb76|Seb76]] 13:31, 1 May 2009 (EDT)

:Very cool! Listen, if you can capture the country and continent data, I can turn it into e.g. a spreadsheet that I'll post here. You can email it via my User link or post it as a new page with a hotlink here (so as not to clutter this one too much). If it's too much trouble, don't worry about it. The formats above are fine, but I have a couple of questions about what I'm looking at. If you're up to it. Thanks! -[[User:MikeTheRed|MikeTheRed]] 19:36, 7 May 2009 (EDT)
Concerning the format, the game uses a series of "quads" (xstart,ystart,xstop,ystop IIRC) and a continent number for each quad. It is quite crude, but the game crosses this data with the polygon data. So, for a given point it checks if it is on water or land, and then which quad it is contained into to deduce the continent's ID. [[User:Seb76|Seb76]] 17:12, 9 May 2009 (EDT)
:Thanks. Any chance you can send the two datsets to me? If not, I can get it. Sounds like you're primed to capture it, though. -[[User:MikeTheRed|MikeTheRed]] 18:25, 12 May 2009 (EDT)

== Terrain Type 12 in UFO ==
[[Image:Arctic_Modded.png|thumb|right]]

Heh, I see you already updated terrain type 12 in UFO, MTR. I didn't realize you did this so I modded world.dat so that the polar area of Siberia is type 12 instead of 9. Everything checks out like you mentioned. Anyway, just thought I should upload the pic so other people could see it. --[[User:Zombie|Zombie]] 19:15, 19 September 2008 (PDT) 

:Coolness. Actually, Pi's graphic on the WORLD page clinched it for me... look at where his terrain 12 is. I am in email with him concerning area calculations and etc. as we speak. -[[User:MikeTheRed|MikeTheRed]] 19:19, 19 September 2008 (PDT)

== Map Wrap problem with WORLD.DAT ==

I've been trying to help Zombie with determining how much of the globe is covered by the various terrains. But I've hit a brick wall with WORLD.DAT records' areas (triangles or quadrilaterals) that cross the "date line" in the middle of the Pacific.

X-COM "longitudes" go from 0 to 2800. The dateline is where 0 and 2800 butt up against each other in the Pacific. It is, of course, possible to have a WORLD record whose area straddles the line (think, Hawaii)... a little of the quad is east of the line, and a little is to the west of it. Mathematically, this can be treated very easily by adding 2800 to the X coordinates to the east of the dateline. That's easy.

The real problem is determining which of the records with huge differences in X coordinates (i.e., approaching 2800) '''''validly''''' cover that amount of area.

# As a first test (crossing my fingers that it would be this simple), I subtracted the lowest X coord from each record's highest X coord, to give a "max length estimate" (MLE) for each record. I was hoping most MLEs would be below, say, 1000, and all the rest would be up around 2800. But alas. While most records' MLEs were ~600 or less, and there was a spike of ~24 MLEs at 2700+, there was no "clear gap" between the low values and the high-end maxima. A histogram shows bin counts (with bins being 300 "wide") fall off a lot above ~600, but there is still a small number of counts in every bin, until you hit the spike at 2700+.
# As a second test, I thought "why not test to see if any records have one leg that's longer than all the others put together". In other words, some kind of discrepancy with the leg lengths. I thought myself clever... but alas. Each area "makes sense" in terms of being a closed figure, so not a single record had a discrepancy. In other words, if one leg was real long, there was always another one that was, too. This method couldn't tell between legitimately large areas, and illegimate dateline wrap-arounds.
# Finally I tried counting the number of legs for a given record that are greater than some arbitrarily high number (like 2600). This is sort of a variation on the first test; I was hoping for a clear division where most records have 0 very long legs, and approx. two dozen have two long legs. Foiled again, though... while most have 0 long legs and a cluster has 2 long ones, there are always a few that have 1 long leg (and no, they're not always triangles).

I can't help but think that there must be some easy way to do this, but I can't think of it. If I could do this graphically, it might be readily apparent... but I haven't worked with graphics at this very-basic level and don't know how to turn coordinates into a graphic figure. (Actually, I can do it, but it's just 4 points on an Excel X-versus-Y graph that aren't otherwise meaningful; they're not superimposed on a map of the globe or anything.)

Clear as mud? Does anyone have ideas? Pi Masta?? -[[User:MikeTheRed|MikeTheRed]] 17:21, 17 October 2008 (CDT)

:The only thing I can think of is a brute force method. Flag a record which have huge differences in the X-coordinates, then edit it so the terrain type is something easily recognizable (like mountainous), go in the game and verify where the record resides. There can't be anything more straight forward than that, no? My 2 cents.--[[User:Zombie|Zombie]] 21:32, 17 October 2008 (CDT)

Now there's an idea. Remind me... WORLD.DAT is not saved to the savegame slot, but I don't have to reload all of X-COM... I can just alt-tab to switch WORLD.DAT, and reload a "same old" GEO savegame, Right? ... Maybe it will get me past my mental wall of, not knowing how to handle these abstract coordinates, even. -[[User:MikeTheRed|MikeTheRed]] 21:51, 17 October 2008 (CDT)

:Correct, just reload a saved game while the game is running and presto, the map should be updated. By the way, approximately how many records have huge differences in X-coordinates? If there are a lot of them, a brute force method may take some time. But from what I remember from the file there are only a handful records which meet this criteria. --[[User:Zombie|Zombie]] 22:02, 17 October 2008 (CDT)

About two dozen. I'll take a crack at it; it's entirely possible that visualizing the first few may make things very clear. But give me a week or so. And if anybody has a brighter idea, jump in. -[[User:MikeTheRed|MikeTheRed]] 22:20, 17 October 2008 (CDT)

:So, all these records with huge differences occur around the "dateline", in the Pacific ocean where the game meshes the start and the end of the render together, correct? There isn't going to be huge tracks of land in the Pacific ocean, so couldn't you just pretend that the areas are small and do it that way? A couple dozen records are just enough to indicate they are Hawaii and other small islands surrounded by ocean. Suppose it couldn't hurt to double check the theory, but that's my take on it. --[[User:Zombie|Zombie]] 22:40, 17 October 2008 (CDT)

It fries my brain a little when I see that one coordinate of a record is an origin (e.g. X 0, Y +720), while the other coordinates are all over the place. A fair number of the high MLE records are like this. Is there a big strip coming down from the poles? Or around the equator? I think your idea of simply seeing what happens when you edit WORLD.DAT is a great idea. I didn't think of that approach... it's been too long since I sat down and hacked the game. But in this case, hacking the game supplies exactly what I said I couldn't visualize - seeing the difference superimposed on not just any map, but X-COM itself. Thanks bro. You owe me some excellent java. -[[User:MikeTheRed|MikeTheRed]] 22:57, 17 October 2008 (CDT)

:Ah, I forgot about the origins. In that case, yeah, there are some fairly large tracks of land which start at the poles and radiate down (or up, depending on the hemisphere). You could double check that by looking at the terrain type and verifying if it is 9 or 12. If you give me the record numbers which straddle the dateline, I could help you out by editing a few of them for you and marking it on the globe. That way you don't have to do so many of them. --[[User:Zombie|Zombie]] 23:22, 17 October 2008 (CDT)

== Which Prime Meridian? ==

Some clarification here, please. Comments above say that the game engine's zero longitude meridian, X=0, is somewhere around the (real world) International Date Line, in the middle of the Pacific. But if you look at the maps rendered from the WORLD.DAT data, they appear to start at (real world) Greenwich Meridian, at 0° longitude: England is right at the left of the map, presumably the start of the render. Which is correct? Did the Bros. Gollop start in Greenwich and number 0-359° East longitude (in eighths of a degree)? Or did they start around Hawaii and number 0-359° East longitude from there? [[User:Spike|Spike]] 16:33, 5 December 2008 (CST)
: Actually it was easier just to go and find out. The X=0 meridian is the real world prime meridian running through Greenwich, UK. This was determined by hacking my starting base location in LOC.DAT.

::Spike has it right and I have to admit - I made that mistake and have been posting that it's at the dateline, but in hindsight this was only an assumption based on how the XCOM Geoscape acted a little weird for me in the Pacific sometimes (plus I assumed the devs made it easy on themself). By coincidence, I just hacked WORLD.DAT today to address the wrap problem (see above) and indeed, it is at the usual Greenwich meridian (see my alternate [[Image:WORLD_DATwithTerrainChangedFor24SuspiciousAreas.DAT]]). Anybody is welcome to cleanup places where I said the meridian is at the dateline. -[[User:MikeTheRed|MikeTheRed]] 18:09, 5 December 2008 (CST)

::: Hey thanks MTR for clearing that up.
::: One more question - this is being a bit picky, but - shouldn't the correct range for longitude be stated as "2880 values, from 0 to 2879"? 2880 is the same as 0, and 'wraps' to 0, right? [[User:Spike|Spike]] 17:11, 6 December 2008 (CST)
:::: The precomputed trigonometry reference tables [[COS.DAT]] and SIN.DAT have lookup values for 0 through 2880, although 2880 indeed 'wraps' (has the same values as 0). I used these reference tables to decide what the authoritative range was. -- [[User:Zaimoni|Zaimoni]], 11:48, 7 December 2008 (CST)
::Sounds right. For the record, in WORLD.DAT, the minimum X value is 0 and the maximum is 2877 (in terms of what actually appears in the records). But it's an easy stretch to assume that the displayed coordinate system goes to 2879 (there just don't happen to be any corner points of areas that fall on 2879).
:::Cool, that nails it, Zaimoni. Thanks! -[[User:MikeTheRed|MikeTheRed]] 12:30, 7 December 2008 (CST)
::FWIW, I don't understand why "the resulting map could be said to have a spatial resolution of 00°07'30" (one-eighth of a degree)". To me, it makes more sense to compare it to degrees and minutes, and I can wrap my brain around something like this, better: "the XCOM coordinates have 13% of the precision of the real world's degree:minute value system (2880/(360*60) = 2/15 = 1/7.5)". Extending it to seconds seems arbitrarily harsh; it could also be arbitrarily extended to decimals of seconds - even harsher. Also FWIW there is, of course, a 2:1 relationship for longitude to latitude in the XCOM values (2880:1440), just like in real life (360:180). (Actually, 1441 and 181 values, but who's counting.)
:::Same here, I inserted the phrase "eighth of a degree" to soften up, and to get my own head around, the 'harsh' statements made previously by somebody that referred to 00°07'30". [[User:Spike|Spike]] 19:08, 6 December 2008 (CST)
::Interestingly, while we mainly use offsets on the wiki (values start at 0, not 1) because programmers do - even though counting starts at 1 for most of "the regular world" - here's a case where reality uses an offset, too. The Prime Meridian is 0, not 1. :P -[[User:MikeTheRed|MikeTheRed]] 18:36, 6 December 2008 (CST)

== AI Helpful Cheating ==

:Incidentally this [test above] also showed that the AI cheats and sends its missions to the area around your starting base. Even though I teleported my base from Hawaii to Casablanca at the start of the game, all the UFO missions still flew to the Pacific region in January. Then in February, all the missions shifted to North Africa or adjacent regions. The Pacific area went totally quiet. So the game "knows" where your base is, and plans the missions accordingly. [[User:Spike|Spike]] 17:08, 5 December 2008 (CST)

::The AI sending its missions in January near the first X-COM base is called "Giving the player a sporting chance." [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:18, 5 December 2008 (CST)

::: Not to mention making the game more fun and more playable. This is a well established principle, as evidenced by the fact that when the Daleks want to invade the Earth, they always start their attack in England, purely because that's where Dr Who lives. :) [[User:Spike|Spike]] 17:11, 6 December 2008 (CST)

:: I thought the Daleks did that cause they recognize Dr Who as the only force on Earth which can stand in their way?
:: It's not just January... the AI seems to give aliens a tendency to follow X-com around all through the game? I find that even in late game, the aliens seem to center on my original base, instead of a smooth worldwide distribution of activity.
:: Spike, your test has also proves that the aliens queue up their missions at the beginning of each month. Hmm... [[User:Jasonred|Jasonred]] 05:57, 2 May 2009 (EDT)

== World Area and Cylinder vs. Sphere ==

Ok Zombie, I finally finished all the math on the areas of terrain types in WORLD.DAT... I'd upload it here, but the Upload File link here is not working for me - is it working for others?

Anyway, I got a somewhat surprising result, that I'm hoping someone can help with. Apparently, WORLD.DAT is "straight up" areas; the XCOM devs did not control for sphericity per se (which is probably simply handled, for all practical purposes, by how it maps onto a "3D" globe in the Geoscape). Which is to say, when I calcuated areas, the poles got stretched way big, very much like the "cyclindrical projection" of the Earth seen in Pi Masta's "maps" on the WORLD.DAT page... and the terrain types of 9 (Ice) and 12 (Icebergs) account for 43% of all XCOM Land. Of course, this makes zero sense if you look at a globe (in XCOM or elsewhere). A quick check of the WORLD.DAT areas shows that Ice and Icebergs have an average latitude of 70° (this is if you take absolute values; otherwise South cancels North). Now, this is just an average of the latitudes of the centroids of each area, and doesn't take into account at all e.g. how large each one is (there could be a lot of tiny ones in Siberia, and a few huge ones at the Poles). Furthermore, it is 43% of the *land* found in WORLD.DAT - Ocean isn't accounted for at all (in XCOM terms, it is simply the absence of any WORLD.DAT land). But anyway, it does show that polar land in the Geoscape could definitely be way overestimated, if one takes spherical coordinates but treats them like a cylinder. Like I just did. :P

Anyway, to make a long story short... Would anyone know a way to "sphericalize" this data, so I can turn it into real-world areas? I'm not sure exactly how that would work - I used the Surveyor's Formula to get areas to begin with; would I have to back all the way up to actually using some variation of Surveyor's for a spherical surface - and WTH would that look like? Or would it be a close enough approximation to simply scale the area of each record somehow, based on the centroid latitude (average of its Y values)? Or maybe I can just straight up scale them relative to the Equator being 100% of area, the Poles being 0% of area? (None of the records actually have a centroid latitute of 90°, of course - in fact the largest ABS(centroid of latitude) is 85°.)

If I can get a handle on this, we could ultimately do a rough check of all my computations by comparing it against the [http://hypertextbook.com/facts/2001/DanielChen.shtml land area of Earth].

Help, anyone? -[[User:MikeTheRed|MikeTheRed]] 22:24, 20 November 2009 (EST)

: Well, latitude/longitude coordinates don't correct for sphericity either.

: The catch, here, is that the length of a degree of longitude varies by latitude. Recall that the scaling factor to convert the length of a degree of longitude at the equator, to a degree of longitude at latitude θ, is cos(θ). How to proceed from there depends on how you want to numerically model it (integration is feasible, while trapezoid approximations are easy to visualize and should be workable until very close to the poles.) -[[User:Zaimoni|Zaimoni]] 13:44, 21 November 2009 (CST)

I don't have intergration apps at hand. Cosine of theta. You bastard. Now I have to refresh myself on geometry, lol. Question: Does a scale from 100% to 0%, closely approximate real life -[[User:MikeTheRed|MikeTheRed]] 16:50, 21 November 2009 (EST)

: cos(0°) is 1 i.e. 100%; cos(90°) is 0 i.e. 0%. So it is a scale from 100% to 0%, it just isn't a linear scale. -[[User:Zaimoni|Zaimoni]] 11:02, 22 November 2009 (CST)

::Seems to me that to compute this on paper would take far too long. For example, say you were to draw one of the polygons, then scale each line of that polygon according to the latitude (multiply it by cos(latitude), I guess). You'd then be able to add up the resulting number of points covered, and get the area as a result... But this'd take far too long to do by hand.

::It may be that there's a formula that can be applied to determine the area covered by a given polygon to a spherical surface (still too much effort to do on paper), but off the top of my head I can't even think of one to do it with a flat surface, so getting a computer to do all the math in bulk seems to be the easiest way.

::The results would end up approximate however you do it, because the real world isn't a sphere.

::- [[User:Bomb Bloke|Bomb Bloke]] 19:38, 23 November 2009 (EST)

Ok, so here's what I came up with for the 2D map:

2D map is 2880x1440 with 4147200 points total, with a land area of 1542330 points (37.189670138888886%).
00: Forest = 53876 points (1.2990933641975309% world area, 3.4931564580861427% land area), Jungle = 189766 points (4.5757619598765435% world area, 3.4931564580861427% land area)
01: Farm = 32441 points (0.7822386188271605% world area, 2.10337606089488% land area)
02: Farm = 134294 points (3.238184799382716% world area, 8.707215706106993% land area)
03: Farm = 72882 points (1.757378472222222% world area, 4.725447861352629% land area)
04: Farm = 138245 points (3.3334538966049383% world area, 8.963386564483606% land area)
05: Mountain = 13513 points (0.3258342978395062% world area, 0.8761419410891313% land area)
06: Forest = 346 points (0.008342978395061729% world area, 0.02243359073609409% land area), Jungle = 24708 points (0.595775462962963% world area, 0.02243359073609409% land area)
07: Desert = 105327 points (2.539713541666667% world area, 6.829083270117291% land area)
08: Desert = 23575 points (0.5684558256172839% world area, 1.52853150752433% land area)
09: Polar = 714710 points (17.233555169753085% world area, 46.33962900287228% land area)
10: Forest = 20530 points (0.49503279320987653% world area, 1.331102941653213% land area), Jungle = 18117 points (0.43684895833333337% world area, 1.331102941653213% land area)
11: Forest = 0 points (0.0% world area, 0.0% land area), Jungle = 0 points (0.0% world area, 0.0% land area)
12: Polar Seas = 269183 points (6.490716628086419% world area, 17.453009407843975% land area)

Now assuming those figures check out with yours, Mike, then (with any luck) these should also be accurate for a 3D map (the sphere):

3D map is 2880x1440 (kinda) with 2659696 points total, with a land area of 783210 points (29.447350373877317%).
00: Forest = 49970 points (1.8787861469882272% world area, 6.380153470972025% land area), Jungle = 189766 points (4.061178420390902% world area, 6.380153470972025% land area)
01: Farm = 24014 points (0.9028851417605621% world area, 3.066099768899784% land area)
02: Farm = 98378 points (3.6988437776347376% world area, 12.56087128611739% land area)
03: Farm = 56052 points (2.1074588975582174% world area, 7.156701267859194% land area)
04: Farm = 122488 points (4.605338354458555% world area, 15.639228304030848% land area)
05: Mountain = 10971 points (0.4124907508226504% world area, 1.4007737388439883% land area)
06: Forest = 324 points (0.012181843338486806% world area, 0.04136821542115142% land area), Jungle = 24708 points (0.41200197315783454% world area, 0.04136821542115142% land area)
07: Desert = 92444 points (3.4757355727872663% world area, 11.803220081459633% land area)
08: Desert = 19755 points (0.742754059110515% world area, 2.5223120235952043% land area)
09: Polar = 152979 points (5.751747568143126% world area, 19.532309342321984% land area)
10: Forest = 19957 points (0.7503489120561146% world area, 2.548103318394811% land area), Jungle = 18117 points (0.6355989556701217% world area, 2.548103318394811% land area)
11: Forest = 0 points (0.0% world area, 0.0% land area), Jungle = 0 points (0.0% world area, 0.0% land area)
12: Polar Seas = 87871 points (3.3037986296178214% world area, 11.21934091750616% land area)

Zaimoni, I used this formula to add up how many points the 3D map would be (2659696), does it look right to you? If so, then the rest of my scaling is probably accurate enough as well.

for (int i=-720;i<721;i++) worldsize[1] += (int)(Math.cos(Math.toRadians(i/8))*2880);

- [[User:Bomb Bloke|Bomb Bloke]] 07:12, 24 November 2009 (EST)

:: What's the target language? That controls whether you'll be nailed by integer division at i/8. (You want the highest-precision floating point available.) For Java, I would try something like

:: for (int i=-720;i<721;i++) worldsize[1] += (int)(Math.cos(Math.toRadians(i/8.0))*2880);

:: to try to get some automatic type conversions going without using an explicit cast on i. - [[User:Zaimoni|Zaimoni]] 10:35, 24 November 2009 (CST)

::: Whoops, I've spent too long dealing with integers. Well caught. - [[User:Bomb Bloke|Bomb Bloke]] 01:12, 25 November 2009 (EST)

: Rats, my percentage of polar land mass on the 2D map comes out at about 64%. Still 46% if I disclude the polar seas. Back to the drawing board, then. [[User:Bomb Bloke|Bomb Bloke]] 07:32, 24 November 2009 (EST)

Ok let me try it with Cosines used against the area of each record, based on the latitude of the centroid point for each area. One thing first, though - the WORLD.DAT page says "at the equator, each possible map location on the Geoscape occupies a square that is 111 kilometres on its side", but shouldn't it be an eighth of that? And for a WORLD.DAT record making a perfect square (0,0; 0,1; 1,1; 1,0), the area would be 193.6 km2? -[[User:MikeTheRed|MikeTheRed]] 23:06, 24 November 2009 (EST)

: Indeed, should be an eighth, as the game map is in eighths of degrees (distance between real world degrees of latitude = ~111km, varying slightly as you move around the globe). A WORLD.DAT record can't really be a "perfect" square anywhere (because our lines can't bend to properly fit the 3D shape on which they're rendered). But say you made a polygon of one unit squared at the equator, it'd be a square eighth of a degree, and so should be pretty close 193.6 km2 (192.5 km2 to my count). This changes wildly as you move towards the poles, as the distance between points of longitude shrink down to 0 as you move from the equator (unlike latitude, where distances remains roughly the same). [http://en.wikipedia.org/wiki/Longitude#Degree_length] - [[User:Bomb Bloke|Bomb Bloke]] 01:12, 25 November 2009 (EST)

P.S. Can someone remind me - is Polar Sea With Icebergs considered land, in the game (can make bases or fight UFOs there)? -[[User:MikeTheRed|MikeTheRed]] 23:10, 24 November 2009 (EST)

:Yup, you can build bases and visit UFO sites on the polar sea texture so it's considered land. Though, in some cases it's a little iffy (probably due to how the area is mapped out on the globe). --[[User:Zombie|Zombie]] 23:15, 24 November 2009 (EST)

Just for comparison, I got a global land percentage of 31.224.. The way I did it however also suffers from some mapping distortions, although not so big.. So 29.44 is probably not to wrong.. Method I used: pixel/color scan of cube.map generated images, rendered using a 3D UFO.world.sphere.. Additional data: north pole: 55.300, south pole: 21.774. --[[User:Mvgulik|Mvgulik]] 22:43, 25 November 2009 (EST)

: After scraping out a heap of integer based calculations my figures vary a bit, but they're still fairly close to what they were. I think my main problem is correctly determining when polygons cross the prime meridion and loop around to the other side: Get that wrong, and certain polys will be way out in terms of accuracy.

: Still, I figure a count of the mountain polys vs total world size should be a good benchmark. Don't think any of those loop. - [[User:Bomb Bloke|Bomb Bloke]] 19:17, 26 November 2009 (EST)

::Done them all for you. Marked the one's where your number is to high if I'm correct. Oddly mountain's is one of them. --[[User:Mvgulik|Mvgulik]] 16:26, 27 November 2009 (EST)
00: 5.7033% *
01: 1.0427%
02: 4.2849%
03: 2.9602%
04: 5.2986%
05: 0.4005% *
06: 0.3188% *
07: 3.9370%
08: 0.9793%
09: 3.0936% *
10: 1.0211% *
11: 0.0%
12: 2.1456% *
:: Giving it a second thought after comparing the numbers. I initially figured the cubemap distortion only worked one way(Up). But it probably works in both ways. So these giving values that can be above and below the real value your after. That more or less leaves only the polar regions with having a somewhat suspicious large difference.

== Flat Earth Projection ==

As noted under [[UFO Interception#Movement]]

''Your ship autopilot prefers to move along lines of latitude (parallel to the equator) for long-range travel. This is especially noticeable when charting trans-polar routes: the ship will circle around the pole instead of flying straight across it. You can shorten the route taken by directing the ship to several intermediate way points along a straight line towards your destination.''

A very clear example of this is if you take a craft at say 85 deg N, 0 deg E and set a waypoint to 85 deg N, 180 deg E (the opposite side of the pole). Instead of flying in a straight line over the surface of the earth, a great circle (in this case right over the pole), it travels along the 85th parallel.

I think the explanation for the waypointing behaviour is that the wayfinding uses what is known as the Flat Earth Approximation method of approximating a great circle. Basically it is taking polar coordinates of latitude and longitude on the surface of a sphere, and treating them as if they were x and y coordinates on a flat rectangle of 360 x +/- 90. The rectangle is 'wrapped' at 0 deg E = 360 deg E, but it does not wrap at the 'top', along the +90 deg N and -90 deg S lines.

If you imagine a craft on a flat rectangle of this type, at coordinates (0,85) heading to (180,85), it would travel along the y=85 line. On a flat plane, this is the shortest route, the Cartesian distance.

The Flat Earth method is a reasonable approximation for short distances nearer the equator. It is poor for long distances and near the poles. It's probably ok for interceptions, especially of slower craft by faster craft. The more exact methods of calculating a great circle course were possibly too expensive to be done continually during an intercept. However they could've been used for plotting paths to static waypoints, even on a 16 bit computer.

Note that the Geoscape movement engine itself is not Cartesian, it is fully aware of spherical geometry. The flat earth method is only a shortcut for the wayfinding, not a shortcut used for actual movement.

I think the behaviour at the pole cited in the example above is pretty much proof, but I guess a harder proof would be to find two cities at reasonably high latitude (away from the equator) that are on a roughly 45/135/225/315 degree bearing to each other, a reasonably long distance, then fly a Skyranger between those via waypointing. Check a gazeteer to find the actual distance and see how much the Skyranger distance (760nm per hour) differs. I'm not even sure if this is a valid test, I haven't thought it through enough. I have tested Skyrangers orbiting pole to pole and they give a very close figure for the correct radius of the Earth, that's why I believe that the actual movement model is accurate. Also, the waypointing model is accurate in the special case where you are travelling along a line of longitude (which is already a great circle). The equator is the only line of latitude that is also a great circle, so the waypointing is also valid when travelling along the equator.

[[User:Spike|Spike]] 20:06, 8 November 2010 (UTC)

== Latitude or longitude? ==

FYI:

Latitude
Latitude is used to express how far north or south you are, relative to the equator. If you are on the equator your latitude is zero. If you are near the north pole your latitude is nearly 90 degrees north. If you are near the south pole your latitude is almost 90 degrees south.

Longitude
Longitude shows your location in an east-west direction, relative to the Greenwich meridian. Places to the east of Greenwich (such as Middle East, India and Japan) have longitude angles up to 180 degrees east. Places to the west of Greenwich (such as the Atlantic and North and South America) have angles up to 180 deg west. For inputting to the satellite dish pointing calculator, longitude west figures need to be input as negative numbers.

--[[User:Volutar|Volutar]] 02:33, 23 August 2012 (EDT)

* The problem is that what is idiomatic English (latitude and longitude) does not describe the file contents (longitude and latitude). Until this edit war is thrashed out, I'd like the table to not be misleading should idiomatic English win out over factual accuracy. [Yes, earlier drafts had me lose my temper.] --[[User:Zaimoni|Zaimoni]] 03:04, 23 August 2012 (CDT)

Talk:WORLD.DAT

2012-08-23T07:38:21Z

Zaimoni:

== Terrain ==

// World.Dat = World Map Terrain

typedef struct worlddat
{
short QuadData[4][2]; // Coordinates of quadrilateral
unsigned long texture; // Terrain texture of quad
} WorldDat;

#define MaxQuads 768 // Observed values, XCOM = 666, TFTD = 733

QuadData/8 = realworld latitude and longitude numbers.

if QuadData[3][1] = -1 then the shape is a triangle and that entery is not used. (for you non programers QuadData[0] is the first so [3] is the forth.)

This may not be usefull for the wiki but I once wrote a program to detect what world.dat entry a givin ship was located in and therefor what texture/terrain file used to create the battlescape map. I have the function if anyone is interested in the math.

--[[User:BladeFireLight|BladeFireLight]] 21:24, 20 January 2007 (PST)

----

Gah, I just spent the last 20 minutes or so figuring this file out, wish I would have seen this before.

Wonder how it defines the countries since this file only seems to designate terrain types. Maybe indexed all the polygons in this file? Be tough to find it then...

Oh, and one thing. When QuadData[3]['''0'''] is -1 when it designates a triangle (and actually QuadData[3][1] is 0 as well).

I'll probably put this info on the page article here soon though. --[[User:Pi Masta|Pi Masta]] 19:42, 5 April 2007 (PDT)

----

Pi Masta, can you post an overlay of the TFTD world map? My first thought was that it was a representation of the quad's depth, but that doesn't seem entirely right either. Or perhaps it's a combination of terrain and height in the single byte? - [[User:NKF|NKF]]

----

Yeah it definitely holds terrain data. the TFTD map took a bit to recognize (aka make sure I was rendering it correctly) as it defines the oceans and not the land. I don't remember the depths that TFTD had, but didn't it also have missions on land as well? With differing land types? I never got into TFTD so my knowledge is limited.

I probably should upload a wire-frame version of the TFTD map, where you can see some of the overlaps. Well, I assume they are overlaps, otherwise they are really really small triangles.

This file is a bit of a pain to render as the points will cross the prime meridian thus X values will go from say 6 to 2700 to 2750 to 200, etc. in the same polygon line. I broke them up and split polygons when the difference was large and for TFTD it worked great. It was XCOM that was a problem and eventually I just excluded the troublesome polygons from being split (still rendered).

--[[User:Pi Masta|Pi Masta]] 15:34, 10 April 2007 (PDT)

----

TFTD has four depth levels, one of which is "surface". However the game only puts polygons on the water so presumably this file would only cover three levels (all land missions are terror sites).

For UFO, I did some value tweaking and came up with these referrences on battlescape terrain:

0 - Jungle
1 - Farm
2 - Farm
3 - Farm
4 - Farm
5 - Mountain
6 - Jungle
7 - Desert
8 - Desert
9 - Polar
10 - Jungle
11 - Jungle
12 - Polar

This does more or less match the [[TEXTURE.DAT|imagery]], but the problem here is that even with multiple missions on each terrain type I couldn't get a forest to appear. My thought is it has something to do with the position on the globe as all the missions I did were in the one area (south pole).

Values above 12 seemed to all use jungle as well, and looped through the usual texture images (oddly enough, I still had to add images to the set to prevent a crash).

- [[User:Bomb Bloke|Bomb Bloke]] 21:29, 1 January 2008 (PST)

----

If I'm not mistaken, the game picks between forest and jungle terrain depending on which part of the hemisphere you're on. Everything north of the Equator uses forest terrain while everything south of the Equator goes with jungle terrain.

- [[User:NKF|NKF]]

----

Is there any place in the article that we can elaborate that the 2880/1440 values makes for a resolution of 00°07'30"? I know it's not neccessary to the data file, but I think it's a nice little real-world statistic. --[[User:Danial|Danial]] 22:41, 29 January 2008 (PST)

----

Thank ye kindly NKF. :)

Ok, so I've gone and thrown all that stuff in the wiki page and nerfed the content re depth (as after quite a bit of testing I wasn't able to affect mission depth with WORLD.DAT values at all).

It might be a while before I play with this file again (mostly I mess with the battlescape data), so while it's fresh in my mind a few other points:

Where regions are located does seem to be controlled by this file... Kinda. For example, I got the impression that polygons 0 to 20 might be "America", polygons 21 to 35 might be "Russia", and so on and so forth. Move the polygons and you move the regions. As for which polygons are assigned to each region, that's gotta be in the executable (the border map you see by pressing space (or other buttons) is probably also in the executable, and is likely only cosmetic). If I get the time (and the right level of boredom) I'll try and create a list of which polygons point where.

I mentioned any TFTD location could produce a "Seabed Rubbish" or "Coral" mission, but I didn't mention the odds of these two turning up for any given polygon. Yeah, I didn't do enough tests for that... Polygons 0 and 8 could actually be set to use one of those two terrains (making one more likely to appear then the other).

By comparing the terrain lists to offset 10 in [[GEODATA.DAT]], I came up with these strings:

?? 01 01 01 01 07 ?? 06 06 08 ?? ?? 08 (UFO)

?? 01 02 03 04 05 06 07 ?? 07 06 01 04 (TFTD)

I was able to find the first one in the [[GEOSCAPE.EXE#Battlescape Terrain List|executable]], but TFTD's version eludes me...

- [[User:Bomb Bloke|Bomb Bloke]] 02:20, 31 January 2008 (PST)

== Borders data ==

FYI, in my UFO Defense Gold Edition executable (495 616 bytes), country borders data starts at offset 74AD4:
0xFFFF indicates the start of a new polyline, then each pair of words is a coordinate.
0xFFFE indicates the end of border data.

It looks like this (in my favorite tool ;-) ):
.data:00474AD4 GeoBordersData dw 0FFFFh ; DATA XREF: GeoDrawBorders+3�r
.data:00474AD4 ; GeoDrawBorders+C�o
.data:00474AD6 dw 221h
.data:00474AD8 dw 0FF43h
.data:00474ADA dw 238h
...
.data:00474DF4 dw 0FE71h
.data:00474DF6 dw 0FFFEh
HTH -[[User:Seb76|Seb76]], 31 January 2008

:Hey Seb76, you posted the information above. By any chance, did you also find borders for continents? XCOM must track them, because it tells you where you are when you start to make a new base. It could help Zombie and me relative to posting the percent of area devoted to different terrain types, because southern continents use jungle and northern ones use forest, for the same terrain code in WORLD.DAT. -[[User:MikeTheRed|MikeTheRed]] 20:38, 30 April 2009 (EDT)

The continents data is located at 0x474F38. Each entry represents a quad (4 values of 2 bytes) and a continent (2 bytes):

.data:00474F38 18 06 87 09 D0 FD 47 FE 00 00+geo_globe_zones structGlobeZone <618h, 987h, 0FDD0h, 0FE47h, 0>; 0
.data:00474F38 30 07 87 09 48 FE 0F FF 00 00+ ; DATA XREF: GetWorldZoneFromPos+10�o
.data:00474F38 80 07 5F 09 10 FF AF FF 00 00+structGlobeZone <730h, 987h, 0FE48h, 0FF0Fh, 0>; 1
.data:00474F38 00 00 3F 0B 30 FD CF FD 01 00+structGlobeZone <780h, 95Fh, 0FF10h, 0FFAFh, 0>; 2
.data:00474F38 00 00 3F 0B E0 01 D0 02 02 00+structGlobeZone <0, 0B3Fh, 0FD30h, 0FDCFh, 1>; 3
...
.data:00474F38 28 00 B8 01 40 01 DF 01 0D 00+structGlobeZone <0A28h, 27h, 78h, 1DFh, 0Dh>; 29
.data:00474F38 B8 01 2F 02 88 FF 4F 00 0E 00+structGlobeZone <28h, 1B8h, 140h, 1DFh, 0Dh>; 30
.data:00474F38 30 02 CF 02 D8 FF 4F 00 0E 00+structGlobeZone <1B8h, 22Fh, 0FF88h, 4Fh, 0Eh>; 31
.data:00474F38 B8 01 47 03 50 00 DF 01 0E 00 structGlobeZone <230h, 2CFh, 0FFD8h, 4Fh, 0Eh>; 32
.data:00474F38 structGlobeZone <1B8h, 347h, 50h, 1DFh, 0Eh>; 33

At 0x475090, the country data starts (using the same format).
HTH [[User:Seb76|Seb76]] 13:31, 1 May 2009 (EDT)

:Very cool! Listen, if you can capture the country and continent data, I can turn it into e.g. a spreadsheet that I'll post here. You can email it via my User link or post it as a new page with a hotlink here (so as not to clutter this one too much). If it's too much trouble, don't worry about it. The formats above are fine, but I have a couple of questions about what I'm looking at. If you're up to it. Thanks! -[[User:MikeTheRed|MikeTheRed]] 19:36, 7 May 2009 (EDT)
Concerning the format, the game uses a series of "quads" (xstart,ystart,xstop,ystop IIRC) and a continent number for each quad. It is quite crude, but the game crosses this data with the polygon data. So, for a given point it checks if it is on water or land, and then which quad it is contained into to deduce the continent's ID. [[User:Seb76|Seb76]] 17:12, 9 May 2009 (EDT)
:Thanks. Any chance you can send the two datsets to me? If not, I can get it. Sounds like you're primed to capture it, though. -[[User:MikeTheRed|MikeTheRed]] 18:25, 12 May 2009 (EDT)

== Terrain Type 12 in UFO ==
[[Image:Arctic_Modded.png|thumb|right]]

Heh, I see you already updated terrain type 12 in UFO, MTR. I didn't realize you did this so I modded world.dat so that the polar area of Siberia is type 12 instead of 9. Everything checks out like you mentioned. Anyway, just thought I should upload the pic so other people could see it. --[[User:Zombie|Zombie]] 19:15, 19 September 2008 (PDT) 

:Coolness. Actually, Pi's graphic on the WORLD page clinched it for me... look at where his terrain 12 is. I am in email with him concerning area calculations and etc. as we speak. -[[User:MikeTheRed|MikeTheRed]] 19:19, 19 September 2008 (PDT)

== Map Wrap problem with WORLD.DAT ==

I've been trying to help Zombie with determining how much of the globe is covered by the various terrains. But I've hit a brick wall with WORLD.DAT records' areas (triangles or quadrilaterals) that cross the "date line" in the middle of the Pacific.

X-COM "longitudes" go from 0 to 2800. The dateline is where 0 and 2800 butt up against each other in the Pacific. It is, of course, possible to have a WORLD record whose area straddles the line (think, Hawaii)... a little of the quad is east of the line, and a little is to the west of it. Mathematically, this can be treated very easily by adding 2800 to the X coordinates to the east of the dateline. That's easy.

The real problem is determining which of the records with huge differences in X coordinates (i.e., approaching 2800) '''''validly''''' cover that amount of area.

# As a first test (crossing my fingers that it would be this simple), I subtracted the lowest X coord from each record's highest X coord, to give a "max length estimate" (MLE) for each record. I was hoping most MLEs would be below, say, 1000, and all the rest would be up around 2800. But alas. While most records' MLEs were ~600 or less, and there was a spike of ~24 MLEs at 2700+, there was no "clear gap" between the low values and the high-end maxima. A histogram shows bin counts (with bins being 300 "wide") fall off a lot above ~600, but there is still a small number of counts in every bin, until you hit the spike at 2700+.
# As a second test, I thought "why not test to see if any records have one leg that's longer than all the others put together". In other words, some kind of discrepancy with the leg lengths. I thought myself clever... but alas. Each area "makes sense" in terms of being a closed figure, so not a single record had a discrepancy. In other words, if one leg was real long, there was always another one that was, too. This method couldn't tell between legitimately large areas, and illegimate dateline wrap-arounds.
# Finally I tried counting the number of legs for a given record that are greater than some arbitrarily high number (like 2600). This is sort of a variation on the first test; I was hoping for a clear division where most records have 0 very long legs, and approx. two dozen have two long legs. Foiled again, though... while most have 0 long legs and a cluster has 2 long ones, there are always a few that have 1 long leg (and no, they're not always triangles).

I can't help but think that there must be some easy way to do this, but I can't think of it. If I could do this graphically, it might be readily apparent... but I haven't worked with graphics at this very-basic level and don't know how to turn coordinates into a graphic figure. (Actually, I can do it, but it's just 4 points on an Excel X-versus-Y graph that aren't otherwise meaningful; they're not superimposed on a map of the globe or anything.)

Clear as mud? Does anyone have ideas? Pi Masta?? -[[User:MikeTheRed|MikeTheRed]] 17:21, 17 October 2008 (CDT)

:The only thing I can think of is a brute force method. Flag a record which have huge differences in the X-coordinates, then edit it so the terrain type is something easily recognizable (like mountainous), go in the game and verify where the record resides. There can't be anything more straight forward than that, no? My 2 cents.--[[User:Zombie|Zombie]] 21:32, 17 October 2008 (CDT)

Now there's an idea. Remind me... WORLD.DAT is not saved to the savegame slot, but I don't have to reload all of X-COM... I can just alt-tab to switch WORLD.DAT, and reload a "same old" GEO savegame, Right? ... Maybe it will get me past my mental wall of, not knowing how to handle these abstract coordinates, even. -[[User:MikeTheRed|MikeTheRed]] 21:51, 17 October 2008 (CDT)

:Correct, just reload a saved game while the game is running and presto, the map should be updated. By the way, approximately how many records have huge differences in X-coordinates? If there are a lot of them, a brute force method may take some time. But from what I remember from the file there are only a handful records which meet this criteria. --[[User:Zombie|Zombie]] 22:02, 17 October 2008 (CDT)

About two dozen. I'll take a crack at it; it's entirely possible that visualizing the first few may make things very clear. But give me a week or so. And if anybody has a brighter idea, jump in. -[[User:MikeTheRed|MikeTheRed]] 22:20, 17 October 2008 (CDT)

:So, all these records with huge differences occur around the "dateline", in the Pacific ocean where the game meshes the start and the end of the render together, correct? There isn't going to be huge tracks of land in the Pacific ocean, so couldn't you just pretend that the areas are small and do it that way? A couple dozen records are just enough to indicate they are Hawaii and other small islands surrounded by ocean. Suppose it couldn't hurt to double check the theory, but that's my take on it. --[[User:Zombie|Zombie]] 22:40, 17 October 2008 (CDT)

It fries my brain a little when I see that one coordinate of a record is an origin (e.g. X 0, Y +720), while the other coordinates are all over the place. A fair number of the high MLE records are like this. Is there a big strip coming down from the poles? Or around the equator? I think your idea of simply seeing what happens when you edit WORLD.DAT is a great idea. I didn't think of that approach... it's been too long since I sat down and hacked the game. But in this case, hacking the game supplies exactly what I said I couldn't visualize - seeing the difference superimposed on not just any map, but X-COM itself. Thanks bro. You owe me some excellent java. -[[User:MikeTheRed|MikeTheRed]] 22:57, 17 October 2008 (CDT)

:Ah, I forgot about the origins. In that case, yeah, there are some fairly large tracks of land which start at the poles and radiate down (or up, depending on the hemisphere). You could double check that by looking at the terrain type and verifying if it is 9 or 12. If you give me the record numbers which straddle the dateline, I could help you out by editing a few of them for you and marking it on the globe. That way you don't have to do so many of them. --[[User:Zombie|Zombie]] 23:22, 17 October 2008 (CDT)

== Which Prime Meridian? ==

Some clarification here, please. Comments above say that the game engine's zero longitude meridian, X=0, is somewhere around the (real world) International Date Line, in the middle of the Pacific. But if you look at the maps rendered from the WORLD.DAT data, they appear to start at (real world) Greenwich Meridian, at 0° longitude: England is right at the left of the map, presumably the start of the render. Which is correct? Did the Bros. Gollop start in Greenwich and number 0-359° East longitude (in eighths of a degree)? Or did they start around Hawaii and number 0-359° East longitude from there? [[User:Spike|Spike]] 16:33, 5 December 2008 (CST)
: Actually it was easier just to go and find out. The X=0 meridian is the real world prime meridian running through Greenwich, UK. This was determined by hacking my starting base location in LOC.DAT.

::Spike has it right and I have to admit - I made that mistake and have been posting that it's at the dateline, but in hindsight this was only an assumption based on how the XCOM Geoscape acted a little weird for me in the Pacific sometimes (plus I assumed the devs made it easy on themself). By coincidence, I just hacked WORLD.DAT today to address the wrap problem (see above) and indeed, it is at the usual Greenwich meridian (see my alternate [[Image:WORLD_DATwithTerrainChangedFor24SuspiciousAreas.DAT]]). Anybody is welcome to cleanup places where I said the meridian is at the dateline. -[[User:MikeTheRed|MikeTheRed]] 18:09, 5 December 2008 (CST)

::: Hey thanks MTR for clearing that up.
::: One more question - this is being a bit picky, but - shouldn't the correct range for longitude be stated as "2880 values, from 0 to 2879"? 2880 is the same as 0, and 'wraps' to 0, right? [[User:Spike|Spike]] 17:11, 6 December 2008 (CST)
:::: The precomputed trigonometry reference tables [[COS.DAT]] and SIN.DAT have lookup values for 0 through 2880, although 2880 indeed 'wraps' (has the same values as 0). I used these reference tables to decide what the authoritative range was. -- [[User:Zaimoni|Zaimoni]], 11:48, 7 December 2008 (CST)
::Sounds right. For the record, in WORLD.DAT, the minimum X value is 0 and the maximum is 2877 (in terms of what actually appears in the records). But it's an easy stretch to assume that the displayed coordinate system goes to 2879 (there just don't happen to be any corner points of areas that fall on 2879).
:::Cool, that nails it, Zaimoni. Thanks! -[[User:MikeTheRed|MikeTheRed]] 12:30, 7 December 2008 (CST)
::FWIW, I don't understand why "the resulting map could be said to have a spatial resolution of 00°07'30" (one-eighth of a degree)". To me, it makes more sense to compare it to degrees and minutes, and I can wrap my brain around something like this, better: "the XCOM coordinates have 13% of the precision of the real world's degree:minute value system (2880/(360*60) = 2/15 = 1/7.5)". Extending it to seconds seems arbitrarily harsh; it could also be arbitrarily extended to decimals of seconds - even harsher. Also FWIW there is, of course, a 2:1 relationship for longitude to latitude in the XCOM values (2880:1440), just like in real life (360:180). (Actually, 1441 and 181 values, but who's counting.)
:::Same here, I inserted the phrase "eighth of a degree" to soften up, and to get my own head around, the 'harsh' statements made previously by somebody that referred to 00°07'30". [[User:Spike|Spike]] 19:08, 6 December 2008 (CST)
::Interestingly, while we mainly use offsets on the wiki (values start at 0, not 1) because programmers do - even though counting starts at 1 for most of "the regular world" - here's a case where reality uses an offset, too. The Prime Meridian is 0, not 1. :P -[[User:MikeTheRed|MikeTheRed]] 18:36, 6 December 2008 (CST)

== AI Helpful Cheating ==

:Incidentally this [test above] also showed that the AI cheats and sends its missions to the area around your starting base. Even though I teleported my base from Hawaii to Casablanca at the start of the game, all the UFO missions still flew to the Pacific region in January. Then in February, all the missions shifted to North Africa or adjacent regions. The Pacific area went totally quiet. So the game "knows" where your base is, and plans the missions accordingly. [[User:Spike|Spike]] 17:08, 5 December 2008 (CST)

::The AI sending its missions in January near the first X-COM base is called "Giving the player a sporting chance." [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:18, 5 December 2008 (CST)

::: Not to mention making the game more fun and more playable. This is a well established principle, as evidenced by the fact that when the Daleks want to invade the Earth, they always start their attack in England, purely because that's where Dr Who lives. :) [[User:Spike|Spike]] 17:11, 6 December 2008 (CST)

:: I thought the Daleks did that cause they recognize Dr Who as the only force on Earth which can stand in their way?
:: It's not just January... the AI seems to give aliens a tendency to follow X-com around all through the game? I find that even in late game, the aliens seem to center on my original base, instead of a smooth worldwide distribution of activity.
:: Spike, your test has also proves that the aliens queue up their missions at the beginning of each month. Hmm... [[User:Jasonred|Jasonred]] 05:57, 2 May 2009 (EDT)

== World Area and Cylinder vs. Sphere ==

Ok Zombie, I finally finished all the math on the areas of terrain types in WORLD.DAT... I'd upload it here, but the Upload File link here is not working for me - is it working for others?

Anyway, I got a somewhat surprising result, that I'm hoping someone can help with. Apparently, WORLD.DAT is "straight up" areas; the XCOM devs did not control for sphericity per se (which is probably simply handled, for all practical purposes, by how it maps onto a "3D" globe in the Geoscape). Which is to say, when I calcuated areas, the poles got stretched way big, very much like the "cyclindrical projection" of the Earth seen in Pi Masta's "maps" on the WORLD.DAT page... and the terrain types of 9 (Ice) and 12 (Icebergs) account for 43% of all XCOM Land. Of course, this makes zero sense if you look at a globe (in XCOM or elsewhere). A quick check of the WORLD.DAT areas shows that Ice and Icebergs have an average latitude of 70° (this is if you take absolute values; otherwise South cancels North). Now, this is just an average of the latitudes of the centroids of each area, and doesn't take into account at all e.g. how large each one is (there could be a lot of tiny ones in Siberia, and a few huge ones at the Poles). Furthermore, it is 43% of the *land* found in WORLD.DAT - Ocean isn't accounted for at all (in XCOM terms, it is simply the absence of any WORLD.DAT land). But anyway, it does show that polar land in the Geoscape could definitely be way overestimated, if one takes spherical coordinates but treats them like a cylinder. Like I just did. :P

Anyway, to make a long story short... Would anyone know a way to "sphericalize" this data, so I can turn it into real-world areas? I'm not sure exactly how that would work - I used the Surveyor's Formula to get areas to begin with; would I have to back all the way up to actually using some variation of Surveyor's for a spherical surface - and WTH would that look like? Or would it be a close enough approximation to simply scale the area of each record somehow, based on the centroid latitude (average of its Y values)? Or maybe I can just straight up scale them relative to the Equator being 100% of area, the Poles being 0% of area? (None of the records actually have a centroid latitute of 90°, of course - in fact the largest ABS(centroid of latitude) is 85°.)

If I can get a handle on this, we could ultimately do a rough check of all my computations by comparing it against the [http://hypertextbook.com/facts/2001/DanielChen.shtml land area of Earth].

Help, anyone? -[[User:MikeTheRed|MikeTheRed]] 22:24, 20 November 2009 (EST)

: Well, latitude/longitude coordinates don't correct for sphericity either.

: The catch, here, is that the length of a degree of longitude varies by latitude. Recall that the scaling factor to convert the length of a degree of longitude at the equator, to a degree of longitude at latitude θ, is cos(θ). How to proceed from there depends on how you want to numerically model it (integration is feasible, while trapezoid approximations are easy to visualize and should be workable until very close to the poles.) -[[User:Zaimoni|Zaimoni]] 13:44, 21 November 2009 (CST)

I don't have intergration apps at hand. Cosine of theta. You bastard. Now I have to refresh myself on geometry, lol. Question: Does a scale from 100% to 0%, closely approximate real life -[[User:MikeTheRed|MikeTheRed]] 16:50, 21 November 2009 (EST)

: cos(0°) is 1 i.e. 100%; cos(90°) is 0 i.e. 0%. So it is a scale from 100% to 0%, it just isn't a linear scale. -[[User:Zaimoni|Zaimoni]] 11:02, 22 November 2009 (CST)

::Seems to me that to compute this on paper would take far too long. For example, say you were to draw one of the polygons, then scale each line of that polygon according to the latitude (multiply it by cos(latitude), I guess). You'd then be able to add up the resulting number of points covered, and get the area as a result... But this'd take far too long to do by hand.

::It may be that there's a formula that can be applied to determine the area covered by a given polygon to a spherical surface (still too much effort to do on paper), but off the top of my head I can't even think of one to do it with a flat surface, so getting a computer to do all the math in bulk seems to be the easiest way.

::The results would end up approximate however you do it, because the real world isn't a sphere.

::- [[User:Bomb Bloke|Bomb Bloke]] 19:38, 23 November 2009 (EST)

Ok, so here's what I came up with for the 2D map:

2D map is 2880x1440 with 4147200 points total, with a land area of 1542330 points (37.189670138888886%).
00: Forest = 53876 points (1.2990933641975309% world area, 3.4931564580861427% land area), Jungle = 189766 points (4.5757619598765435% world area, 3.4931564580861427% land area)
01: Farm = 32441 points (0.7822386188271605% world area, 2.10337606089488% land area)
02: Farm = 134294 points (3.238184799382716% world area, 8.707215706106993% land area)
03: Farm = 72882 points (1.757378472222222% world area, 4.725447861352629% land area)
04: Farm = 138245 points (3.3334538966049383% world area, 8.963386564483606% land area)
05: Mountain = 13513 points (0.3258342978395062% world area, 0.8761419410891313% land area)
06: Forest = 346 points (0.008342978395061729% world area, 0.02243359073609409% land area), Jungle = 24708 points (0.595775462962963% world area, 0.02243359073609409% land area)
07: Desert = 105327 points (2.539713541666667% world area, 6.829083270117291% land area)
08: Desert = 23575 points (0.5684558256172839% world area, 1.52853150752433% land area)
09: Polar = 714710 points (17.233555169753085% world area, 46.33962900287228% land area)
10: Forest = 20530 points (0.49503279320987653% world area, 1.331102941653213% land area), Jungle = 18117 points (0.43684895833333337% world area, 1.331102941653213% land area)
11: Forest = 0 points (0.0% world area, 0.0% land area), Jungle = 0 points (0.0% world area, 0.0% land area)
12: Polar Seas = 269183 points (6.490716628086419% world area, 17.453009407843975% land area)

Now assuming those figures check out with yours, Mike, then (with any luck) these should also be accurate for a 3D map (the sphere):

3D map is 2880x1440 (kinda) with 2659696 points total, with a land area of 783210 points (29.447350373877317%).
00: Forest = 49970 points (1.8787861469882272% world area, 6.380153470972025% land area), Jungle = 189766 points (4.061178420390902% world area, 6.380153470972025% land area)
01: Farm = 24014 points (0.9028851417605621% world area, 3.066099768899784% land area)
02: Farm = 98378 points (3.6988437776347376% world area, 12.56087128611739% land area)
03: Farm = 56052 points (2.1074588975582174% world area, 7.156701267859194% land area)
04: Farm = 122488 points (4.605338354458555% world area, 15.639228304030848% land area)
05: Mountain = 10971 points (0.4124907508226504% world area, 1.4007737388439883% land area)
06: Forest = 324 points (0.012181843338486806% world area, 0.04136821542115142% land area), Jungle = 24708 points (0.41200197315783454% world area, 0.04136821542115142% land area)
07: Desert = 92444 points (3.4757355727872663% world area, 11.803220081459633% land area)
08: Desert = 19755 points (0.742754059110515% world area, 2.5223120235952043% land area)
09: Polar = 152979 points (5.751747568143126% world area, 19.532309342321984% land area)
10: Forest = 19957 points (0.7503489120561146% world area, 2.548103318394811% land area), Jungle = 18117 points (0.6355989556701217% world area, 2.548103318394811% land area)
11: Forest = 0 points (0.0% world area, 0.0% land area), Jungle = 0 points (0.0% world area, 0.0% land area)
12: Polar Seas = 87871 points (3.3037986296178214% world area, 11.21934091750616% land area)

Zaimoni, I used this formula to add up how many points the 3D map would be (2659696), does it look right to you? If so, then the rest of my scaling is probably accurate enough as well.

for (int i=-720;i<721;i++) worldsize[1] += (int)(Math.cos(Math.toRadians(i/8))*2880);

- [[User:Bomb Bloke|Bomb Bloke]] 07:12, 24 November 2009 (EST)

:: What's the target language? That controls whether you'll be nailed by integer division at i/8. (You want the highest-precision floating point available.) For Java, I would try something like

:: for (int i=-720;i<721;i++) worldsize[1] += (int)(Math.cos(Math.toRadians(i/8.0))*2880);

:: to try to get some automatic type conversions going without using an explicit cast on i. - [[User:Zaimoni|Zaimoni]] 10:35, 24 November 2009 (CST)

::: Whoops, I've spent too long dealing with integers. Well caught. - [[User:Bomb Bloke|Bomb Bloke]] 01:12, 25 November 2009 (EST)

: Rats, my percentage of polar land mass on the 2D map comes out at about 64%. Still 46% if I disclude the polar seas. Back to the drawing board, then. [[User:Bomb Bloke|Bomb Bloke]] 07:32, 24 November 2009 (EST)

Ok let me try it with Cosines used against the area of each record, based on the latitude of the centroid point for each area. One thing first, though - the WORLD.DAT page says "at the equator, each possible map location on the Geoscape occupies a square that is 111 kilometres on its side", but shouldn't it be an eighth of that? And for a WORLD.DAT record making a perfect square (0,0; 0,1; 1,1; 1,0), the area would be 193.6 km2? -[[User:MikeTheRed|MikeTheRed]] 23:06, 24 November 2009 (EST)

: Indeed, should be an eighth, as the game map is in eighths of degrees (distance between real world degrees of latitude = ~111km, varying slightly as you move around the globe). A WORLD.DAT record can't really be a "perfect" square anywhere (because our lines can't bend to properly fit the 3D shape on which they're rendered). But say you made a polygon of one unit squared at the equator, it'd be a square eighth of a degree, and so should be pretty close 193.6 km2 (192.5 km2 to my count). This changes wildly as you move towards the poles, as the distance between points of longitude shrink down to 0 as you move from the equator (unlike latitude, where distances remains roughly the same). [http://en.wikipedia.org/wiki/Longitude#Degree_length] - [[User:Bomb Bloke|Bomb Bloke]] 01:12, 25 November 2009 (EST)

P.S. Can someone remind me - is Polar Sea With Icebergs considered land, in the game (can make bases or fight UFOs there)? -[[User:MikeTheRed|MikeTheRed]] 23:10, 24 November 2009 (EST)

:Yup, you can build bases and visit UFO sites on the polar sea texture so it's considered land. Though, in some cases it's a little iffy (probably due to how the area is mapped out on the globe). --[[User:Zombie|Zombie]] 23:15, 24 November 2009 (EST)

Just for comparison, I got a global land percentage of 31.224.. The way I did it however also suffers from some mapping distortions, although not so big.. So 29.44 is probably not to wrong.. Method I used: pixel/color scan of cube.map generated images, rendered using a 3D UFO.world.sphere.. Additional data: north pole: 55.300, south pole: 21.774. --[[User:Mvgulik|Mvgulik]] 22:43, 25 November 2009 (EST)

: After scraping out a heap of integer based calculations my figures vary a bit, but they're still fairly close to what they were. I think my main problem is correctly determining when polygons cross the prime meridion and loop around to the other side: Get that wrong, and certain polys will be way out in terms of accuracy.

: Still, I figure a count of the mountain polys vs total world size should be a good benchmark. Don't think any of those loop. - [[User:Bomb Bloke|Bomb Bloke]] 19:17, 26 November 2009 (EST)

::Done them all for you. Marked the one's where your number is to high if I'm correct. Oddly mountain's is one of them. --[[User:Mvgulik|Mvgulik]] 16:26, 27 November 2009 (EST)
00: 5.7033% *
01: 1.0427%
02: 4.2849%
03: 2.9602%
04: 5.2986%
05: 0.4005% *
06: 0.3188% *
07: 3.9370%
08: 0.9793%
09: 3.0936% *
10: 1.0211% *
11: 0.0%
12: 2.1456% *
:: Giving it a second thought after comparing the numbers. I initially figured the cubemap distortion only worked one way(Up). But it probably works in both ways. So these giving values that can be above and below the real value your after. That more or less leaves only the polar regions with having a somewhat suspicious large difference.

== Flat Earth Projection ==

As noted under [[UFO Interception#Movement]]

''Your ship autopilot prefers to move along lines of latitude (parallel to the equator) for long-range travel. This is especially noticeable when charting trans-polar routes: the ship will circle around the pole instead of flying straight across it. You can shorten the route taken by directing the ship to several intermediate way points along a straight line towards your destination.''

A very clear example of this is if you take a craft at say 85 deg N, 0 deg E and set a waypoint to 85 deg N, 180 deg E (the opposite side of the pole). Instead of flying in a straight line over the surface of the earth, a great circle (in this case right over the pole), it travels along the 85th parallel.

I think the explanation for the waypointing behaviour is that the wayfinding uses what is known as the Flat Earth Approximation method of approximating a great circle. Basically it is taking polar coordinates of latitude and longitude on the surface of a sphere, and treating them as if they were x and y coordinates on a flat rectangle of 360 x +/- 90. The rectangle is 'wrapped' at 0 deg E = 360 deg E, but it does not wrap at the 'top', along the +90 deg N and -90 deg S lines.

If you imagine a craft on a flat rectangle of this type, at coordinates (0,85) heading to (180,85), it would travel along the y=85 line. On a flat plane, this is the shortest route, the Cartesian distance.

The Flat Earth method is a reasonable approximation for short distances nearer the equator. It is poor for long distances and near the poles. It's probably ok for interceptions, especially of slower craft by faster craft. The more exact methods of calculating a great circle course were possibly too expensive to be done continually during an intercept. However they could've been used for plotting paths to static waypoints, even on a 16 bit computer.

Note that the Geoscape movement engine itself is not Cartesian, it is fully aware of spherical geometry. The flat earth method is only a shortcut for the wayfinding, not a shortcut used for actual movement.

I think the behaviour at the pole cited in the example above is pretty much proof, but I guess a harder proof would be to find two cities at reasonably high latitude (away from the equator) that are on a roughly 45/135/225/315 degree bearing to each other, a reasonably long distance, then fly a Skyranger between those via waypointing. Check a gazeteer to find the actual distance and see how much the Skyranger distance (760nm per hour) differs. I'm not even sure if this is a valid test, I haven't thought it through enough. I have tested Skyrangers orbiting pole to pole and they give a very close figure for the correct radius of the Earth, that's why I believe that the actual movement model is accurate. Also, the waypointing model is accurate in the special case where you are travelling along a line of longitude (which is already a great circle). The equator is the only line of latitude that is also a great circle, so the waypointing is also valid when travelling along the equator.

[[User:Spike|Spike]] 20:06, 8 November 2010 (UTC)

== Latitude or longitude? ==

FYI:

Latitude
Latitude is used to express how far north or south you are, relative to the equator. If you are on the equator your latitude is zero. If you are near the north pole your latitude is nearly 90 degrees north. If you are near the south pole your latitude is almost 90 degrees south.

Longitude
Longitude shows your location in an east-west direction, relative to the Greenwich meridian. Places to the east of Greenwich (such as Middle East, India and Japan) have longitude angles up to 180 degrees east. Places to the west of Greenwich (such as the Atlantic and North and South America) have angles up to 180 deg west. For inputting to the satellite dish pointing calculator, longitude west figures need to be input as negative numbers.

--[[User:Volutar|Volutar]] 02:33, 23 August 2012 (EDT)

* The above is irrelevant, due to being agreed to by everyone here. The problem is that the X coordinate is longitude and the Y coordinate is latitude, so what is idiomatic English (latitude and longitude) does not describe the file contents (longitude and latitude). I'd rather have the text be consistent with the file. --[[User:Zaimoni|Zaimoni]] 02:38, 23 August 2012 (CDT)

WORLD.DAT

2012-08-23T07:33:51Z

Zaimoni:

The original XCOM file is 13320 bytes long, while TFTD is 14660 bytes long. However, each uses the same 20-byte record format giving the original 666 entries and TFTD 733 entries. This file describes the terrain on the geoscape screen using quadrilateral polygons and triangles.

The first 16 bytes of file contain the points for the polygon. 4 sets of 2 short (2-byte) integers, designating the 'X' and 'Y' coordinate (or longitude and latitude respectively, if you prefer). If the last set has an x value of -1 then it is to be rendered as a triangle, otherwise it is a quad.

The last 4 bytes in the record contain the terrain type. This could be a long integer or 2 short integers as the last 2 bytes in each record are 0.

== Structure ==
{| {{StdDescTable}}
|- {{StdDescTable_Heading}}
! Offsets !! Meaning !! Values
|-
| 0-1 || First X coordinate/longitude || 0 - 2879
|-
| 2-3 || First Y coordinate/latitude || -720 - 720
|-
| 4-5 || Second X coordinate/longitude || 0 - 2879
|-
| 6-7 || Second Y coordinate/latitude || -720 - 720
|-
| 8-9 || Third X coordinate/longitude || 0 - 2879
|-
| 10-11 || Third Y coordinate/latitude || -720 - 720
|-
| 12-13 || Fourth* X coordinate/longitude || 0 - 2879
|-
| 14-15 || Fourth* Y coordinate/latitude || -720 - 720
|-
| 16-19 || Terrain Type/Texture || 0-12
|}
<nowiki>*</nowiki> As mentioned above, the fourth coordinate could be (-1, 0) denoting a triangle

== Relationship to Real World Geography ==

As the 2880 possible longitude values range from 0 to 2879 (hex: 3F 0B) and the latitude values range from -720 to 720, the resulting map could be said to have a spatial resolution of one-eighth of a degree, both in latitude and in longitude (0.125° or 00°07'30"). (2880 = 360 x 8, and 720 = 90 x 8.)

This implies that, at the equator, each possible map location on the Geoscape occupies a square that is 60 nautical miles (111 kilometres, 69 statute miles) on its side, or an area of 4,761 square miles / 12,321 square kilometres. This area would of course reduce with North or South latitude as you move away from the equator (and also the shape of the area will become progressively less square).

The X coordinate starts with X = 0 at 0° longitude (the Prime Meridian or Greenwich Meridian) and increases going eastward. Unlike real-world longitude, there is only "East" longitude, from 0°E to 359.875°E. This is the result of forcing the coordinate system to be positive-only, for algorithmic purposes. So, for example, the equivalent of 90°W longitude would be "270°E longitude", with a game X coordinate of 270 x 8 = 2160.

A Y coordinate value of 720 (hex: D0 02) corresponds to 90°S latitude (the South Pole); a Y coordinate value of -720 (hex: 30 FD) corresponds to 90°N latitude (the North Pole).

== Texture / Terrain Type ==

The final value in each record points to the [[TEXTURE.DAT|texture type]] to be displayed for that polygon. It also serves to determine the terrain type used when you start a battle in that area.

UFO TFTD
0: Forest / Jungle 0: (Nothing?)
1: Farm 1: Pipes
2: Farm 2: Crashed Plane
3: Farm 3: Atlantis
4: Farm 4: Mu
5: Mountain 5: Sunken Galleon
6: Forest / Jungle 6: Sunken Liner
7: Desert 7: Volcanic
8: Desert 8: (Nothing?)
9: Polar Ice 9: Volcanic
10: Forest / Jungle 10: Sunken Liner
11: Forest / Jungle 11: Pipes
12: Polar Seas w/Icebergs 12: Mu

In UFO, terrain types 0, 6, 10 and 11 will produce forest missions in the northern hemisphere and jungle mission in the south. (11 is not actually used in the game, but hacking reveals this.)

For TFTD, the terrain type is always selected randomly from a choice of three - Coral, Seabed, and whatever the terrain type for that actual polygon is. In the case of a type 0 or 8, the mission will always be in either the Coral or Seabed terrains.

Although TFTD has three choices of underwater depth that can be associated with any given mission (plus a forth "depth" for surface missions), that value is not derived from this file. Most likely it's taken from the [[LOC.DAT]] record that points to the mission in concern.

<gallery widths="400" heights="225">
Image:xcom_render2.gif|Rendering of the data in WORLD.DAT for the original XCOM. The colors are obtained by using offset 16-19 for each record. Click on the image to see the exact color key, generally speaking though it goes bright green to dark green for 0-5, and dark yellow to white for 6 - 12. Value 11 however is not used anywhere in the map.
Image:tftd_render.gif|Rendering of the data in WORLD.DAT for TFTD. Colors again are obtained by using the same offset as before. They go from blue to white for 0 to 12.
</gallery>

TFTD seems to have overlapping polygons at places whereas XCOM didn't (exception to the poles, which is probably because these polygons are rendered to a sphere, not a flat surface).

--[[User:Pi Masta|Pi Masta]] 15:24, 10 April 2007 (PDT)

Each polygon has its light calculated individually. This gives rise to the effect of a large area of the same texture having different colors, depending on how much sunlight the particular area defined by the WORLD.DAT record is receiving.

Country and regional borders must be stored in the executable somewhere. I've tried hard looking for the position of cities in there hoping the position would be near its [[ENGLISH.DAT]] index, but I haven't had much luck.

--[[User:Pi Masta|Pi Masta]] 16:06, 10 April 2007 (PDT)

== See Also ==

*[[COS.DAT]]
*[[TEXTURE.DAT]]
[[Category:Game Files]]

Talk:WORLD.DAT

2012-08-23T07:30:37Z

Zaimoni:

== Terrain ==

// World.Dat = World Map Terrain

typedef struct worlddat
{
short QuadData[4][2]; // Coordinates of quadrilateral
unsigned long texture; // Terrain texture of quad
} WorldDat;

#define MaxQuads 768 // Observed values, XCOM = 666, TFTD = 733

QuadData/8 = realworld latitude and longitude numbers.

if QuadData[3][1] = -1 then the shape is a triangle and that entery is not used. (for you non programers QuadData[0] is the first so [3] is the forth.)

This may not be usefull for the wiki but I once wrote a program to detect what world.dat entry a givin ship was located in and therefor what texture/terrain file used to create the battlescape map. I have the function if anyone is interested in the math.

--[[User:BladeFireLight|BladeFireLight]] 21:24, 20 January 2007 (PST)

----

Gah, I just spent the last 20 minutes or so figuring this file out, wish I would have seen this before.

Wonder how it defines the countries since this file only seems to designate terrain types. Maybe indexed all the polygons in this file? Be tough to find it then...

Oh, and one thing. When QuadData[3]['''0'''] is -1 when it designates a triangle (and actually QuadData[3][1] is 0 as well).

I'll probably put this info on the page article here soon though. --[[User:Pi Masta|Pi Masta]] 19:42, 5 April 2007 (PDT)

----

Pi Masta, can you post an overlay of the TFTD world map? My first thought was that it was a representation of the quad's depth, but that doesn't seem entirely right either. Or perhaps it's a combination of terrain and height in the single byte? - [[User:NKF|NKF]]

----

Yeah it definitely holds terrain data. the TFTD map took a bit to recognize (aka make sure I was rendering it correctly) as it defines the oceans and not the land. I don't remember the depths that TFTD had, but didn't it also have missions on land as well? With differing land types? I never got into TFTD so my knowledge is limited.

I probably should upload a wire-frame version of the TFTD map, where you can see some of the overlaps. Well, I assume they are overlaps, otherwise they are really really small triangles.

This file is a bit of a pain to render as the points will cross the prime meridian thus X values will go from say 6 to 2700 to 2750 to 200, etc. in the same polygon line. I broke them up and split polygons when the difference was large and for TFTD it worked great. It was XCOM that was a problem and eventually I just excluded the troublesome polygons from being split (still rendered).

--[[User:Pi Masta|Pi Masta]] 15:34, 10 April 2007 (PDT)

----

TFTD has four depth levels, one of which is "surface". However the game only puts polygons on the water so presumably this file would only cover three levels (all land missions are terror sites).

For UFO, I did some value tweaking and came up with these referrences on battlescape terrain:

0 - Jungle
1 - Farm
2 - Farm
3 - Farm
4 - Farm
5 - Mountain
6 - Jungle
7 - Desert
8 - Desert
9 - Polar
10 - Jungle
11 - Jungle
12 - Polar

This does more or less match the [[TEXTURE.DAT|imagery]], but the problem here is that even with multiple missions on each terrain type I couldn't get a forest to appear. My thought is it has something to do with the position on the globe as all the missions I did were in the one area (south pole).

Values above 12 seemed to all use jungle as well, and looped through the usual texture images (oddly enough, I still had to add images to the set to prevent a crash).

- [[User:Bomb Bloke|Bomb Bloke]] 21:29, 1 January 2008 (PST)

----

If I'm not mistaken, the game picks between forest and jungle terrain depending on which part of the hemisphere you're on. Everything north of the Equator uses forest terrain while everything south of the Equator goes with jungle terrain.

- [[User:NKF|NKF]]

----

Is there any place in the article that we can elaborate that the 2880/1440 values makes for a resolution of 00°07'30"? I know it's not neccessary to the data file, but I think it's a nice little real-world statistic. --[[User:Danial|Danial]] 22:41, 29 January 2008 (PST)

----

Thank ye kindly NKF. :)

Ok, so I've gone and thrown all that stuff in the wiki page and nerfed the content re depth (as after quite a bit of testing I wasn't able to affect mission depth with WORLD.DAT values at all).

It might be a while before I play with this file again (mostly I mess with the battlescape data), so while it's fresh in my mind a few other points:

Where regions are located does seem to be controlled by this file... Kinda. For example, I got the impression that polygons 0 to 20 might be "America", polygons 21 to 35 might be "Russia", and so on and so forth. Move the polygons and you move the regions. As for which polygons are assigned to each region, that's gotta be in the executable (the border map you see by pressing space (or other buttons) is probably also in the executable, and is likely only cosmetic). If I get the time (and the right level of boredom) I'll try and create a list of which polygons point where.

I mentioned any TFTD location could produce a "Seabed Rubbish" or "Coral" mission, but I didn't mention the odds of these two turning up for any given polygon. Yeah, I didn't do enough tests for that... Polygons 0 and 8 could actually be set to use one of those two terrains (making one more likely to appear then the other).

By comparing the terrain lists to offset 10 in [[GEODATA.DAT]], I came up with these strings:

?? 01 01 01 01 07 ?? 06 06 08 ?? ?? 08 (UFO)

?? 01 02 03 04 05 06 07 ?? 07 06 01 04 (TFTD)

I was able to find the first one in the [[GEOSCAPE.EXE#Battlescape Terrain List|executable]], but TFTD's version eludes me...

- [[User:Bomb Bloke|Bomb Bloke]] 02:20, 31 January 2008 (PST)

== Borders data ==

FYI, in my UFO Defense Gold Edition executable (495 616 bytes), country borders data starts at offset 74AD4:
0xFFFF indicates the start of a new polyline, then each pair of words is a coordinate.
0xFFFE indicates the end of border data.

It looks like this (in my favorite tool ;-) ):
.data:00474AD4 GeoBordersData dw 0FFFFh ; DATA XREF: GeoDrawBorders+3�r
.data:00474AD4 ; GeoDrawBorders+C�o
.data:00474AD6 dw 221h
.data:00474AD8 dw 0FF43h
.data:00474ADA dw 238h
...
.data:00474DF4 dw 0FE71h
.data:00474DF6 dw 0FFFEh
HTH -[[User:Seb76|Seb76]], 31 January 2008

:Hey Seb76, you posted the information above. By any chance, did you also find borders for continents? XCOM must track them, because it tells you where you are when you start to make a new base. It could help Zombie and me relative to posting the percent of area devoted to different terrain types, because southern continents use jungle and northern ones use forest, for the same terrain code in WORLD.DAT. -[[User:MikeTheRed|MikeTheRed]] 20:38, 30 April 2009 (EDT)

The continents data is located at 0x474F38. Each entry represents a quad (4 values of 2 bytes) and a continent (2 bytes):

.data:00474F38 18 06 87 09 D0 FD 47 FE 00 00+geo_globe_zones structGlobeZone <618h, 987h, 0FDD0h, 0FE47h, 0>; 0
.data:00474F38 30 07 87 09 48 FE 0F FF 00 00+ ; DATA XREF: GetWorldZoneFromPos+10�o
.data:00474F38 80 07 5F 09 10 FF AF FF 00 00+structGlobeZone <730h, 987h, 0FE48h, 0FF0Fh, 0>; 1
.data:00474F38 00 00 3F 0B 30 FD CF FD 01 00+structGlobeZone <780h, 95Fh, 0FF10h, 0FFAFh, 0>; 2
.data:00474F38 00 00 3F 0B E0 01 D0 02 02 00+structGlobeZone <0, 0B3Fh, 0FD30h, 0FDCFh, 1>; 3
...
.data:00474F38 28 00 B8 01 40 01 DF 01 0D 00+structGlobeZone <0A28h, 27h, 78h, 1DFh, 0Dh>; 29
.data:00474F38 B8 01 2F 02 88 FF 4F 00 0E 00+structGlobeZone <28h, 1B8h, 140h, 1DFh, 0Dh>; 30
.data:00474F38 30 02 CF 02 D8 FF 4F 00 0E 00+structGlobeZone <1B8h, 22Fh, 0FF88h, 4Fh, 0Eh>; 31
.data:00474F38 B8 01 47 03 50 00 DF 01 0E 00 structGlobeZone <230h, 2CFh, 0FFD8h, 4Fh, 0Eh>; 32
.data:00474F38 structGlobeZone <1B8h, 347h, 50h, 1DFh, 0Eh>; 33

At 0x475090, the country data starts (using the same format).
HTH [[User:Seb76|Seb76]] 13:31, 1 May 2009 (EDT)

:Very cool! Listen, if you can capture the country and continent data, I can turn it into e.g. a spreadsheet that I'll post here. You can email it via my User link or post it as a new page with a hotlink here (so as not to clutter this one too much). If it's too much trouble, don't worry about it. The formats above are fine, but I have a couple of questions about what I'm looking at. If you're up to it. Thanks! -[[User:MikeTheRed|MikeTheRed]] 19:36, 7 May 2009 (EDT)
Concerning the format, the game uses a series of "quads" (xstart,ystart,xstop,ystop IIRC) and a continent number for each quad. It is quite crude, but the game crosses this data with the polygon data. So, for a given point it checks if it is on water or land, and then which quad it is contained into to deduce the continent's ID. [[User:Seb76|Seb76]] 17:12, 9 May 2009 (EDT)
:Thanks. Any chance you can send the two datsets to me? If not, I can get it. Sounds like you're primed to capture it, though. -[[User:MikeTheRed|MikeTheRed]] 18:25, 12 May 2009 (EDT)

== Terrain Type 12 in UFO ==
[[Image:Arctic_Modded.png|thumb|right]]

Heh, I see you already updated terrain type 12 in UFO, MTR. I didn't realize you did this so I modded world.dat so that the polar area of Siberia is type 12 instead of 9. Everything checks out like you mentioned. Anyway, just thought I should upload the pic so other people could see it. --[[User:Zombie|Zombie]] 19:15, 19 September 2008 (PDT) 

:Coolness. Actually, Pi's graphic on the WORLD page clinched it for me... look at where his terrain 12 is. I am in email with him concerning area calculations and etc. as we speak. -[[User:MikeTheRed|MikeTheRed]] 19:19, 19 September 2008 (PDT)

== Map Wrap problem with WORLD.DAT ==

I've been trying to help Zombie with determining how much of the globe is covered by the various terrains. But I've hit a brick wall with WORLD.DAT records' areas (triangles or quadrilaterals) that cross the "date line" in the middle of the Pacific.

X-COM "longitudes" go from 0 to 2800. The dateline is where 0 and 2800 butt up against each other in the Pacific. It is, of course, possible to have a WORLD record whose area straddles the line (think, Hawaii)... a little of the quad is east of the line, and a little is to the west of it. Mathematically, this can be treated very easily by adding 2800 to the X coordinates to the east of the dateline. That's easy.

The real problem is determining which of the records with huge differences in X coordinates (i.e., approaching 2800) '''''validly''''' cover that amount of area.

# As a first test (crossing my fingers that it would be this simple), I subtracted the lowest X coord from each record's highest X coord, to give a "max length estimate" (MLE) for each record. I was hoping most MLEs would be below, say, 1000, and all the rest would be up around 2800. But alas. While most records' MLEs were ~600 or less, and there was a spike of ~24 MLEs at 2700+, there was no "clear gap" between the low values and the high-end maxima. A histogram shows bin counts (with bins being 300 "wide") fall off a lot above ~600, but there is still a small number of counts in every bin, until you hit the spike at 2700+.
# As a second test, I thought "why not test to see if any records have one leg that's longer than all the others put together". In other words, some kind of discrepancy with the leg lengths. I thought myself clever... but alas. Each area "makes sense" in terms of being a closed figure, so not a single record had a discrepancy. In other words, if one leg was real long, there was always another one that was, too. This method couldn't tell between legitimately large areas, and illegimate dateline wrap-arounds.
# Finally I tried counting the number of legs for a given record that are greater than some arbitrarily high number (like 2600). This is sort of a variation on the first test; I was hoping for a clear division where most records have 0 very long legs, and approx. two dozen have two long legs. Foiled again, though... while most have 0 long legs and a cluster has 2 long ones, there are always a few that have 1 long leg (and no, they're not always triangles).

I can't help but think that there must be some easy way to do this, but I can't think of it. If I could do this graphically, it might be readily apparent... but I haven't worked with graphics at this very-basic level and don't know how to turn coordinates into a graphic figure. (Actually, I can do it, but it's just 4 points on an Excel X-versus-Y graph that aren't otherwise meaningful; they're not superimposed on a map of the globe or anything.)

Clear as mud? Does anyone have ideas? Pi Masta?? -[[User:MikeTheRed|MikeTheRed]] 17:21, 17 October 2008 (CDT)

:The only thing I can think of is a brute force method. Flag a record which have huge differences in the X-coordinates, then edit it so the terrain type is something easily recognizable (like mountainous), go in the game and verify where the record resides. There can't be anything more straight forward than that, no? My 2 cents.--[[User:Zombie|Zombie]] 21:32, 17 October 2008 (CDT)

Now there's an idea. Remind me... WORLD.DAT is not saved to the savegame slot, but I don't have to reload all of X-COM... I can just alt-tab to switch WORLD.DAT, and reload a "same old" GEO savegame, Right? ... Maybe it will get me past my mental wall of, not knowing how to handle these abstract coordinates, even. -[[User:MikeTheRed|MikeTheRed]] 21:51, 17 October 2008 (CDT)

:Correct, just reload a saved game while the game is running and presto, the map should be updated. By the way, approximately how many records have huge differences in X-coordinates? If there are a lot of them, a brute force method may take some time. But from what I remember from the file there are only a handful records which meet this criteria. --[[User:Zombie|Zombie]] 22:02, 17 October 2008 (CDT)

About two dozen. I'll take a crack at it; it's entirely possible that visualizing the first few may make things very clear. But give me a week or so. And if anybody has a brighter idea, jump in. -[[User:MikeTheRed|MikeTheRed]] 22:20, 17 October 2008 (CDT)

:So, all these records with huge differences occur around the "dateline", in the Pacific ocean where the game meshes the start and the end of the render together, correct? There isn't going to be huge tracks of land in the Pacific ocean, so couldn't you just pretend that the areas are small and do it that way? A couple dozen records are just enough to indicate they are Hawaii and other small islands surrounded by ocean. Suppose it couldn't hurt to double check the theory, but that's my take on it. --[[User:Zombie|Zombie]] 22:40, 17 October 2008 (CDT)

It fries my brain a little when I see that one coordinate of a record is an origin (e.g. X 0, Y +720), while the other coordinates are all over the place. A fair number of the high MLE records are like this. Is there a big strip coming down from the poles? Or around the equator? I think your idea of simply seeing what happens when you edit WORLD.DAT is a great idea. I didn't think of that approach... it's been too long since I sat down and hacked the game. But in this case, hacking the game supplies exactly what I said I couldn't visualize - seeing the difference superimposed on not just any map, but X-COM itself. Thanks bro. You owe me some excellent java. -[[User:MikeTheRed|MikeTheRed]] 22:57, 17 October 2008 (CDT)

:Ah, I forgot about the origins. In that case, yeah, there are some fairly large tracks of land which start at the poles and radiate down (or up, depending on the hemisphere). You could double check that by looking at the terrain type and verifying if it is 9 or 12. If you give me the record numbers which straddle the dateline, I could help you out by editing a few of them for you and marking it on the globe. That way you don't have to do so many of them. --[[User:Zombie|Zombie]] 23:22, 17 October 2008 (CDT)

== Which Prime Meridian? ==

Some clarification here, please. Comments above say that the game engine's zero longitude meridian, X=0, is somewhere around the (real world) International Date Line, in the middle of the Pacific. But if you look at the maps rendered from the WORLD.DAT data, they appear to start at (real world) Greenwich Meridian, at 0° longitude: England is right at the left of the map, presumably the start of the render. Which is correct? Did the Bros. Gollop start in Greenwich and number 0-359° East longitude (in eighths of a degree)? Or did they start around Hawaii and number 0-359° East longitude from there? [[User:Spike|Spike]] 16:33, 5 December 2008 (CST)
: Actually it was easier just to go and find out. The X=0 meridian is the real world prime meridian running through Greenwich, UK. This was determined by hacking my starting base location in LOC.DAT.

::Spike has it right and I have to admit - I made that mistake and have been posting that it's at the dateline, but in hindsight this was only an assumption based on how the XCOM Geoscape acted a little weird for me in the Pacific sometimes (plus I assumed the devs made it easy on themself). By coincidence, I just hacked WORLD.DAT today to address the wrap problem (see above) and indeed, it is at the usual Greenwich meridian (see my alternate [[Image:WORLD_DATwithTerrainChangedFor24SuspiciousAreas.DAT]]). Anybody is welcome to cleanup places where I said the meridian is at the dateline. -[[User:MikeTheRed|MikeTheRed]] 18:09, 5 December 2008 (CST)

::: Hey thanks MTR for clearing that up.
::: One more question - this is being a bit picky, but - shouldn't the correct range for longitude be stated as "2880 values, from 0 to 2879"? 2880 is the same as 0, and 'wraps' to 0, right? [[User:Spike|Spike]] 17:11, 6 December 2008 (CST)
:::: The precomputed trigonometry reference tables [[COS.DAT]] and SIN.DAT have lookup values for 0 through 2880, although 2880 indeed 'wraps' (has the same values as 0). I used these reference tables to decide what the authoritative range was. -- [[User:Zaimoni|Zaimoni]], 11:48, 7 December 2008 (CST)
::Sounds right. For the record, in WORLD.DAT, the minimum X value is 0 and the maximum is 2877 (in terms of what actually appears in the records). But it's an easy stretch to assume that the displayed coordinate system goes to 2879 (there just don't happen to be any corner points of areas that fall on 2879).
:::Cool, that nails it, Zaimoni. Thanks! -[[User:MikeTheRed|MikeTheRed]] 12:30, 7 December 2008 (CST)
::FWIW, I don't understand why "the resulting map could be said to have a spatial resolution of 00°07'30" (one-eighth of a degree)". To me, it makes more sense to compare it to degrees and minutes, and I can wrap my brain around something like this, better: "the XCOM coordinates have 13% of the precision of the real world's degree:minute value system (2880/(360*60) = 2/15 = 1/7.5)". Extending it to seconds seems arbitrarily harsh; it could also be arbitrarily extended to decimals of seconds - even harsher. Also FWIW there is, of course, a 2:1 relationship for longitude to latitude in the XCOM values (2880:1440), just like in real life (360:180). (Actually, 1441 and 181 values, but who's counting.)
:::Same here, I inserted the phrase "eighth of a degree" to soften up, and to get my own head around, the 'harsh' statements made previously by somebody that referred to 00°07'30". [[User:Spike|Spike]] 19:08, 6 December 2008 (CST)
::Interestingly, while we mainly use offsets on the wiki (values start at 0, not 1) because programmers do - even though counting starts at 1 for most of "the regular world" - here's a case where reality uses an offset, too. The Prime Meridian is 0, not 1. :P -[[User:MikeTheRed|MikeTheRed]] 18:36, 6 December 2008 (CST)

== AI Helpful Cheating ==

:Incidentally this [test above] also showed that the AI cheats and sends its missions to the area around your starting base. Even though I teleported my base from Hawaii to Casablanca at the start of the game, all the UFO missions still flew to the Pacific region in January. Then in February, all the missions shifted to North Africa or adjacent regions. The Pacific area went totally quiet. So the game "knows" where your base is, and plans the missions accordingly. [[User:Spike|Spike]] 17:08, 5 December 2008 (CST)

::The AI sending its missions in January near the first X-COM base is called "Giving the player a sporting chance." [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:18, 5 December 2008 (CST)

::: Not to mention making the game more fun and more playable. This is a well established principle, as evidenced by the fact that when the Daleks want to invade the Earth, they always start their attack in England, purely because that's where Dr Who lives. :) [[User:Spike|Spike]] 17:11, 6 December 2008 (CST)

:: I thought the Daleks did that cause they recognize Dr Who as the only force on Earth which can stand in their way?
:: It's not just January... the AI seems to give aliens a tendency to follow X-com around all through the game? I find that even in late game, the aliens seem to center on my original base, instead of a smooth worldwide distribution of activity.
:: Spike, your test has also proves that the aliens queue up their missions at the beginning of each month. Hmm... [[User:Jasonred|Jasonred]] 05:57, 2 May 2009 (EDT)

== World Area and Cylinder vs. Sphere ==

Ok Zombie, I finally finished all the math on the areas of terrain types in WORLD.DAT... I'd upload it here, but the Upload File link here is not working for me - is it working for others?

Anyway, I got a somewhat surprising result, that I'm hoping someone can help with. Apparently, WORLD.DAT is "straight up" areas; the XCOM devs did not control for sphericity per se (which is probably simply handled, for all practical purposes, by how it maps onto a "3D" globe in the Geoscape). Which is to say, when I calcuated areas, the poles got stretched way big, very much like the "cyclindrical projection" of the Earth seen in Pi Masta's "maps" on the WORLD.DAT page... and the terrain types of 9 (Ice) and 12 (Icebergs) account for 43% of all XCOM Land. Of course, this makes zero sense if you look at a globe (in XCOM or elsewhere). A quick check of the WORLD.DAT areas shows that Ice and Icebergs have an average latitude of 70° (this is if you take absolute values; otherwise South cancels North). Now, this is just an average of the latitudes of the centroids of each area, and doesn't take into account at all e.g. how large each one is (there could be a lot of tiny ones in Siberia, and a few huge ones at the Poles). Furthermore, it is 43% of the *land* found in WORLD.DAT - Ocean isn't accounted for at all (in XCOM terms, it is simply the absence of any WORLD.DAT land). But anyway, it does show that polar land in the Geoscape could definitely be way overestimated, if one takes spherical coordinates but treats them like a cylinder. Like I just did. :P

Anyway, to make a long story short... Would anyone know a way to "sphericalize" this data, so I can turn it into real-world areas? I'm not sure exactly how that would work - I used the Surveyor's Formula to get areas to begin with; would I have to back all the way up to actually using some variation of Surveyor's for a spherical surface - and WTH would that look like? Or would it be a close enough approximation to simply scale the area of each record somehow, based on the centroid latitude (average of its Y values)? Or maybe I can just straight up scale them relative to the Equator being 100% of area, the Poles being 0% of area? (None of the records actually have a centroid latitute of 90°, of course - in fact the largest ABS(centroid of latitude) is 85°.)

If I can get a handle on this, we could ultimately do a rough check of all my computations by comparing it against the [http://hypertextbook.com/facts/2001/DanielChen.shtml land area of Earth].

Help, anyone? -[[User:MikeTheRed|MikeTheRed]] 22:24, 20 November 2009 (EST)

: Well, latitude/longitude coordinates don't correct for sphericity either.

: The catch, here, is that the length of a degree of longitude varies by latitude. Recall that the scaling factor to convert the length of a degree of longitude at the equator, to a degree of longitude at latitude θ, is cos(θ). How to proceed from there depends on how you want to numerically model it (integration is feasible, while trapezoid approximations are easy to visualize and should be workable until very close to the poles.) -[[User:Zaimoni|Zaimoni]] 13:44, 21 November 2009 (CST)

I don't have intergration apps at hand. Cosine of theta. You bastard. Now I have to refresh myself on geometry, lol. Question: Does a scale from 100% to 0%, closely approximate real life -[[User:MikeTheRed|MikeTheRed]] 16:50, 21 November 2009 (EST)

: cos(0°) is 1 i.e. 100%; cos(90°) is 0 i.e. 0%. So it is a scale from 100% to 0%, it just isn't a linear scale. -[[User:Zaimoni|Zaimoni]] 11:02, 22 November 2009 (CST)

::Seems to me that to compute this on paper would take far too long. For example, say you were to draw one of the polygons, then scale each line of that polygon according to the latitude (multiply it by cos(latitude), I guess). You'd then be able to add up the resulting number of points covered, and get the area as a result... But this'd take far too long to do by hand.

::It may be that there's a formula that can be applied to determine the area covered by a given polygon to a spherical surface (still too much effort to do on paper), but off the top of my head I can't even think of one to do it with a flat surface, so getting a computer to do all the math in bulk seems to be the easiest way.

::The results would end up approximate however you do it, because the real world isn't a sphere.

::- [[User:Bomb Bloke|Bomb Bloke]] 19:38, 23 November 2009 (EST)

Ok, so here's what I came up with for the 2D map:

2D map is 2880x1440 with 4147200 points total, with a land area of 1542330 points (37.189670138888886%).
00: Forest = 53876 points (1.2990933641975309% world area, 3.4931564580861427% land area), Jungle = 189766 points (4.5757619598765435% world area, 3.4931564580861427% land area)
01: Farm = 32441 points (0.7822386188271605% world area, 2.10337606089488% land area)
02: Farm = 134294 points (3.238184799382716% world area, 8.707215706106993% land area)
03: Farm = 72882 points (1.757378472222222% world area, 4.725447861352629% land area)
04: Farm = 138245 points (3.3334538966049383% world area, 8.963386564483606% land area)
05: Mountain = 13513 points (0.3258342978395062% world area, 0.8761419410891313% land area)
06: Forest = 346 points (0.008342978395061729% world area, 0.02243359073609409% land area), Jungle = 24708 points (0.595775462962963% world area, 0.02243359073609409% land area)
07: Desert = 105327 points (2.539713541666667% world area, 6.829083270117291% land area)
08: Desert = 23575 points (0.5684558256172839% world area, 1.52853150752433% land area)
09: Polar = 714710 points (17.233555169753085% world area, 46.33962900287228% land area)
10: Forest = 20530 points (0.49503279320987653% world area, 1.331102941653213% land area), Jungle = 18117 points (0.43684895833333337% world area, 1.331102941653213% land area)
11: Forest = 0 points (0.0% world area, 0.0% land area), Jungle = 0 points (0.0% world area, 0.0% land area)
12: Polar Seas = 269183 points (6.490716628086419% world area, 17.453009407843975% land area)

Now assuming those figures check out with yours, Mike, then (with any luck) these should also be accurate for a 3D map (the sphere):

3D map is 2880x1440 (kinda) with 2659696 points total, with a land area of 783210 points (29.447350373877317%).
00: Forest = 49970 points (1.8787861469882272% world area, 6.380153470972025% land area), Jungle = 189766 points (4.061178420390902% world area, 6.380153470972025% land area)
01: Farm = 24014 points (0.9028851417605621% world area, 3.066099768899784% land area)
02: Farm = 98378 points (3.6988437776347376% world area, 12.56087128611739% land area)
03: Farm = 56052 points (2.1074588975582174% world area, 7.156701267859194% land area)
04: Farm = 122488 points (4.605338354458555% world area, 15.639228304030848% land area)
05: Mountain = 10971 points (0.4124907508226504% world area, 1.4007737388439883% land area)
06: Forest = 324 points (0.012181843338486806% world area, 0.04136821542115142% land area), Jungle = 24708 points (0.41200197315783454% world area, 0.04136821542115142% land area)
07: Desert = 92444 points (3.4757355727872663% world area, 11.803220081459633% land area)
08: Desert = 19755 points (0.742754059110515% world area, 2.5223120235952043% land area)
09: Polar = 152979 points (5.751747568143126% world area, 19.532309342321984% land area)
10: Forest = 19957 points (0.7503489120561146% world area, 2.548103318394811% land area), Jungle = 18117 points (0.6355989556701217% world area, 2.548103318394811% land area)
11: Forest = 0 points (0.0% world area, 0.0% land area), Jungle = 0 points (0.0% world area, 0.0% land area)
12: Polar Seas = 87871 points (3.3037986296178214% world area, 11.21934091750616% land area)

Zaimoni, I used this formula to add up how many points the 3D map would be (2659696), does it look right to you? If so, then the rest of my scaling is probably accurate enough as well.

for (int i=-720;i<721;i++) worldsize[1] += (int)(Math.cos(Math.toRadians(i/8))*2880);

- [[User:Bomb Bloke|Bomb Bloke]] 07:12, 24 November 2009 (EST)

:: What's the target language? That controls whether you'll be nailed by integer division at i/8. (You want the highest-precision floating point available.) For Java, I would try something like

:: for (int i=-720;i<721;i++) worldsize[1] += (int)(Math.cos(Math.toRadians(i/8.0))*2880);

:: to try to get some automatic type conversions going without using an explicit cast on i. - [[User:Zaimoni|Zaimoni]] 10:35, 24 November 2009 (CST)

::: Whoops, I've spent too long dealing with integers. Well caught. - [[User:Bomb Bloke|Bomb Bloke]] 01:12, 25 November 2009 (EST)

: Rats, my percentage of polar land mass on the 2D map comes out at about 64%. Still 46% if I disclude the polar seas. Back to the drawing board, then. [[User:Bomb Bloke|Bomb Bloke]] 07:32, 24 November 2009 (EST)

Ok let me try it with Cosines used against the area of each record, based on the latitude of the centroid point for each area. One thing first, though - the WORLD.DAT page says "at the equator, each possible map location on the Geoscape occupies a square that is 111 kilometres on its side", but shouldn't it be an eighth of that? And for a WORLD.DAT record making a perfect square (0,0; 0,1; 1,1; 1,0), the area would be 193.6 km2? -[[User:MikeTheRed|MikeTheRed]] 23:06, 24 November 2009 (EST)

: Indeed, should be an eighth, as the game map is in eighths of degrees (distance between real world degrees of latitude = ~111km, varying slightly as you move around the globe). A WORLD.DAT record can't really be a "perfect" square anywhere (because our lines can't bend to properly fit the 3D shape on which they're rendered). But say you made a polygon of one unit squared at the equator, it'd be a square eighth of a degree, and so should be pretty close 193.6 km2 (192.5 km2 to my count). This changes wildly as you move towards the poles, as the distance between points of longitude shrink down to 0 as you move from the equator (unlike latitude, where distances remains roughly the same). [http://en.wikipedia.org/wiki/Longitude#Degree_length] - [[User:Bomb Bloke|Bomb Bloke]] 01:12, 25 November 2009 (EST)

P.S. Can someone remind me - is Polar Sea With Icebergs considered land, in the game (can make bases or fight UFOs there)? -[[User:MikeTheRed|MikeTheRed]] 23:10, 24 November 2009 (EST)

:Yup, you can build bases and visit UFO sites on the polar sea texture so it's considered land. Though, in some cases it's a little iffy (probably due to how the area is mapped out on the globe). --[[User:Zombie|Zombie]] 23:15, 24 November 2009 (EST)

Just for comparison, I got a global land percentage of 31.224.. The way I did it however also suffers from some mapping distortions, although not so big.. So 29.44 is probably not to wrong.. Method I used: pixel/color scan of cube.map generated images, rendered using a 3D UFO.world.sphere.. Additional data: north pole: 55.300, south pole: 21.774. --[[User:Mvgulik|Mvgulik]] 22:43, 25 November 2009 (EST)

: After scraping out a heap of integer based calculations my figures vary a bit, but they're still fairly close to what they were. I think my main problem is correctly determining when polygons cross the prime meridion and loop around to the other side: Get that wrong, and certain polys will be way out in terms of accuracy.

: Still, I figure a count of the mountain polys vs total world size should be a good benchmark. Don't think any of those loop. - [[User:Bomb Bloke|Bomb Bloke]] 19:17, 26 November 2009 (EST)

::Done them all for you. Marked the one's where your number is to high if I'm correct. Oddly mountain's is one of them. --[[User:Mvgulik|Mvgulik]] 16:26, 27 November 2009 (EST)
00: 5.7033% *
01: 1.0427%
02: 4.2849%
03: 2.9602%
04: 5.2986%
05: 0.4005% *
06: 0.3188% *
07: 3.9370%
08: 0.9793%
09: 3.0936% *
10: 1.0211% *
11: 0.0%
12: 2.1456% *
:: Giving it a second thought after comparing the numbers. I initially figured the cubemap distortion only worked one way(Up). But it probably works in both ways. So these giving values that can be above and below the real value your after. That more or less leaves only the polar regions with having a somewhat suspicious large difference.

== Flat Earth Projection ==

As noted under [[UFO Interception#Movement]]

''Your ship autopilot prefers to move along lines of latitude (parallel to the equator) for long-range travel. This is especially noticeable when charting trans-polar routes: the ship will circle around the pole instead of flying straight across it. You can shorten the route taken by directing the ship to several intermediate way points along a straight line towards your destination.''

A very clear example of this is if you take a craft at say 85 deg N, 0 deg E and set a waypoint to 85 deg N, 180 deg E (the opposite side of the pole). Instead of flying in a straight line over the surface of the earth, a great circle (in this case right over the pole), it travels along the 85th parallel.

I think the explanation for the waypointing behaviour is that the wayfinding uses what is known as the Flat Earth Approximation method of approximating a great circle. Basically it is taking polar coordinates of latitude and longitude on the surface of a sphere, and treating them as if they were x and y coordinates on a flat rectangle of 360 x +/- 90. The rectangle is 'wrapped' at 0 deg E = 360 deg E, but it does not wrap at the 'top', along the +90 deg N and -90 deg S lines.

If you imagine a craft on a flat rectangle of this type, at coordinates (0,85) heading to (180,85), it would travel along the y=85 line. On a flat plane, this is the shortest route, the Cartesian distance.

The Flat Earth method is a reasonable approximation for short distances nearer the equator. It is poor for long distances and near the poles. It's probably ok for interceptions, especially of slower craft by faster craft. The more exact methods of calculating a great circle course were possibly too expensive to be done continually during an intercept. However they could've been used for plotting paths to static waypoints, even on a 16 bit computer.

Note that the Geoscape movement engine itself is not Cartesian, it is fully aware of spherical geometry. The flat earth method is only a shortcut for the wayfinding, not a shortcut used for actual movement.

I think the behaviour at the pole cited in the example above is pretty much proof, but I guess a harder proof would be to find two cities at reasonably high latitude (away from the equator) that are on a roughly 45/135/225/315 degree bearing to each other, a reasonably long distance, then fly a Skyranger between those via waypointing. Check a gazeteer to find the actual distance and see how much the Skyranger distance (760nm per hour) differs. I'm not even sure if this is a valid test, I haven't thought it through enough. I have tested Skyrangers orbiting pole to pole and they give a very close figure for the correct radius of the Earth, that's why I believe that the actual movement model is accurate. Also, the waypointing model is accurate in the special case where you are travelling along a line of longitude (which is already a great circle). The equator is the only line of latitude that is also a great circle, so the waypointing is also valid when travelling along the equator.

[[User:Spike|Spike]] 20:06, 8 November 2010 (UTC)

== Latitude or longitude? ==

FYI:

Latitude
Latitude is used to express how far north or south you are, relative to the equator. If you are on the equator your latitude is zero. If you are near the north pole your latitude is nearly 90 degrees north. If you are near the south pole your latitude is almost 90 degrees south.

Longitude
Longitude shows your location in an east-west direction, relative to the Greenwich meridian. Places to the east of Greenwich (such as Middle East, India and Japan) have longitude angles up to 180 degrees east. Places to the west of Greenwich (such as the Atlantic and North and South America) have angles up to 180 deg west. For inputting to the satellite dish pointing calculator, longitude west figures need to be input as negative numbers.

--[[User:Volutar|Volutar]] 02:33, 23 August 2012 (EDT)

* The above is irrelevant, due to being agreed to by everyone here. The problem is that the X coordinate is longitude and the Y coordinate is latitude, so what is idiomatic English (latitude and longitude) does not describe the file contents (longitude and latitude). --[[User:Zaimoni|Zaimoni]] 02:30, 23 August 2012 (CDT)

Buying/Selling/Transferring

2012-08-22T18:26:10Z

Zaimoni: Remove self-contradiction regarding items on a transport being transferred; note about soldiers on a transferred transport

== Purchase Times ==
<center>
<table {{StdCenterTable}} width ="60%">
<tr {{StdDescTable_Heading}}>
<th>Item</th>
<th>Time (Hours)</th>
<th>Time (Days)</th></tr>
<tr><td>All Personnel</td><td>72</td><td>3</td></tr>
<tr><td>[[Skyranger|SKYRANGER]]</td><td>72</td><td>3</td></tr>
<tr><td>[[Interceptor|INTERCEPTOR]]</td><td>96</td><td>4</td></tr>
<tr><td>Craft Weapons</td><td>48</td><td>2</td></tr>
<tr><td>Craft Missiles</td><td>48</td><td>2</td></tr>
<tr><td>Cannon Rounds (×50)</td><td>96</td><td>4</td></tr>
<tr><td>HWPs</td><td>96</td><td>4</td></tr>
<tr><td>HWP Ammo</td><td>48</td><td>2</td></tr>
<tr><td>All Weapons</td><td>24</td><td>1</td></tr>
<tr><td>All Ammunition</td><td>24</td><td>1</td></tr>
<tr><td>All Equipment</td><td>24</td><td>1</td></tr>
</table>
</center>

== Non-Manufacturable Prices ==
<center>
<table {{StdCenterTable}} width ="80%">
<tr {{StdDescTable_Heading}}>
<th>Item</th>
<th>Cost ($)</th>
<th>Sale Price ($)</th>
<th>Wage/Rental ($/month)</th></tr>
<tr><td>Soldier</td><td>40,000</td><td>0</td><td>20,000</td></tr>
<tr><td>Scientist</td><td>60,000</td><td>0</td><td>30,000</td></tr>
<tr><td>Engineer</td><td>50,000</td><td>0</td><td>25,000</td></tr>
<tr><td>[[Skyranger|SKYRANGER]]</td><td>500,000</td><td>0</td><td>500,000</td></tr>
<tr><td>[[Interceptor|INTERCEPTOR]]</td><td>600,000</td><td>0</td><td>600,000</td></tr>
<tr><td>[[Stingray|Stingray Launcher]]</td><td>16,000</td><td>12,000</td><td></td></tr>
<tr><td>[[Avalanche|Avalanche Launcher]]</td><td>17,000</td><td>12,750</td><td></td></tr>
<tr><td>[[Cannon]]</td><td>30,000</td><td>22,500</td><td></td></tr>
<tr><td>Stingray Missiles</td><td>3,000</td><td>2,400</td><td></td></tr>
<tr><td>Avalanche Missiles</td><td>9,000</td><td>7,200</td><td></td></tr>
<tr><td>Cannon Rounds (×50)</td><td>1,240</td><td>1,012</td><td></td></tr>
<tr><td>[[Tank/Cannon]]</td><td>420,000</td><td>340,000</td><td></td></tr>
<tr><td>HWP Cannon Shells</td><td>200</td><td>100</td><td></td></tr>
<tr><td>[[Tank/Rocket Launcher]]</td><td>480,000</td><td>360,000</td><td></td></tr>
<tr><td>HWP Rockets</td><td>3,000</td><td>2,250</td><td></td></tr>
<tr><td>[[Pistol]]</td><td>800</td><td>600</td><td></td></tr>
<tr><td>Pistol Clip</td><td>70</td><td>52</td><td></td></tr>
<tr><td>[[Rifle]]</td><td>3,000</td><td>2,250</td><td></td></tr>
<tr><td>Rifle Clip</td><td>200</td><td>150</td><td></td></tr>
<tr><td>[[Heavy Cannon]]</td><td>6,400</td><td>4,800</td><td></td></tr>
<tr><td>HC-AP Ammo</td><td>300</td><td>225</td><td></td></tr>
<tr><td>HC-HE Ammo</td><td>500</td><td>275</td><td></td></tr>
<tr><td>HC-I Ammo</td><td>400</td><td>300</td><td></td></tr>
<tr><td>[[Auto-Cannon]]</td><td>13,500</td><td>10,125</td><td></td></tr>
<tr><td>AC-AP Ammo</td><td>500</td><td>400</td><td></td></tr>
<tr><td>AC-HE Ammo</td><td>700</td><td>560</td><td></td></tr>
<tr><td>AC-I Ammo</td><td>650</td><td>520</td><td></td></tr>
<tr><td>[[Rocket Launcher]]</td><td>4,000</td><td>3,000</td><td></td></tr>
<tr><td>Small Rocket</td><td>600</td><td>480</td><td></td></tr>
<tr><td>Large Rocket</td><td>900</td><td>720</td><td></td></tr>
<tr><td>Incendiary Rocket</td><td>1,200</td><td>960</td><td></td></tr>
<tr><td>[[Grenade]]</td><td>300</td><td>240</td><td></td></tr>
<tr><td>[[Smoke Grenade]]</td><td>150</td><td>120</td><td></td></tr>
<tr><td>[[Proximity Grenade]]</td><td>500</td><td>400</td><td></td></tr>
<tr><td>[[High Explosive]]</td><td>1,500</td><td>1,200</td><td></td></tr>
<tr><td>[[Stun Rod]]</td><td>1,260</td><td>945</td><td></td></tr>
<tr><td>[[Electro-flare]]</td><td>60</td><td>40</td><td></td></tr>
</table>
</center>

== Manufacturable Prices ==
These are the build prices "straight up", as shown in the [[manufacturing]] screen. For a more in-depth look at manufacturing, including labor costs, exotic components, etc., see [[Manufacturing Profitability]].

<table {{StdCenterTable}} width ="100%">
<tr {{StdDescTable_Heading}}>
<th>Item</th>
<th>Cost ($)</th>
<th>Sale Price ($)</th>
<th>Hours</th>
<th>[[Workshop|Workspace]]</th>
<th>[[Alien Alloys|Alloys]]</th>
<th>[[Elerium-115|Elerium]]</th>
<th>[[UFO Power Source|Power]]</th>
<th>[[UFO Navigation|Navigation]]</th></tr>
<tr><td>[[Fusion Ball Launcher]]</td><td>242,000</td><td>281,100</td><td>400</td><td>6</td><td>1</td><td></td><td></td><td></td></tr>

<tr><td>[[Laser Cannon]]</td><td>182,000</td><td>211,000</td><td>300</td><td>6</td><td></td><td></td><td></td><td></td></tr>

<tr><td>[[Plasma Beam]]</td><td>226,000</td><td>267,300</td><td>500</td><td>8</td><td></td><td>15</td><td></td><td></td></tr>
<tr><td>[[Fusion_Ball_Launcher#Fusion_Balls|Fusion Ball]]</td><td>28,000</td><td>53,300</td><td>600</td><td>6</td><td></td><td>4</td><td></td><td></td></tr>
<tr><td>[[Tank/Laser Cannon]]</td><td>500,000</td><td>594,000</td><td>1,200</td><td>25</td><td></td><td></td><td></td><td></td></tr>
<tr><td>[[Hovertank/Plasma]]</td><td>850,000</td><td>980,000</td><td>1,200</td><td>30</td><td>5</td><td>30</td><td></td><td></td></tr>
<tr><td>[[Hovertank/Launcher]]</td><td>900,000</td><td>1,043,000</td><td>1,400</td><td>30</td><td>8</td><td>25</td><td></td><td></td></tr>
<tr><td>HWP Fusion Bomb</td><td>15,000</td><td>31,500</td><td>400</td><td>25</td><td>8</td><td>5</td><td></td><td></td></tr>
<tr><td>[[Laser Pistol]]</td><td>8,000</td><td>20,000</td><td>300</td><td>2</td><td></td><td></td><td></td><td></td></tr>
<tr><td>[[Laser Rifle]]</td><td>20,000</td><td>36,900</td><td>400</td><td>3</td><td></td><td></td><td></td><td></td></tr>
<tr><td>[[Heavy Laser]]</td><td>32,000</td><td>61,000</td><td>700</td><td>4</td><td></td><td></td><td></td><td></td></tr>
<tr><td>[[Motion Scanner]]</td><td>34,000</td><td>45,600</td><td>220</td><td>4</td><td></td><td></td><td></td><td></td></tr>
<tr><td>[[Medi-Kit]]</td><td>28,000</td><td>46,500</td><td>420</td><td>4</td><td></td><td></td><td></td><td></td></tr>
<tr><td>[[Psi-Amp]]</td><td>160,000</td><td>194,700</td><td>500</td><td>4</td><td></td><td>1</td><td></td><td></td></tr>
<tr><td>[[Heavy Plasma]]</td><td>122,000</td><td>171,600</td><td>1,000</td><td>4</td><td>1</td><td></td><td></td><td></td></tr>
<tr><td>[[Heavy Plasma Clip]]</td><td>6,000</td><td>9,590</td><td>80</td><td>4</td><td></td><td>3</td><td></td><td></td></tr>
<tr><td>[[Plasma Rifle]]</td><td>88,000</td><td>126,500</td><td>820</td><td>4</td><td>1</td><td></td><td></td><td></td></tr>
<tr><td>[[Plasma Rifle Clip]]</td><td>3,000</td><td>6,290</td><td>80</td><td>4</td><td></td><td>2</td><td></td><td></td></tr>
<tr><td>[[Plasma Pistol]]</td><td>56,000</td><td>84,000</td><td>600</td><td>3</td><td>1</td><td></td><td></td><td></td></tr>
<tr><td>[[Plasma Pistol Clip]]</td><td>2,000</td><td>4,440</td><td>60</td><td>4</td><td></td><td>1</td><td></td><td></td></tr>
<tr><td>[[Blaster Launcher]]</td><td>90,000</td><td>144,000</td><td>1,200</td><td>5</td><td>1</td><td></td><td></td><td></td></tr>
<tr><td>[[Blaster Bomb]]</td><td>8,000</td><td>17,028</td><td>220</td><td>3</td><td></td><td>3</td><td></td><td></td></tr>
<tr><td>[[Small Launcher]]</td><td>78,000</td><td>120,000</td><td>900</td><td>3</td><td>1</td><td></td><td></td><td></td></tr>
<tr><td>[[Stun Bomb]]</td><td>7,000</td><td>15,200</td><td>200</td><td>2</td><td></td><td>1</td><td></td><td></td></tr>
<tr><td>[[Alien Grenade]]</td><td>6,700</td><td>14,850</td><td>200</td><td>2</td><td></td><td>2</td><td></td><td></td></tr>
<tr><td>[[Mind Probe]]</td><td>262,000</td><td>304,000</td><td>1,200</td><td>4</td><td></td><td>1</td><td></td><td></td></tr>
<tr><td>[[Personal Armor]]</td><td>22,000</td><td>54,000</td><td>800</td><td>12</td><td>4</td><td></td><td></td><td></td></tr>
<tr><td>[[Power Suit]]</td><td>42,000</td><td>85,000</td><td>1,000</td><td>16</td><td>5</td><td>5</td><td></td><td></td></tr>
<tr><td>[[Flying Suit]]</td><td>58,000</td><td>115,000</td><td>1,400</td><td>16</td><td>5</td><td>16</td><td></td><td></td></tr>
<tr><td>[[Alien Alloys]]</td><td>3,000</td><td>6,500</td><td>100</td><td>10</td><td></td><td></td><td></td><td></td></tr>
<tr><td>[[UFO Power Source]]</td><td>130,000</td><td>250,000</td><td>1,400</td><td>22</td><td>5</td><td>16</td><td></td><td></td></tr>
<tr><td>[[UFO Navigation]]</td><td>150,000</td><td>80,000</td><td>1,600</td><td>18</td><td>3</td><td></td><td></td><td></td></tr>
<tr><td>[[Firestorm]]</td><td>400,000</td><td>0</td><td>14,000</td><td>30</td><td>65</td><td></td><td>1</td><td>1</td></tr>
<tr><td>[[Lightning]]</td><td>600,000</td><td>0</td><td>18,000</td><td>34</td><td>85</td><td></td><td>1</td><td>1</td></tr>
<tr><td>[[Avenger]]</td><td>900,000</td><td>0</td><td>34,000</td><td>36</td><td>120</td><td></td><td>2</td><td>1</td></tr>
</table>

== UFO Recoverable Prices ==

<center>
<table {{StdCenterTable}} width ="40%">
<tr {{StdDescTable_Heading}}>
<th>Item</th>
<th>Sale Price ($)</th>
</tr>
<tr><td>[[Elerium-115]]*</td><td>5,000</td></tr>
<tr><td>Alien Corpses</td><td>20,000</td></tr>
<tr><td>[[Alien Food]]</td><td>5,000</td></tr>
<tr><td>[[Alien Entertainment]]</td><td>20,000</td></tr>
<tr><td>[[Alien Surgery]]</td><td>38,000</td></tr>
<tr><td>[[Examination Room]]</td><td>9,000</td></tr>
<tr><td>[[UFO Construction]]**</td><td>20,000</td></tr>
<tr><td>[[Alien Reproduction]]**</td><td>40,000</td></tr>
<tr><td>[[Alien Habitat]]**</td><td>100</td></tr>
</table>
</center>
<nowiki>*</nowiki> Elerium-115 is the only useful item in the game that can never be bought or manufactured (only recovered from UFO and Alien Base assaults), so it is recommended that you never sell it. 
<nowiki>**</nowiki> These items cannot be recovered from a UFO. They are game "artifacts" which can only be added to your inventory via an editor.

== Transfers ==
*All items and personnel take anywhere from 6 to 16 hours to transfer between bases, dependent entirely on distance. The minimum is 6 hours, even if your bases are right on top of each other! ''If anybody wants to test the fee schedule, it is probably directly related to transfer costs, so these might be able to be used to estimate or confirm each other. -[[User:MikeTheRed|MTR]]
*Transfer fees appear to be distance-related. This has not been well investigated, but for an example, see [[Known_Bugs#Sticky_Craft_Transfer_Fee_glitch|here]].
*The transfer queue can only have a maximum of 100 line items in it. "Line items" means that e.g. a one transfer of 50 Alloys only counts as one line item.
*Items transferred in a Troop Transport all only count as one line item (for the Transport). Also, you are only charged the cost of the transferring the Transport. ''(Tip courtesy NKF.)'' This can be a good way to move stuff if your transfer queue is near full. But don't forget about the [[Known_Bugs#Sticky_Craft_Transfer_Fee_glitch|Sticky Craft Transfer Fee]] when moving craft - every subsequent transfer has the cost of that craft's transport added to it, for as long as the craft is in transit!
**While soldiers do stay assigned to the Troop Transport, they cannot disembark except at their home base.
*Transferring an existing craft to a base is ''much'' quicker (6-16 hrs) than ordering a new craft for that base (72 or 96 hrs, plus arming/fueling time). If craft are urgently needed in an area, transfer craft from other base(s) in quieter areas, and (if required), order new craft for the quieter base(s).
*Transferred craft arrive with their existing weapons, fully loaded and ready for a mission. Again this is faster than newly bought craft which must go through the full arming/fueling/etc cycle.
*Transferring anything that is alive (soldiers, scientists, engineers and captured aliens) is FREE!
**Note that when transferring captured aliens, you need to have room in the target base's containment. One thing that is not terribly obvious is that these aliens in transit use up living quarter space at the target base until they arrive and are thrown into the freezer.

== See Also ==
*[[Known_Bugs#Transfer_Limit_cash_eater|Transfer Limit cash eater]]
*[[Hiring/firing]]
*[[Manufacturing Profitability]]
*[[UFO Recovery Values]]
*[[Economics]]
*[[Buying/Selling/Transferring_(TFTD)]]

[[Category:data tables]]

Talk:Open Questions

2012-07-08T09:58:37Z

Zaimoni:

Geoscape alien mission abortion??? Never heard of that...
Can anyone shed a light on this?
--[[User:Volutar|Volutar]] 00:40, 3 October 2011 (EDT)

: That's my fault. I was just restating "run away" as "abort mission". But actually I don't have any evidence that a UFO that runs from air combat, also aborts its mission. I can't remember if they attempt to return to the mission, or what they do. But UFOs will definitely attempt to break off air combat some of the time - as you found in your code dig I guess. (Good work by the way!). [[User:Spike|Spike]] 07:15, 3 October 2011 (EDT)

:: Okay then. So it's just an intercepted UFO escape action. This "open questions" list should be renewed, and all new things inserted where they need to be. Also there are another sections in ufopaedia with "unanswered" things, shouldn't they be in one place? I want to clarify all "unknown" things. --[[User:Volutar|Volutar]] 07:31, 3 October 2011 (EDT)

::: Agreed - done. [[User:Spike|Spike]] 21:22, 4 October 2011 (EDT)

== X-Com The Novel ==

In response to the open questions on the novel, I do have a copy, which I should probably take some time to re-read. From what I remember, indeed the scale of how the X-Com bases and troops were moved was quite enormous toward the end.

The novel itself was just a small snippet in the life of a commander being assigned to set up a new base, finding it was built practically on top of an alien base, and finally dealing with it (this is where we get hundreds of troops). Not really an epic start to end story, and it jumps right in the middle of things with Lightnings, Power Suits, Heavy Lasers, Heavy Plasmas, etc.

It would be standard fare for the casual sci-fi reader who might get puzzled by the technology thrown about in it. For a fan, perhaps slightly disappointing because it's not true to form.

There was one sore point I have with it where what seemed to be building up to be an epic mission with the male lead (or now that I reflect on it, just a support character) was simply skipped.

The best part of it was the opening chapter, which is coincidentally the teaser chapter that was published on-line for all to read.

There were other teaser novellas put out for TFTD too. Would be nice if we could gather them all here. -[[User:NKF|NKF]] 02:05, 5 October 2011 (EDT)

----

Can you lose Russia to the aliens?--[[User:Ditto51|Ditto51]] 04:24, 8 July 2012 (EDT)

: I haven't personally verified this, but losing Russia to the aliens appears to be possible only in 1.0; it has never been seen in (thus thought impossible for) 1.2, 1.4, and Collectors Edition. -- [[User:Zaimoni|Zaimoni]] 04:48, 8 July 2012 (CDT)

Talk:Base Farming

2012-06-22T22:49:13Z

Zaimoni:

Just for consistency it might be better to head this under Base Farming, since that's how it's referred to in various articles. -[[User:NKF|NKF]] 21:05, 19 June 2012 (EDT)

:Thanks, I have changed the page based on what you suggested. -[[User:Ditto51|Ditto51]] 11:03, 20 June 2012 (GMT)

:: Of course, to be fair, there's various terms that can describe it. I mean, leaching, farming, milking, etc. It can't hurt to mention them in the description. -[[User:NKF|NKF]] 04:49, 21 June 2012 (EDT)

Does anyone know if PSI is improved as you use it, or is just improved through the PSI Labs? -[[User:Ditto51|Ditto51]] 19:24, 22 June 2012 (GMT)

: Both means improve psi skill. As noted in the "obvious" entry here, improvement by use is subject to the stat cap of 100, but the PSI labs are not so impaired. I have not seen test results for whether premature wraparound effects have been observed, and if so whether these are version-dependent. -[[User:Zaimoni|Zaimoni]] 17:48, 22 June 2012 (CDT)

== Races ==

=== Sectoid ===

Sectoids, might still be a good option. Here's how I'm thinking: A Sectoid supply ship is quite a good way to get a Sectoid Leader. You know where it is going to be from the start of the mission, and there will only be one. So at most, three psi attacks per turn, and the leader won't be wandering too much if it keeps useing psi. The first mission against a supply ship will be drawn out as you manage your troops and their equipment (or use power suits and pistols/rifles and not worry), but once you've captured the leader you'll be able to nullify their psi advantage. They are slightly better fighters than floaters, but they cannot withstand much damage. -[[User:NKF|NKF]] 05:12, 21 June 2012 (EDT)

:True, and if you have PSI training then really it would work. Also if you de-arm men that aren't going out of the Skyranger, then even if they are Mind Controlled then they can't shoot at the others or go Berserk and shhot your other men. -[[User:Ditto51|Ditto51]] 16:15, 21 June 2012 (GMT)

==Images==

How do you add images to this wiki? -[[User:Ditto51|Ditto51]] 21:02, 21 June 2012 (GMT)

Talk:Alien Appearance Ratios

2012-06-20T05:07:47Z

Zaimoni:

Don't Alien Retaliations depend on who you shot down. So in August if you shoot down lots of Snakemen Ships they will retaliate not the Ethereals who have 40% chance to be the race on the Retalation?

: Retaliations are done in two ways. The aliens can be generated to appear on retaliation scouting missions, with the race determined by the probabilities in these tables. This means any race can start scouting for X-Com bases to attack even if you haven't shot down any UFOs of that particular race. They still have to find your base to attack it though.

: The other method is the instant base attack. Every time you shoot down a UFO, the game has a 2% chance to instantly retaliate against the interceptor's home base and will send a battleship straight to the base without having to scout for it. In this scenario, the race is determined by the crew of the UFO you shot down.

: I think it was determined that researching the Martian Solution (or was it Cydonia or Bust?) may generate a base attack as well. -[[User:NKF|NKF]] 17:21, 19 June 2012 (EDT)

:: I have never seen either of those ways in the Collector's Edition. The only way that works in the Collectors Edition (verified by examining MISSIONS.DAT) is to shoot down a UFO, which has a difficulty-level dependent probability of immediately generating a Retaliation scouting mission of the same race as the one you shot down.

:: Note that since DOS does not do an awesome job of default-initializing its files, that garbage data in XBASES.DAT can do strange things. For the Collector's Edition, correctly tweaking that file will convert the next mission by that race into a base attack, and cause the scheduled mission to be rescheduled for later. -[[User:Zaimoni|Zaimoni]] 17:21, 19 June 2012 (EDT)

Zaimoni's XCOM1 Editor

2012-03-31T18:37:50Z

Zaimoni:

[[Image:ZaiXcomSuite.0.1.zip|ZaiXcomSuite.0.1.zip]]

This set of DOS batch files and Python 2.5.x scripts is a command-line savegame editor and turn-swapping utility. You will also need the (http://www.python.org/) Python scripting language installed. Unzip into c:\mps\ufo (will need editing if the XCOM1 install is elsewhere)

The Python scripts should work with Python 2.6.x and 2.7.x as well.
* They will not work with Python 2.4.x due to undocumented incompatible changes in the struct module, and presumably will not work with earlier versions either.
* They will not work with Python 3 due to pointless, gratuitous changes in the Python language, including but not limited to renaming xrange to range.

Usage:
* Soldier.py : Soldier and battlescape editor. Intended to run from the savegame directory being edited: <code>..\Soldier.py ....</code>
* Base.py : Base editor. Intended to run from the savegame directory being edited: <code>..\Base.py ....</code>
* Transfer.py : Transfer editor. Intended to run from the savegame directory being edited: <code>..\Transfer.py ....</code>
* Omniview.py : lights whole map, reveals whole map, renders all aliens visible.
* PrepareSWP.py : Prepares a battlescape savegame for turnswapping. Run from the savegame directory to be enabled: <code>..\PrepareSWP.py</code>
* Alienturn.bat : Swaps a game from the human player to the alien player. Run from the main directory, e.g. <code>Alienturn.bat game_8</code>
* Humanturn.bat : Swaps a game from the alien player to the human player. Run from the main directory, e.g. <code>Humanturn.bat game_8</code>
* XCOM1.py : some numerical utilities for tactical analysis. Run from the main directory as <code>python -i XCOM1.py</code> (it's meant to be used in interactive mode).

AutoClose.py may also be useful for repairing savefiles with UFO doors stuck open. Run from the savegame directory to be fixed: <code>..\AutoClose.py</code>
<hr>
<tt>Base.py</tt>

<code>Supported subcommands for Base.py
unbuild_dirt:
sets days-to-completion for dirt to 255/-1 (never) at all bases. This bypasses
a bug.
fast_construction:
forces all in-construction facilities to complete at next midnight. Cheat.
instant_construction:
forces all in-construction facilities to complete instantly. Cheat. Not smart
enough to handle radars or hyperwave detectors.
overview Name:
lists all items in inventory at base Name.</code>

<tt>Soldier.py</tt>

<code>Supported subcommands for Soldier.py
list
lists soldier names in internal order.
sort:
sorts soldiers according to the function SOLDIERS_CMP.
Soldiers in transit will be left in place to prevent eliciting gross bugs.
rename OldName NewName:
renames soldier from oldname to newname. NewName will be truncated to fit, if
needed.
swap Name1 Name2:
swaps the soldiers named Name1 and Name2.
max_recruit Name:
sets recruit stats for Name to maximum. Cheat.
inactive Name:
reduces mission count and score for Name by 1. Cheat.
battlescape
military intelligence overview...vaguely like XCOMUtil DIS:2
facing [unitref index] [facing]
changes facing of target index
transpose [unitref index] [unitref index]
transposes two units on the battlescape. Unreliable in the presence of
large units.</code>
<hr>The shipped sort order is moderately useful if you want psi-weakings to soak reaction fire.

<tt>Transfer.py</tt>

<code>Supported subcommands for Transfer.py

fast_shipment:
forces all in-progress transfers to arrive at the next hour transition. Cheat.</code>

==See Also==
[[User_talk:Zaimoni]]

File:ZaiXcomSuite.0.1.zip

2012-03-31T18:33:56Z

Zaimoni: uploaded a new version of "File:ZaiXcomSuite.0.1.zip": * Soldier sort does not reorder soldiers assigned to craft, but does move them to top. * Battlescape view has AI mode appended to alien view * Omniview.py: see everything

Python-based XCOM1 savefile editor

File:ZaiXcomSuite.0.1.zip

2012-03-31T18:29:51Z

Zaimoni: uploaded a new version of "File:ZaiXcomSuite.0.1.zip": Reverted to version as of 00:53, 31 December 2010

Python-based XCOM1 savefile editor

File:ZaiXcomSuite.0.1.zip

2012-03-31T18:27:13Z

Zaimoni: uploaded a new version of "File:ZaiXcomSuite.0.1.zip": * Soldier sort does not reorder soldiers assigned to craft, but does move them to the top * Omniview.py : reveals whole map, lights it up, reveals all aliens.

Python-based XCOM1 savefile editor

Blind Spots From First Principles

2012-03-27T15:37:57Z

Zaimoni:

(Strictly speaking for XCOM1, but should generalize to XCOM2 and Apocalypse.)

[[User:Zaimoni|Zaimoni]]: It's a parallelogram problem: the two lines of fire are not coincident, and the displacement between the firing point and the center is "just enough" to create the blind spot.

Facing table [firer is at relative coordinates (0,0)]
{|
! borderline facing || target || real facing
|-
| N-NE || (-2,1) || N/0 ||
|-
| E-NE || (-1,2) || NE/1 ||
|-
| E-SE || (1,2) || E/2 ||
|-
| S-SE || (2,1) || SE/3 ||
|-
| S-SW || (2,-1) || S/4 ||
|-
| W-SW || (1,-2) || SW/5 ||
|-
| W-NW || (-1,-2) || W/6 ||
|-
| N-NW || (-2,-1) || NW/7 ||
|}

Partial firing voxel table (from Seb76's work):
{|
! facing || internal x-y coordinates of voxel ||
|-
| N/0 || (8,1) ||
|-
| NE/1 || (14,1) ||
|-
| E/2 || (15,8) ||
|-
| SE/3 || (15,15) ||
|-
| S/4 || (8,15) ||
|-
| SW/5 || (1,15) ||
|-
| W/6 || (1,8) ||
|-
| NW/7 || (1,1) ||
|}

(Following to be revised)
Example: north wall in square 1 south of unit, ambusher unit facing SE (facing 3). Defender facing when returning fire is 7. Assuming a "sane" pixel-line drawing algorithm:
* If the resulting firing line has classical SE slope strictly exceeding 2, the ambusher's firing line should hit the north wall and not be an issue.
* If the classical SE slope is exactly 2, we have an edge case and the actual line-tracing algorithm determines whether the ambusher has a line of fire.
* Due SE isn't a blind spot.
* In both cases, we have a 8-pixel diagonal line (containing the endpoints) between the unit's centroid at (8,8) and the firing origin. The defender can return fire if his line of fire goes through the ambusher's firing origin, otherwise he is blind. [This only makes sense because we're analyzing in voxelspace.) The critical classical SE slope is 15/14; for this slope, the actual line-tracing algorithm determines whether the ambusher has a line of fire.

Without loss of generality, consider the ambusher to be at (0,0); we wish to identify squares with range 19 or less in (1..18,1..18) that should be ambushable.

{|
! target || ambush line of fire || SE slope || targetable? || ambush?
|-
| (2,1) || ((-15, 15), (-40, 24)) || 25/9 || no ||
|-
| (3,2) || ((-15, 15), (-56, 40)) || 41/25 || yes || yes
|-
| (4,2) || ((-15, 15), (-72, 40)) || 57/25 || no ||
|-
| (4,3) || ((-15, 15), (-72, 56)) || 57/41 || yes || yes
|-
| (5,3) || ((-15, 15), (-88, 56)) || 73/41 || no ||
|-
| (5,4) || ((-15, 15), (-88, 72)) || 73/57 || yes || yes
|-
| (6,4) || ((-15, 15), (-104, 72)) || 89/57 || yes || yes
|-
| (7,4) || ((-15, 15), (-120, 72)) || 105/57 || yes || yes
|-
| (8,4) || ((-15, 15), (-136, 72)) || 121/57 || yes || yes
|-
| (6,5) || ((-15, 15), (-104, 88)) || 89/73 || yes || yes
|-
| (7,5) || ((-15, 15), (-120, 88)) || 105/73 || yes || yes
|-
| (8,5) || ((-15, 15), (-136, 88)) || 121/73 || yes || yes
|-
| (9,5) || ((-15, 15), (-152, 88)) || 137/73 || yes || yes
|-
| (10,5) || ((-15, 15), (-168, 88)) || 153/73 || no ||
|-
| (7,6) || ((-15, 15), (-120, 104)) || 105/87 || yes || yes
|-
| (8,6) || ((-15, 15), (-136, 104)) || 121/87 || yes || yes
|-
| (9,6) || ((-15, 15), (-152, 104)) || 137/87 || yes || yes
|-
| (10,6) || ((-15, 15), (-168, 104)) || 153/87 || yes || yes
|-
| (11,6) || ((-15, 15), (-184, 104)) || 169/87 || yes || yes
|-
| (12,6) || ((-15, 15), (-200, 104)) || 185/87 || no ||
|-
| (8,7) || ((-15, 15), (-136, 120)) || 121/103 || yes || yes
|-
| (9,7) || ((-15, 15), (-152, 120)) || 137/103 || yes || yes
|-
| (10,7) || ((-15, 15), (-168, 120)) || 153/103 || yes || yes
|-
| (11,7) || ((-15, 15), (-184, 120)) || 169/103 || yes || yes
|-
| (12,7) || ((-15, 15), (-200, 120)) || 185/103 || yes || yes
|-
| (13,7) || ((-15, 15), (-216, 120)) || 201/103 || yes || yes
|-
| (14,7) || ((-15, 15), (-232, 120)) || 217/103 || no ||
|-
| (9,8) || ((-15, 15), (-152, 136)) || 137/119 || yes || yes
|-
| (10,8) || ((-15, 15), (-168, 136)) || 153/119 || yes || yes
|-
| (11,8) || ((-15, 15), (-184, 136)) || 169/119 || yes || yes
|-
| (12,8) || ((-15, 15), (-200, 136)) || 185/119 || yes || yes
|-
| (13,8) || ((-15, 15), (-216, 136)) || 201/119 || yes || yes
|-
| (14,8) || ((-15, 15), (-232, 136)) || 217/119 || yes || yes
|-
| (15,8) || ((-15, 15), (-248, 136)) || 233/119 || yes || yes
|-
| (10,9) || ((-15, 15), (-168, 152)) || 153/135 || yes || yes
|-
| (11,9) || ((-15, 15), (-184, 152)) || 169/135 || yes || yes
|-
| (12,9) || ((-15, 15), (-200, 152)) || 185/135 || yes || yes
|-
| (13,9) || ((-15, 15), (-216, 152)) || 201/135 || yes || yes
|-
| (14,9) || ((-15, 15), (-232, 152)) || 217/135 || yes || yes
|-
| (15,9) || ((-15, 15), (-248, 152)) || 233/135 || yes || yes
|-
| (11,10) || ((-15, 15), (-184, 168)) || 169/151 || yes || yes
|-
| (12,10) || ((-15, 15), (-200, 168)) || 185/151 || yes || yes
|-
| (13,10) || ((-15, 15), (-216, 168)) || 201/151 || yes || yes
|-
| (14,10) || ((-15, 15), (-232, 168)) || 217/151 || yes || yes
|-
| (12,11) || ((-15, 15), (-200, 184)) || 185/167 || yes || yes
|-
| (13,11) || ((-15, 15), (-216, 184)) || 201/167 || yes || yes
|-
| (14,11) || ((-15, 15), (-232, 184)) || 217/167 || yes || yes
|-
| (13,12) || ((-15, 15), (-216, 200)) || 201/183 || yes || yes
|}

[Yes, strictly speaking all of those classical slopes are negative, but that's implied (for this choice of coordinates) by specifying a southeast bearing.]

We have a dual analysis and table for ambusher with west wall one square east.

Python 2.6 source code for constructing the ambush line of fire for the above table follows (should also be in the next update to my XCOM editor suite as XCOM1.py):
<pre># Voxelspace: 0..15,0..15,0,23..0 internal coordinates
fire_voxel_x_y_from_facing = ((1,8),(1,14),(8,15),(15,15),(15,8),(15,1),(8,1),(1,1))

# coords are internal-square: row,col format with 0,0 at upper-left
# we need to self-test this
def facing_from_coords(src,dest):
delta = (dest[0]-src[0],dest[1]-src[1])
if 0==delta[0]:
if 0<delta[1]:
return 2
else:
return 6
elif 0==delta[1]:
if 0<delta[0]:
return 4
else:
return 0
elif 0<delta[0]:
if 0<delta[1]:
if 2*delta[0]<=delta[1]:
return 2
elif 2*delta[1]<delta[0]:
return 4
else:
return 3
else: #if 0>delta[1]
if 2*delta[0]<-delta[1]:
return 6
elif -2*delta[1]<=delta[0]:
return 4
else:
return 5
else: #if 0>delta[0]
if 0<delta[1]:
if -2*delta[0]<delta[1]:
return 2
elif 2*delta[1]<=-delta[0]:
return 0
else:
return 1
else: #if 0>delta[1]
if -2*delta[0]<=-delta[1]:
return 6
elif -2*delta[1]<-delta[0]:
return 0
else:
return 7

# yes, Voxelspace rows are reverse-order to coordinate rows
def convert_firearm_attack_unit_coords_from_map_to_voxels(src,dest):
fire_offset = fire_voxel_x_y_from_facing[facing_from_coords(src,dest)]
return ((-16*src[0]-fire_offset[0],16*src[1]+fire_offset[1]),(-16*dest[0]-8,16*dest[1]+8))
</pre>

==See Also==

[[Line of sight]]

[[User talk:Bomb Bloke:Firing Accuracy]]

Blind Spots From First Principles

2012-03-27T15:09:09Z

Zaimoni:

(Strictly speaking for XCOM1, but should generalize to XCOM2 and Apocalypse.)

[[User:Zaimoni|Zaimoni]]: It's a parallelogram problem: the two lines of fire are not coincident, and the displacement between the firing point and the center is "just enough" to create the blind spot.

Facing table [firer is at relative coordinates (0,0)]
{|
! borderline facing || target || real facing
|-
| N-NE || (-2,1) || N/0 ||
|-
| E-NE || (-1,2) || NE/1 ||
|-
| E-SE || (1,2) || E/2 ||
|-
| S-SE || (2,1) || SE/3 ||
|-
| S-SW || (2,-1) || S/4 ||
|-
| W-SW || (1,-2) || SW/5 ||
|-
| W-NW || (-1,-2) || W/6 ||
|-
| N-NW || (-2,-1) || NW/7 ||
|}

(Following to be revised)
Example: north wall in square 1 south of unit, ambusher unit facing SE (facing 3). Defender facing when returning fire is 7. Assuming a "sane" pixel-line drawing algorithm:
* If the resulting firing line has classical SE slope strictly exceeding 2, the ambusher's firing line should hit the north wall and not be an issue.
* If the classical SE slope is exactly 2, we have an edge case and the actual line-tracing algorithm determines whether the ambusher has a line of fire.
* Due SE isn't a blind spot.
* In both cases, we have a 8-pixel diagonal line (containing the endpoints) between the unit's centroid at (8,8) and the firing origin. The defender can return fire if his line of fire goes through the ambusher's firing origin, otherwise he is blind. [This only makes sense because we're analyzing in voxelspace.) The critical classical SE slope is 15/14; for this slope, the actual line-tracing algorithm determines whether the ambusher has a line of fire.

Without loss of generality, consider the ambusher to be at (0,0); we wish to identify squares with range 19 or less in (1..18,1..18) that should be ambushable.

{|
! target || ambush line of fire || SE slope || targetable? || ambush?
|-
| (2,1) || ((-15, 15), (-40, 24)) || 25/9 || no ||
|-
| (3,2) || ((-15, 15), (-56, 40)) || 41/25 || yes || yes
|-
| (4,2) || ((-15, 15), (-72, 40)) || 57/25 || no ||
|-
| (4,3) || ((-15, 15), (-72, 56)) || 57/41 || yes || yes
|-
| (5,3) || ((-15, 15), (-88, 56)) || 73/41 || no ||
|-
| (5,4) || ((-15, 15), (-88, 72)) || 73/57 || yes || yes
|-
| (6,4) || ((-15, 15), (-104, 72)) || 89/57 || yes || yes
|-
| (7,4) || ((-15, 15), (-120, 72)) || 105/57 || yes || yes
|-
| (8,4) || ((-15, 15), (-136, 72)) || 121/57 || yes || yes
|-
| (6,5) || ((-15, 15), (-104, 88)) || 89/73 || yes || yes
|-
| (7,5) || ((-15, 15), (-120, 88)) || 105/73 || yes || yes
|-
| (8,5) || ((-15, 15), (-136, 88)) || 121/73 || yes || yes
|-
| (9,5) || ((-15, 15), (-152, 88)) || 137/73 || yes || yes
|-
| (10,5) || ((-15, 15), (-168, 88)) || 153/73 || no ||
|-
| (7,6) || ((-15, 15), (-120, 104)) || 105/87 || yes || yes
|-
| (8,6) || ((-15, 15), (-136, 104)) || 121/87 || yes || yes
|-
| (9,6) || ((-15, 15), (-152, 104)) || 137/87 || yes || yes
|-
| (10,6) || ((-15, 15), (-168, 104)) || 153/87 || yes || yes
|-
| (11,6) || ((-15, 15), (-184, 104)) || 169/87 || yes || yes
|-
| (12,6) || ((-15, 15), (-200, 104)) || 185/87 || no ||
|-
| (8,7) || ((-15, 15), (-136, 120)) || 121/103 || yes || yes
|-
| (9,7) || ((-15, 15), (-152, 120)) || 137/103 || yes || yes
|-
| (10,7) || ((-15, 15), (-168, 120)) || 153/103 || yes || yes
|-
| (11,7) || ((-15, 15), (-184, 120)) || 169/103 || yes || yes
|-
| (12,7) || ((-15, 15), (-200, 120)) || 185/103 || yes || yes
|-
| (13,7) || ((-15, 15), (-216, 120)) || 201/103 || yes || yes
|-
| (14,7) || ((-15, 15), (-232, 120)) || 217/103 || no ||
|-
| (9,8) || ((-15, 15), (-152, 136)) || 137/119 || yes || yes
|-
| (10,8) || ((-15, 15), (-168, 136)) || 153/119 || yes || yes
|-
| (11,8) || ((-15, 15), (-184, 136)) || 169/119 || yes || yes
|-
| (12,8) || ((-15, 15), (-200, 136)) || 185/119 || yes || yes
|-
| (13,8) || ((-15, 15), (-216, 136)) || 201/119 || yes || yes
|-
| (14,8) || ((-15, 15), (-232, 136)) || 217/119 || yes || yes
|-
| (15,8) || ((-15, 15), (-248, 136)) || 233/119 || yes || yes
|-
| (10,9) || ((-15, 15), (-168, 152)) || 153/135 || yes || yes
|-
| (11,9) || ((-15, 15), (-184, 152)) || 169/135 || yes || yes
|-
| (12,9) || ((-15, 15), (-200, 152)) || 185/135 || yes || yes
|-
| (13,9) || ((-15, 15), (-216, 152)) || 201/135 || yes || yes
|-
| (14,9) || ((-15, 15), (-232, 152)) || 217/135 || yes || yes
|-
| (15,9) || ((-15, 15), (-248, 152)) || 233/135 || yes || yes
|-
| (11,10) || ((-15, 15), (-184, 168)) || 169/151 || yes || yes
|-
| (12,10) || ((-15, 15), (-200, 168)) || 185/151 || yes || yes
|-
| (13,10) || ((-15, 15), (-216, 168)) || 201/151 || yes || yes
|-
| (14,10) || ((-15, 15), (-232, 168)) || 217/151 || yes || yes
|-
| (12,11) || ((-15, 15), (-200, 184)) || 185/167 || yes || yes
|-
| (13,11) || ((-15, 15), (-216, 184)) || 201/167 || yes || yes
|-
| (14,11) || ((-15, 15), (-232, 184)) || 217/167 || yes || yes
|-
| (13,12) || ((-15, 15), (-216, 200)) || 201/183 || yes || yes
|}

[Yes, strictly speaking all of those classical slopes are negative, but that's implied (for this choice of coordinates) by specifying a southeast bearing.]

We have a dual analysis and table for ambusher with west wall one square east.

Python 2.6 source code for constructing the ambush line of fire for the above table follows (should also be in the next update to my XCOM editor suite as XCOM1.py):
<pre># Voxelspace: 0..15,0..15,0,23..0 internal coordinates
fire_voxel_x_y_from_facing = ((1,8),(1,14),(8,15),(15,15),(15,8),(15,1),(8,1),(1,1))

# coords are internal-square: row,col format with 0,0 at upper-left
# we need to self-test this
def facing_from_coords(src,dest):
delta = (dest[0]-src[0],dest[1]-src[1])
if 0==delta[0]:
if 0<delta[1]:
return 2
else:
return 6
elif 0==delta[1]:
if 0<delta[0]:
return 4
else:
return 0
elif 0<delta[0]:
if 0<delta[1]:
if 2*delta[0]<=delta[1]:
return 2
elif 2*delta[1]<delta[0]:
return 4
else:
return 3
else: #if 0>delta[1]
if 2*delta[0]<-delta[1]:
return 6
elif -2*delta[1]<=delta[0]:
return 4
else:
return 5
else: #if 0>delta[0]
if 0<delta[1]:
if -2*delta[0]<delta[1]:
return 2
elif 2*delta[1]<=-delta[0]:
return 0
else:
return 1
else: #if 0>delta[1]
if -2*delta[0]<=-delta[1]:
return 6
elif -2*delta[1]<-delta[0]:
return 0
else:
return 7

# yes, Voxelspace rows are reverse-order to coordinate rows
def convert_firearm_attack_unit_coords_from_map_to_voxels(src,dest):
fire_offset = fire_voxel_x_y_from_facing[facing_from_coords(src,dest)]
return ((-16*src[0]-fire_offset[0],16*src[1]+fire_offset[1]),(-16*dest[0]-8,16*dest[1]+8))
</pre>

==See Also==

[[Line of sight]]

[[User talk:Bomb Bloke:Firing Accuracy]]

UNITREF.DAT

2012-03-26T17:46:32Z

Zaimoni: recalculate marker for AI mode observed

A [[Saved Game Files|save game file]] that has a record size of 124 bytes for UFO, or 132 for TFTD. Values are unsigned unless otherwise stated. Some bytes represent bitfields. There are 80 records (not all of them necessarily used) for a fixed file size of 9,920 bytes (or 10,560 for TFTD). It goes hand in hand with [[UNITPOS.DAT]].

Comes in three flavours: 

*UNIREF.DAT 
Initially created by the GeoScape engine before tactical battles. Stored in the [[Saved_Game_Files#Missdat_Files|MISSDAT]] folder and contains info on all units that will be present in the coming mission (in an alive state - the deaths of aliens killed by exploding UFO power units isn't determined until [[Battlescape_Map_Generation#KABOOM.21.21|later]]). Unlike the other two versions, this only contains the bare minimum number of records required to store the units it details. 

*UNITREF.DAT 
Created along with a [[Saved_Game_Files#Battlescape_Files|battlescape save]], contains the mid-mission state of the unit table. 

*UNIREF2.DAT 
Appears in the [[Saved_Game_Files#Missdat_Files|MISSDAT]] folder at the end of combat. Used to determine which troopers/tanks survived, statistic gains via [[experience]], and which aliens need to be hauled off to the [[Alien Containment]] unit. 

Values are presented according to byte offset ([[#0|0]] to [[#123|123]] (or [[#131|131]] for TFTD)) followed by the equivalent hex offset ([[#0x00|0x00]] to [[#0x7B|0x7B]] (or [[#0x83|0x83]] for TFTD)). Notes apply to both UFO and TFTD unless otherwise stated. Let us know what else you can find - refer to the [[#Notes|bottom of the page]] for those values that're unknown, or to the [[Talk:UNITREF.DAT|talk page]] for further ideas as to what they could be.

== Structure ==

{| class="wikitable"
|-
!Offset (Decimal)
!Offset (Hex)
!Usage
|- valign="top"
!0
!0x00
|Type of unit. Unit scream and movement sound effects are based on this and gender. Gender and flying abilities affect the sprites as well. Not turrets. Specifically: [[#53|[53]]] & [[#54|[54]]] (weapons in hands), [[#115|[115]]] (gender) and [[#120|[120]]] (other flags) affect the final screen image. If the unit is a large unit, this will also determine the appearance of the last three quarters of the unit. This does NOT affect: the flying ability of the unit, the soldier image in the inventory screen, or the special abilities for certain aliens.
UFO TFTD
0: Male/female unarmored X-COM soldier 0: Male/female unarmored X-COM diver
1: Male/female personal armor soldier 1: Male/female plastic armor diver
2: Power/flying suit soldier 2: Power/flying suit diver
3: Tank 3: Tank
4: Sectoid 4: Aquatoid
5: Snakeman 5: Gillman
6: Ethereal 6: Lobster Man
7: Muton 7: Tasoth
8: Floater 8: Calcinite
9: Celatid 9: Deep One
10: Silacoid 10: BioDrone
11: Chryssalid 11: Tentaculat
12: Reaper 12: Triscene
13: Sectopod 13: Hallucinoid
14: Cyberdisc 14: Xarquid
15: Male civilian 15: Male civilians
16: Female civilian 16: Female civilians
17: Zombie 17: Zombie
255: Unused 255: Unused

<blockquote>If the corresponding [[UNITPOS.DAT]] record is unused, then the record is unused.</blockquote>
|- valign="top"
!1
!0x01
|Inventory paper doll image. File "UFOGRAPH\MAN_"+(char)(value + 48)+".SPK" will be used as the inventory sprite, unless the value is 0 or 1. In those cases, [[#115|[115]]] and [[#116|[116]]] are used to determine the picture.
0: No armor.
1: Personal armour.
2: Power suit.
3: Flying suit.
|- valign="top"
!2-5
!0x02-0x05
|Four byte value pointing to RAM location of the [[Image_Formats#PCK|PCK set]] used by the unit. Re-determined when the save game is loaded.
|- valign="top"
!6-9
!0x06-0x09
|Four byte value pointing to RAM location of the [[Image_Formats#PCK|TAB index for the PCK data]] used by the unit. Re-determined when the save game is loaded.
|- valign="top"
!10
!0x0A
|Unit facing. Does NOT control HWP turret direction; see [[#24|[24]]].
0: North (up right)
1: Northeast (right)
2: East (down right)
3: Southeast (down)
4: South (down left)
5: Southwest (left)
6: West (up left)
7: Northwest (up)
|- valign="top"
!11
!0x0B
|Movement type. When entering a given map location, each tile is checked to see the TU requirements accordingly. [[MCD]][39+[[#11|UnitRef[11]]]] is the offset used. Note: By default, this is 0 for ALL unit types.
0: Walking
1: Sliding
2: Flying
|- valign="top"
!12
!0x0C
|Current TUs.
|- valign="top"
!13
!0x0D
|Current Health. Health of 0 = Dead. Compare [[#42|[42]]], [[#120|[120]]].

''For my [[Talk:Bravery|Bravery experience point testing]], I killed 15 of 16 aliens by setting this to zero, and my soldiers to 0 Morale. When I loaded the savegame, the aliens were still "alive" (i.e., up), then all died when I ended this turn. So death is probably only checked when injury happens, and at end of turn... to truly kill them dead on the ground through savegame editing must take more. And arg - when they all died, my soldiers all went to 100 Morale! So I edited them back to 0 Morale. But guess what... then all the aliens died '''again''' at the end of '''next''' turn, even though they were all on the ground (I heard screams, and all soldiers' Morale went to 100 again). What the heck? The aliens stayed down after that, though. --[[User:MikeTheRed|MikeTheRed]] 16:01, 3 November 2006 (PST)''

''Update: [[UNITPOS.DAT]] offset 10 bit 2 should be used to kill a unit entirely dead. Thanks, NKF & BB - MTR''

: ''While the game kills characters when Health<=Fatal Wounds (__ dies message), XComUtil will recover them based if their health is greater than 0. Haven't tested an unmodified game. --[[User:Zaimoni|Zaimoni]] 11:52, 14 April 2007 (CDT)''
|- valign="top"
!14
!0x0E
|Current Stun level ''how much falloff of paralysis every turn? What determines it?''
|- valign="top"
!15
!0x0F
|Current Energy
|- valign="top"
!16
!0x10
|Current Reactions ''NKF: affected by health percentage''
|- valign="top"
!17
!0x11
|Strength
|- valign="top"
!18
!0x12
|Current Front Armour
|- valign="top"
!19
!0x13
|Current Left Armour
|- valign="top"
!20
!0x14
|Current Right Armour
|- valign="top"
!21
!0x15
|Current Rear Armour
|- valign="top"
!22
!0x16
|Current Under Armour
|- valign="top"
|colspan="3"|"Base" means the original (total) value (as carried forward from geoscape) - Also see Note 1 re: Base soldier stat values.
|- valign="top"
!23
!0x17
|Base Firing accuracy. Current value = this * [[#13|[13]]]/[[#26|[26]]] (percent health)
|- valign="top"
!24
!0x18
|Base Throwing accuracy. Current value = this * [[#13|[13]]]/[[#26|[26]]] (percent health)

Note: Tanks (turreted units?) always have 0 throwing accuracy. They use this for turret facing, relative to unit facing. 0 means it's facing forwards. Additional values are clockwise increments; see [[#10|[10]]].
|- valign="top"
!25
!0x19
|Base TUs
|- valign="top"
!26
!0x1A
|Base Health
|- valign="top"
!27
!0x1B
|Base Energy
|- valign="top"
!28
!0x1C
|Base Reactions
|- valign="top"
|colspan="3"|''These Base Armour values are used to show the starting armor value in the Attributes screen (so you can readily see if it's been damaged''
|- valign="top"
!29
!0x1D
|Base Front Armour
|- valign="top"
!30
!0x1E
|Base Left Armour
|- valign="top"
!31
!0x1F
|Base Right Armour
|- valign="top"
!32
!0x20
|Base Rear Armour
|- valign="top"
!33
!0x21
|Base Under Armour
|- valign="top"
!34
!0x22
|Always 0? [Unused]
|- valign="top"
!35
!0x23
|Energy to recharge each turn. Equals '''recruit initial''' TUs/3 ([[SOLDIER.DAT]][43], '''not''' total base TUs). This is a signed byte. See [[Time Units]] and [[Energy#Usage|Energy Usage]]; also see [[#45|[45]]] (energy usage when walking/turning). ''BombBloke: Is this affected by damage?''
|- valign="top"
!36
!0x24
|Always 0? [Unused]
|- valign="top"
!37
!0x25
|Psi skill. Psi stats not displayed/usable until this is greater then 0.
|- valign="top"
!38
!0x26
|Item to create when unit is unconscious/dead (index into obdata.dat).

NKF: If you set this value to that of a usable item, the item that is created in place of the unconscious or dead soldier can be used like the ordinary item. Elerium pods, for example, can be recovered for 50 elerium each after the battle. Weapons can be used as you normally use them, etc.

For unconscious 'units', the item will be treated as the unconscious body - it will retain the name of the unconscious unit when looked at via the inventory screen. Picking up and using the 'item' will work, but when the unit wakes up, the 'item' image in the soldier's hands is not cleared, even though the item no longer 'exists' in the soldier's hands. Using this 'item' will just crash the battlescape.

Actually, I do not even want to think about what would happen if you 'prime' a grenade/stunned body.
|- valign="top"
!39
!0x27
|"Soldier value" a.k.a. victory points. You gain (or lose, as the case may be) score at the end of combat according to this value when the unit dies.
*For X-COM units: A soldier with 42 will be worth -42 points if killed. Note this doesn't seem to apply if the soldier is killed when unconscious. The soldier just vanishes.
*For aliens: A commander with 35 will give you +35 points if killed.
*This value is the same as [[SOLDIER.DAT]] bytes 15-16 (a Word) and equals:
20 + Missions + Rank Bonus

with [[Rank]] Bonus as follows: SGT +1, CPT +3, COL +6, CDR +10
Note that although this equation holds true, the value is not actually computed per se. Instead, 1 is added directly to it each mission, as is a rank-bonus delta if you advance (e.g. COL to CDR, delta +4). In other words, hacking the Missions or Rank fields does not affect this value.
|- valign="top"
!40
!0x28
|Index into [[SOLDIER.DAT]], so game knows what to update. 255 = does not belong to anyone (i.e., it's not a soldier). ''NKF: This byte is critical for player controlled units. If this doesn't refer to anything, the unit ceases to exist at the end of the game. If it points to a valid soldier entry in soldier.dat, the soldier.dat entry will be updated.''
|- valign="top"
!41
!0x29
|Animation frame counter for the unit. Used by eg [[Celatid]]s and [[Silacoid]]s.
|- valign="top"
!42
!0x2A
|Rank. Affects morale loss and interface icon (hull for tanks). Only X-COM troopers display rank icons.
X-COM
0: Rookie ''Civvies are 0 too''
1: Squaddie
2: Sergeant
3: Captain
4: Colonel
5: Commander
255: Dead/unused

Aliens
1: Commander
2: Leader
3: Engineer
4: Medic
5: Navigator
6: Soldier
7: Terrorist
255: Dead/unused

Hull shape for X-COM tanks:
0: Treaded
1: Hover
''I don't see 255 set for three dead mutons in a current game... [[#13|[13]]] (Health=0) seems to be the only reliable death indicator for them. Compare [[#120|[120]]]. -[[User:MikeTheRed|MikeTheRed]]''
|- valign="top"
!43
!0x2B
|0 or 1? In Hobbes' savegame, civvies and sectoids are 1. All others are 0 (soldiers, aliens, terrorists, tank).

''MTR: If the next byte is "aggression", and civvies and sectoids have a 1 here, could this be "cowardliness"? Likelihood to panic; to do something dumb/random? We've all seen civvies running around in a mad / random panic.''
|- valign="top"
!44
!0x2C
|Alien aggression. The higher it is, the less likely an alien will take cover. Maximum of 2. ''MTR: This is true for aliens in Hobbes game, but soldiers have values from 4 to 254. Garbage? Delete this comment if so.''
|- valign="top"
!45
!0x2D
|Used to calculate energy loss when walking or turning as: INT( TUs / 2[45] ). See [[Energy#Usage]]; compare [[#35|[35]]] (energy recharge per turn). Set this byte to 4 to ensure no energy use whatsoever (maximum map [[Time Units#Time_Unit_Walking_Usage_Tables|tile TU cost]] is 12). ''In Hobbes game, many aliens are 0 and all soldiers are 1, but a dozen aliens have higher values ranging all the way up to 112! Garbage and/or the game doesn't care if they are garbage?''
|- valign="top"
!46
!0x2E
|HWP turret image. Only used (and only appears) if unit type [[#0|[0]]]=3 (X-COM tanks):
0: Cannon
1: Rocket
2: Laser
3: Plasma
4: Blaster
5,6: ? Blanks
'''Note:''' For non-tanks, this controls the inventory layout. ''Only'' 0 and 1 are valid. 0 is the standard layout seen on all soldiers. 1 is an alternate layout that may have been intended for custom tank equipment. Larger values only crash the game due to missing files. Also see [[#113|[113]]] and [[#117|[117]]].
|- valign="top"
!47
!0x2F
|This is a direct copy of offset[48] from the [[MCD]] record of the tile the unit is standing on. A signed byte.
|- valign="top"
!48
!0x30
|Values for this byte always equal [[#52|[52]]] and are:
2 (3x3 square; legacy 5 pixels): Sectoid
3 (5x5 square, corners removed; legacy 7 pixels): Celatid, Chryssalid, Civvie,
Ethereal, Floater, Muton, Snake, '''Soldier'''
4 (7x7 octagon; legacy 9 pixels): Cyberdisc, Hovertank, Reaper, Sectopod, Tank
5 (9x9 square, Ls with 3-pixel legs removed; legacy 11 pixels): Silacoid
Based on copious research by [[User:Bomb_Bloke|Bomb_Bloke]], [[User:Seb76|Seb76]], [[user:Zombie|Zombie]], and others, this has been found to be a LOF Template look-up for the shape of targets; Loftemps 2 to 5 define the "3D" shape of units relative to Line Of Fire as a cylinder, where 2 (Sectoid) is a thin cylinder and 5 (Silacoid) is very wide. The pixel width of each "silhoutte" that [[LOFTEMPS.DAT]] corresponds to has been added to the list above (see LOFTemps images 2-5). Tiles are 16 pixels wide in the X or Y direction (that's what this byte is about), and 24 pixels high (compare [[#49|[49]]]).

This cylindrical shape is used in conjunction with height [[#49|[49]]] to define the silhouette that targets present to a shooter. Combine the pixel-width cross-section from Loftemps with height to find the cross-sectional area presented to shooters (sorted on increasing cross-section):

LOF LOF Cross Percent
Lookup Width Height Section of 384 Float 4x?
Type ''UR[48] Pixels UR[[#49|[49]]] Pxls X Ht (16x24) UR[[#51|[51]]]''
---- ------ ------ ------ --------- ------- ------ ---
Sectoid 2 5 16 80 20.8% - -
Celatid 3 7 12 84 21.9% 6 -
Soldier (Kneeling) 3 7 14 98 25.5% - -
Hovertank 4 9 12 108 28.1% 6 Yes
Silacoid 5 11 10 110 28.6% - -
Snakeman 3 7 18 126 32.8% - -
Zombie 3 7 18 126 32.8% - -
Ethereal 3 7 20 140 36.5% - -
Cyberdisc 4 9 15 135 35.2% 2 Yes
Chryssalid 3 7 21 147 38.3% - -
Civilian 3 7 21 147 38.3% 2 -
Floater 3 7 21 147 38.3% 2 -
Muton 3 7 21 147 38.3% - -
Tank 4 9 16 144 37.5% - Yes
Soldier 3 7 22 154 40.1% - -
Reaper 4 9 23 207 53.9% - Yes
Sectopod 4 9 23 207 53.9% - Yes
Units take up an amount of the whole tile (as seen in cross-section by a shooter) as shown in the "Percent of 384" column. In reality, though, the [[Firing Accuracy|accuracy]] of shots makes this a more complex topic than the percents suggest. Also, dividing by 384 is an oversimplification, since it implies a directly rectangular shot (shooting right down the X or Y axis). While it's useful to see, keep in mind that this column only shows relative numbers.

: [[User:Zaimoni|Zaimoni]]: actual cross section depends on shot facing. The table is close to correct for pure diagonal shots, so leaving alone for now.

The unit Float number ([[#51|[51]]], below) is shown simply for convenience. It does not enter into the cross-sectional computations. "4x" units actually consist of four units grouped in tight 2x2 formation (making their cross section effectively much larger then the percentage stated).

Note that causing an X-Com soldier to kneel causes their cross section to fall by 36.36~% of that of when they are standing.
|- valign="top"
!49
!0x31
|[[height|Standing height]].
|- valign="top"
!50
!0x32
|[[height|Kneeling height]].
|- valign="top"
!51
!0x33
|Floating [[height]]. A unit 'floats' this high above the ground, thus allowing shots to fly underneath. The heighest point of a unit can be found by adding this to the units height stat. Does this have an effect on explosive damage?
|- valign="top"
!52
!0x34
|Always the same as [[#48|[48]]] in all known saved games. XCOMmies are trying to test its significance, as seen at [[Talk:UNITREF.DAT#Offsets_0x30_.26_0x34|Talk:UNITREF.DAT#Offsets_0x30_&_0x34]] ([48] and [52]).
|- valign="top"
!53
!0x35
|Image index for item in left hand. 255 for none. Indexes into [[OBDATA.DAT]], not [[OBPOS.DAT]].
|- valign="top"
!54
!0x36
|Image index for item in right hand. 255 for none. Indexes into [[OBDATA.DAT]], not [[OBPOS.DAT]].
|- valign="top"
|colspan="3"|''NKF:'' If there is no item in the unit's hands, but one of the above two bytes are set, the 'image' that represents the item will still be displayed in the battlescape. If these phantom items are clicked on, the game crashes. If the image is not the right type for the real item in hand, the ammo count doesn't get displayed. Otherwise, it'll work as normal.
|- valign="top"
!55
!0x37
|[[Damage#Susceptible_to...|Damage Modifier]] Category

This field is simply a look-up table, or more directly, a way to categorize the units into similar groups. The actual modifiers are listed in the executable. A value of 1 indicates the first DM category, a value of 4 indicates the 4th, etc. The values of 2 and 3 are not seen in the alien stats as they refer to X-COM soldier armor info. I'm not sure about 13 as the Zombie's stats haven't been found yet, but I think there is a category in the DM's for it.

'''Value''' '''Unit Type(s)'''
'''0''' Terrain and Items
'''1''' Civilian, Sectoid, Celatid, Floater
'''2''' Personal Armor
'''3''' Power Suit, Flying Suit
'''4''' Tanks, Hovertanks
'''5''' Snakemen
'''6''' Ethereal
'''7''' Muton
'''8''' Silacoid
'''9''' Chryssalid
'''10''' Reaper
'''11''' Sectopod
'''12''' Cyberdisc
'''13''' Zombie
|- valign="top"
!56
!0x38
|[[Melee Accuracy]] ([[SOLDIER.DAT]] bytes 50 (initial) & 60 (increase) added together)
|- valign="top"
!57
!0x39
|[[Psionic Strength]]
|- valign="top"
!58
!0x3A
|Current [[Morale]]. Base morale is hardcoded to 100.
|- valign="top"
!59
!0x3B
|[[Bravery]] = 110 - (10 * ''this value'')
|- valign="top"
!60
!0x3C
|Panic mode. This takes effect at the start of the unit's next turn. Since it is cleared at that point, you'll never see it at anything other then 0 in the save files. You can manually change it to other values to force a specific panic attack on the next turn.
0: None
1: Freeze
2: Running
3: Berserk
|- valign="top"
!61
!0x3D
|[[#62|[62]]] will increment by this amount whenever the unit moves.
3: Sectiod ''- Hobbes''
4: Soldiers, civs, and all other aliens (but Hobbes had no Large aliens)
30: Tank/Laser
|- valign="top"
!62
!0x3E
|Visibility via motion scanner. The bigger it is, the bigger the blip. Test this one out for values.
|- valign="top"
!63
!0x3F
|Number of [[Fatal Wounds]] to head.
|- valign="top"
!64
!0x40
|Number of fatal wounds to torso.
|- valign="top"
!65
!0x41
|Number of fatal wounds to right arm.
|- valign="top"
!66
!0x42
|Number of fatal wounds to left arm.
|- valign="top"
!67
!0x43
|Number of fatal wounds to right leg.
|- valign="top"
!68
!0x44
|Number of fatal wounds to left leg.
|- valign="top"
!69-70
!0x45-0x46
|Indexes into [[ROUTES.DAT]]. To start with, aliens will be located at the same position as the node indicated by byte 69.
:For patrol AI (no X-COM units sighted in turn 1, either X-COM or alien):
::Byte 69 is the index of the node of the start of the planned move.
::Byte 70 is the index of the node of the end of the planned move.
:Note that the move may be multi-turn, and byte 69 is not guaranteed to update during a multi-turn move. I think it will if the alien ends its move on a node, however. -- Zaimoni
|- valign="top"
!71
!0x47
|''NKF:'' Always 16 for XCom units, 1 for cyberdisc, 0 for others? Perhaps involves mobile lighting - see the [[Talk:UNITREF.DAT#Offset_0x47|Talk]] page.
|- valign="top"
!72
!0x48
|The amount of [[Morale]] that has been restored using the [[Medi-Kit (EU)|Medkit's]] painkillers. The amount that ''can'' be restored is equal to the maximum health of the unit (index 26) minus their current health (index 13) further minus this.
|- valign="top"
!73
!0x49
|Intelligence. Rated from 2 - 8. Indicates for how many turns the alien will know the location of spotted soldiers. ''Hey - why do humans have zero intelligence? :(''
|- valign="top"
!74
!0x4A
|''NKF:'' Could be the unit spotted icon identifier? Could point to visible enemy units?

''MikeTheRed:'' XCOMs always have 0, but Mutons have values of 0-3 (usually 0 or 2, and often fluctuating) in a firing squad situation.

''Zaimoni:'' [http://www.strategycore.co.uk/forums/UFO-AI-patch-t8908.html&st=20&start=20|This] indicates AI mode: 0:PATROL, 1:SNIPER, 2:COMBAT, 3:ESCAPE

''Zaimoni:'' 255 i.e. -1 also possible. I tripped this by wounding a Floater in SNIPER mode; it returned fire, then was taken down by another soldier. Snap guess is that this is a "recalculate" marker.
|- valign="top"
!75
!0x4B
|Always 0?
|- valign="top"
!76-77
!0x4C-0x4D
|Mission count. Signed integer (low byte, high byte) also found in [[SOLDIER.DAT]] ''MTR: Wonder why they bothered to put this in Unitref since this will never change '''during''' a mission; compare how soldier stats are actually read from SOLDIER (not UNITREF) on return to geoscape. Is Missions shown anywhere on the combatscape?
|- valign="top"
!78-79
!0x4E-0x4F
|Kill count. Signed integer (low byte, high byte) also found in [[SOLDIER.DAT]]. Number of kills this unit has made for ALL missions, not just this one. This one '''can''' vary "unpredictably" and thus is the only byte known to directly carry forward into the geoscape / Soldier.Dat!
|- valign="top"
!80
!0x50
|[[Reactions]] experience counter, for number of reaction shots. It doesn't matter if they hit the target; reactions still count. See Note 2 re: Experience counters. (Also note: Aliens do not use experience counters.)

''NKF:'' Where does death by fire (overexposure rather than incendiary shell impact) fit into the experience counters? It becomes a non-assigned kill, I guess, like death by wounds, or death by a grenade that hasn't got an owner?
|- valign="top"
!81
!0x51
|[[Firing Accuracy]] experience counter, for number of hits on an enemy (lethal or not, grenades or bullets). Each Autoshot hit counts as 1, so you can get 3 hits from one Autoshot burst. Likewise, grenades and blaster bombs can hit multiple targets with one explosion. Also, if you miss the intended target but hit a different alien, it still counts. Finally, if your shot actually has zero [[Damage]], it does still count as a hit. (Not due to armor blockage; a pure roll of 0 coming out of the gun.)
|- valign="top"
!82
!0x52
|[[Melee Accuracy]] experience counter, for number of times stun rod has been used (not stun bombs).
|- valign="top"
!83
!0x53
|[[Throwing Accuracy]] experience counter, for number of times unit has thrown any object.
|- valign="top"
!84
!0x54
|<div id="Psi_Skill_Experience_Counter"></div>[[Psionic Skill]] experience counter, for number of psi attacks performed. 1 is added if attempt was unsuccessful, 3 if it was successful. Note: if this value goes over 255, all psi experience is lost. That's 85 successful psis (255/3). So be careful of marathon psi'ing (a minimum of 43 turns at 2 psis/turn, 29 turns at 3/turn).
|- valign="top"
!85
!0x55
|[[Bravery]] experience counter, for number of times unit has ''resisted'' panicking, despite Morale < 50. Being mind-controlled, panicking, or going berserk does ''not'' increase this stat -- although Panic Unit attacks will reduce Morale to the point where panic checks will be performed by the game.
|- valign="top"
!86-110
!0x56-0x6E
|Unit's Name. Standard string ended by null byte. The rest can hold garbage.
|- valign="top"
!111
!0x6F
|Set to 1 when the unit fires, then back to 0 afterwards - determines whether to render the gun and firing arm in the "pointing weapon" position, or whether the weapon is being held against the chest. If manually set to a value above 0, the unit will hold its weapon out until such time as it actually uses it.

Note that this value is only used by units holding two-handed weapons. A unit holding for eg a pistol will ''always'' point the weapon, and uses a different arm sprite for the purposes of doing so (regardless of whether or not the weapon is being fired).
|- valign="top"
!112
!0x70
|0; sometimes 1 for aliens.
|- valign="top"
!113
!0x71
|If 1, then you can't use the inventory button and the unit will be immune to stun. Used for tanks. Mind controlled units don't use this but their button disables anyway.

''BombBloke:'' This is the only way to access tank inventories.
*Tank/Cannon has a normal inventory and uses man_1m0.spk.
*Tank/Rocket Launcher has a different layout and uses man_1m0.spk.
*Tank/Laser Cannon uses man_œ.spk, which doesn't exist normally. Providing this file still crashes.
*Hovertank/Plasma simply crashes.
*Hovertank/Launcher simply crashes.

[[#1|[1]]] actually determines the inventory screen used, might be worth playing with that. [[#46|[46]]] determines the layout.
|- valign="top"
!114
!0x72
|If not 0, then unit is on fire, and will burn for this amount of turns.
|- valign="top"
!115
!0x73
|Gender: 0 = male, 1 = female.
|- valign="top"
!116
!0x74
|Hair/skin colour (for inventory; all other units = 0):
0: Blond caucasian
1: Brunette caucasian
2: Asian
3: Black
|- valign="top"
!117
!0x75
|Turret weapon. Over-rides hand held weapon. Turret images are not centered; that would be impossible because they aren't all 'objects' (e.g. Celatid). ''(Mix of notes by BB and NKF)''
F.A. TUs F.A. TUs
0: HWP cannon (bigobs[40])....................Aimed 90% 80% Snap 60% 33%
1: HWP rocket (bigobs[42])....................Aimed 115% 75% Snap 55% 45%
2: HWP laser (bigobs[54]).....................Aimed 85% 75% Snap 50% 33%
3: HWP plasma cannon (bigobs[43]).............Aimed 100% 60% Snap 86% 30%
4: HWP blaster (bigobs[43]) (looks like ordinary cannon?)......Aimed 120% 80%
5: Celatid plasma cannon (bigobs[38]).........Aimed 110% 60% Snap 75% 30%
6: Cyberdisc plasma cannon (bigobs[34]).......Aimed 110% 60% Snap 75% 30%
7: Sectopod Laser* cannon (bigobs[34])as cyberdisk, above, plus Auto 50% 35%
22: Invalid - Incredibly powerful armour piercing shell. Overpowering.
255: Unused
Note: This item will take precendence over any item carried in the hand slots. It can be installed on non-tanks, but then the unit won't be able to use any carried weapons or items. This weapon is NOT affected by the kneeling modifier, but it is affected by the current unit's accuracy stat. Also note, this byte does NOT determine the turret image for HWPs in the battlescape.

[*]The damage type for the Sectopod is indeed set to (3)laser in the executable! Graphical/sound effects of a turret weapon is set there as well, via a reference to a weapon in OBDATA.DAT (HWP Cannon=4=Heavy Cannon, Sectopod=34=Heavy Plasma) ''When I changed HWP Cannon to 2, it looked/sounded like rifle fire - Crus8r''

Also see [[#46|[46]]], [[#113|[113]]], and [[#118|[118]]].
|- valign="top"
!118
!0x76
|Ammo for [[#117|[117]]] turret weapon
|- valign="top"
!119
!0x77
|Movement related? Large unit related? Possible bitfield.
''MTR:''
00000000 0 Chryssalid(2), Civilian(9), Ethereal(2), Floater(2), Muton,
00000001 1 Muton, PA Soldier(2) Sectoid(2), Silacoid(2),
00000011 3 PA Soldier PA Soldier(2), Tank/Laser
00000101 5 Snakeman
00001010 10 Celatid ''- Hobbes game - could have some garbage''
00001101 13 Muton, PA Soldier '' (parens) is count, if more than 1 unit''
00010011 19 Snakeman
00100110 38 PA Soldier
00101010 42 Muton(3)
00110001 49 Muton
00110010 50 PA Soldier
00110101 53 Silacoid(2)
00111011 59 Celatid
00111111 63 Silacoid
01001110 78 PA Soldier
01100111 103 PA Soldier
01111111 127 Muton
10010000 144 Muton
11000000 192 Celatid
11111110 254 Muton
|- valign="top"
!120
!0x78
|Unit bit flags, mainly re: mobility. They do NOT affect the soldier in inventory screen: ''(Mix of notes by BB and NKF)''
( 1) 1: 1 = Dead. ''This was only set for 2 of 3 dead aliens in my current game.''
''[[#13|[13]]] (Health=0) is the most reliable indicator for me.''
''-[[User:MikeTheRed|MikeTheRed]]''
( 2) 2: 1 = Unit can fly.
( 4) 3: 1 = Unit is flying. (Toggles leg sprites for power armour.)
( 8) 4: ??? Seems to flag if the unit has been selected this turn.
( 16) 5: 1 = Unit has been disabled for selection.
(Stops the unit tab button from selecting this soldier.)
( 32) 6: 0 = Unit has left hand object selected, 1 = right hand object selected.
( 64) 7: 1 = Unit is kneeling.
(128) 8: 1 = Unit is wearing power/flying suit. (Can't be stunned by smoke flag?
Seems to work for fire, too.)
If a unit is carrying something in either hand, it is impossible to get him to appear as if he is carrying nothing - in the game, at least. If he is carrying nothing, bit 6 can flag (as though the unit was using it's right hand item). But maybe it's just the order of dropped items affecting this?

Note: A unit is only considered as flying if it is not on the ground. For example, a hover tank is not always considered as flying.

What if a hovertank is half on the ground, half in the air? What about a treaded tank, or large alien unit? What about units in lifts?
|- valign="top"
!121
!0x79
|Possible Values: 0 or 16. All units in unitref.dat get a value of 0 except for the second unit in the list which gets 16. Doesn't matter if the second unit is a soldier, a tank, or an alien. It's always 16. Editing it to 0 doesn't crash the game or have any dire consequences.
|- valign="top"
!122
!0x7A
|Always 0?
|- valign="top"
!123
!0x7B
|Always 0?
|- valign="top"
!124
!0x7C
|TFTD ONLY - Appears to be a count as to which frame of bubbles the soldier is on. Can be 0 to 16 (0x0F), most likely 125/7D is included with this.
|- valign="top"
!125
!0x7D
|TFTD ONLY, unknown.
|- valign="top"
!126
!0x7E
|TFTD ONLY, unknown.
|- valign="top"
!127
!0x7F
|TFTD ONLY, unknown.
|- valign="top"
!128
!0x80
|TFTD ONLY, unknown.
|- valign="top"
!129
!0x81
|TFTD ONLY, unknown.
|- valign="top"
!130
!0x82
|TFTD ONLY, unknown.
|- valign="top"
!131
!0x83
|TFTD ONLY, unknown.
|-
|}

== Notes ==
1) The original/base values for soldier stats (offsets [[#23|[23]]]-[[#28|[28]]], etc.) correspond to the initial+increase bytes from [[SOLDIER.DAT|Soldier.Dat]] (bytes 43-62). Changes to these Unitref bytes are lost when the mission ends; instead, XCOM re-reads them from Soldier at that time. This makes sense because base soldier stats don't change during a mission per se (although they might increase when the mission ends); in this way, the programmers didn't have to bother with separately storing and/or adding initial+increase during combat. (It's also why you don't see the initial+increase in the soldier stat display during combat, that you can see back at base.) On a practical note, if you are testing soldier stat increases versus experience counters, change the experience counters in Unitref, but change the soldier stats in Soldier. (IOW, it doesn't matter what the soldier stats are in the combat mission.)

The Kill count (offset [[#78-79|[78-79]]]) is the only Unitref value I know of that is directly carried forward into the geoscape and Soldier.dat. However, some others do indirectly carry forward, for example: experience (offsets [[#80|[80]]]-[[#85|[85]]]) causes stat and rank increases, and decreased health (offset [[#26|[26]]] - offset [[#13|[13]]]) means hospital time. And, of course, death is permanent. Heh.

2) Experience counters (offsets [[#80|[80]]]-[[#85|[85]]]) determine the likelihood of soldier stat increases at the end of the combat mission, according to the formula for Primary Stats shown [[Experience#How_Experience_Points_Are_Applied|here]]. The Bravery counter (offset [[#85|[85]]]) affects Bravery as shown [[Bravery|here]].

Also, if at least one of the experience counters (except Throws) has a count, your secondary stats will increase, as discussed [[Experience#Secondary_Stats|here]]. All you need is at least a 1 in offsets [[#80|[80]]]-[[#82|[82]]] or [[#84|[84]]]-[[#85|[85]]]; more than 1 and/or multiple counters has no additional effect.

3) BombBloke's additional "To be Done" notes - can we cross some of these off yet?

Need to research:
Stun recovery rate, does it exist?
Hand to hand attacks
<strike>Offset of weapon from unit image?</strike>
''Based on unit height and nothing else. There may be values to determine what arm sprites to use,''
''but I doubt it.''
Firing sprite offset?
''Probably just based on unit height and some hardcoded values in the executable.''
<strike>Inventory lockout?</strike> ''All mind controlled units are locked out.''
Kneel lockout?
''Probably the same as above, I seem to remember that using XcomUtil to "swap sides" would make it''
''possible to kneel small alien units.''
<strike>Aliens seen?</strike> ''Not used in unitref.dat, only in unitpos.dat. -[[User:Zombie|Zombie]] 23:48, 29 September 2006 (PDT)''
<strike>Whether a unit slides/floats/hovers/rolls/walks (movement noise)?</strike> ''Set according to unit type.''
What else? The more to look for, the easier it is...

Know 111 values.
Unknown values (13 in total):
[[#34|[034 / 0x22]]] - Always 0?
[[#36|[036 / 0x24]]] - Always 0?
[[#43|[043 / 0x2B]]] - Set to 1 on occasion, usually 0.
[[#52|[052 / 0x34]]] - Seems to be a mirror of 48 / 0x30, the LOFTemp index for the unit.
[[#71|[071 / 0x47]]] - Appears to relate to lighting caused by the unit, [[Talk:UNITREF.DAT#Offset_0x47|discussion here]].
[[#74|[074 / 0x4A]]] - Appears to relate to the AI-mode used by the unit, [[Talk:UNITREF.DAT#Offset_0x4A_.2874.29|discussion here]].
[[#75|[075 / 0x4B]]] - Always 0?
[[#112|[112 / 0x70]]] - Set to 1 for some aliens, 0 otherwise.
[[#119|[119 / 0x77]]] - No idea, possible bitfield, could be anything.
[[#120|[120 / 0x78]]] - Unit bit flags, mainly re: mobility. Only one bit not 100% identified.
[[#121|[121 / 0x79]]] - Second unit gets a value of 16. Everyone else gets 0. No obvious purpose.
[[#122|[122 / 0x7A]]] - Always 0?
[[#123|[123 / 0x7B]]] - Always 0?

Know 1 TFTD value.
Unknown TFTD values (7 in total):
[[#125|[125]]] [[#126|[126]]] [[#127|[127]]] [[#128|[128]]] [[#129|[129]]] [[#130|[130]]] [[#131|[131]]]

4) Hobbes posted a savegame with a TON of different aliens in it [http://www.xcomufo.com/forums/index.php?showtopic=8591 here] (message 6). Interesting for testing. But note it was made with XCOMUTIL and there may(?) be concerns over vailidity of unit info - see [[Talk:UNITREF.DAT]].

5) A [[HackerTools|Hex Workshop]] Structure Library for UNITREF.DAT created by Danial is [[UNITREF_DAT_HSL|here]].

== For More Information ==
*[[SOLDIER.DAT]]
*[[Soldiers|Soldier Stats]]
*[[Experience]]
*[[HackerTools|Hex editing]]

Return to [[Saved_Game_Files|Saved Game Files]]
[[Category:Game Files]]

UNITREF.DAT

2012-03-04T06:45:56Z

Zaimoni:

A [[Saved Game Files|save game file]] that has a record size of 124 bytes for UFO, or 132 for TFTD. Values are unsigned unless otherwise stated. Some bytes represent bitfields. There are 80 records (not all of them necessarily used) for a fixed file size of 9,920 bytes (or 10,560 for TFTD). It goes hand in hand with [[UNITPOS.DAT]].

Comes in three flavours: 

*UNIREF.DAT 
Initially created by the GeoScape engine before tactical battles. Stored in the [[Saved_Game_Files#Missdat_Files|MISSDAT]] folder and contains info on all units that will be present in the coming mission (in an alive state - the deaths of aliens killed by exploding UFO power units isn't determined until [[Battlescape_Map_Generation#KABOOM.21.21|later]]). Unlike the other two versions, this only contains the bare minimum number of records required to store the units it details. 

*UNITREF.DAT 
Created along with a [[Saved_Game_Files#Battlescape_Files|battlescape save]], contains the mid-mission state of the unit table. 

*UNIREF2.DAT 
Appears in the [[Saved_Game_Files#Missdat_Files|MISSDAT]] folder at the end of combat. Used to determine which troopers/tanks survived, statistic gains via [[experience]], and which aliens need to be hauled off to the [[Alien Containment]] unit. 

Values are presented according to byte offset ([[#0|0]] to [[#123|123]] (or [[#131|131]] for TFTD)) followed by the equivalent hex offset ([[#0x00|0x00]] to [[#0x7B|0x7B]] (or [[#0x83|0x83]] for TFTD)). Notes apply to both UFO and TFTD unless otherwise stated. Let us know what else you can find - refer to the [[#Notes|bottom of the page]] for those values that're unknown, or to the [[Talk:UNITREF.DAT|talk page]] for further ideas as to what they could be.

== Structure ==

{| class="wikitable"
|-
!Offset (Decimal)
!Offset (Hex)
!Usage
|- valign="top"
!0
!0x00
|Type of unit. Unit scream and movement sound effects are based on this and gender. Gender and flying abilities affect the sprites as well. Not turrets. Specifically: [[#53|[53]]] & [[#54|[54]]] (weapons in hands), [[#115|[115]]] (gender) and [[#120|[120]]] (other flags) affect the final screen image. If the unit is a large unit, this will also determine the appearance of the last three quarters of the unit. This does NOT affect: the flying ability of the unit, the soldier image in the inventory screen, or the special abilities for certain aliens.
UFO TFTD
0: Male/female unarmored X-COM soldier 0: Male/female unarmored X-COM diver
1: Male/female personal armor soldier 1: Male/female plastic armor diver
2: Power/flying suit soldier 2: Power/flying suit diver
3: Tank 3: Tank
4: Sectoid 4: Aquatoid
5: Snakeman 5: Gillman
6: Ethereal 6: Lobster Man
7: Muton 7: Tasoth
8: Floater 8: Calcinite
9: Celatid 9: Deep One
10: Silacoid 10: BioDrone
11: Chryssalid 11: Tentaculat
12: Reaper 12: Triscene
13: Sectopod 13: Hallucinoid
14: Cyberdisc 14: Xarquid
15: Male civilian 15: Male civilians
16: Female civilian 16: Female civilians
17: Zombie 17: Zombie
255: Unused 255: Unused

<blockquote>If the corresponding [[UNITPOS.DAT]] record is unused, then the record is unused.</blockquote>
|- valign="top"
!1
!0x01
|Inventory paper doll image. File "UFOGRAPH\MAN_"+(char)(value + 48)+".SPK" will be used as the inventory sprite, unless the value is 0 or 1. In those cases, [[#115|[115]]] and [[#116|[116]]] are used to determine the picture.
0: No armor.
1: Personal armour.
2: Power suit.
3: Flying suit.
|- valign="top"
!2-5
!0x02-0x05
|Four byte value pointing to RAM location of the [[Image_Formats#PCK|PCK set]] used by the unit. Re-determined when the save game is loaded.
|- valign="top"
!6-9
!0x06-0x09
|Four byte value pointing to RAM location of the [[Image_Formats#PCK|TAB index for the PCK data]] used by the unit. Re-determined when the save game is loaded.
|- valign="top"
!10
!0x0A
|Unit facing. Does NOT control HWP turret direction; see [[#24|[24]]].
0: North (up right)
1: Northeast (right)
2: East (down right)
3: Southeast (down)
4: South (down left)
5: Southwest (left)
6: West (up left)
7: Northwest (up)
|- valign="top"
!11
!0x0B
|Movement type. When entering a given map location, each tile is checked to see the TU requirements accordingly. [[MCD]][39+[[#11|UnitRef[11]]]] is the offset used. Note: By default, this is 0 for ALL unit types.
0: Walking
1: Sliding
2: Flying
|- valign="top"
!12
!0x0C
|Current TUs.
|- valign="top"
!13
!0x0D
|Current Health. Health of 0 = Dead. Compare [[#42|[42]]], [[#120|[120]]].

''For my [[Talk:Bravery|Bravery experience point testing]], I killed 15 of 16 aliens by setting this to zero, and my soldiers to 0 Morale. When I loaded the savegame, the aliens were still "alive" (i.e., up), then all died when I ended this turn. So death is probably only checked when injury happens, and at end of turn... to truly kill them dead on the ground through savegame editing must take more. And arg - when they all died, my soldiers all went to 100 Morale! So I edited them back to 0 Morale. But guess what... then all the aliens died '''again''' at the end of '''next''' turn, even though they were all on the ground (I heard screams, and all soldiers' Morale went to 100 again). What the heck? The aliens stayed down after that, though. --[[User:MikeTheRed|MikeTheRed]] 16:01, 3 November 2006 (PST)''

''Update: [[UNITPOS.DAT]] offset 10 bit 2 should be used to kill a unit entirely dead. Thanks, NKF & BB - MTR''

: ''While the game kills characters when Health<=Fatal Wounds (__ dies message), XComUtil will recover them based if their health is greater than 0. Haven't tested an unmodified game. --[[User:Zaimoni|Zaimoni]] 11:52, 14 April 2007 (CDT)''
|- valign="top"
!14
!0x0E
|Current Stun level ''how much falloff of paralysis every turn? What determines it?''
|- valign="top"
!15
!0x0F
|Current Energy
|- valign="top"
!16
!0x10
|Current Reactions ''NKF: affected by health percentage''
|- valign="top"
!17
!0x11
|Strength
|- valign="top"
!18
!0x12
|Current Front Armour
|- valign="top"
!19
!0x13
|Current Left Armour
|- valign="top"
!20
!0x14
|Current Right Armour
|- valign="top"
!21
!0x15
|Current Rear Armour
|- valign="top"
!22
!0x16
|Current Under Armour
|- valign="top"
|colspan="3"|"Base" means the original (total) value (as carried forward from geoscape) - Also see Note 1 re: Base soldier stat values.
|- valign="top"
!23
!0x17
|Base Firing accuracy. Current value = this * [[#13|[13]]]/[[#26|[26]]] (percent health)
|- valign="top"
!24
!0x18
|Base Throwing accuracy. Current value = this * [[#13|[13]]]/[[#26|[26]]] (percent health)

Note: Tanks (turreted units?) always have 0 throwing accuracy. They use this for turret facing, relative to unit facing. 0 means it's facing forwards. Additional values are clockwise increments; see [[#10|[10]]].
|- valign="top"
!25
!0x19
|Base TUs
|- valign="top"
!26
!0x1A
|Base Health
|- valign="top"
!27
!0x1B
|Base Energy
|- valign="top"
!28
!0x1C
|Base Reactions
|- valign="top"
|colspan="3"|''These Base Armour values are used to show the starting armor value in the Attributes screen (so you can readily see if it's been damaged''
|- valign="top"
!29
!0x1D
|Base Front Armour
|- valign="top"
!30
!0x1E
|Base Left Armour
|- valign="top"
!31
!0x1F
|Base Right Armour
|- valign="top"
!32
!0x20
|Base Rear Armour
|- valign="top"
!33
!0x21
|Base Under Armour
|- valign="top"
!34
!0x22
|Always 0? [Unused]
|- valign="top"
!35
!0x23
|Energy to recharge each turn. Equals '''recruit initial''' TUs/3 ([[SOLDIER.DAT]][43], '''not''' total base TUs). This is a signed byte. See [[Time Units]] and [[Energy#Usage|Energy Usage]]; also see [[#45|[45]]] (energy usage when walking/turning). ''BombBloke: Is this affected by damage?''
|- valign="top"
!36
!0x24
|Always 0? [Unused]
|- valign="top"
!37
!0x25
|Psi skill. Psi stats not displayed/usable until this is greater then 0.
|- valign="top"
!38
!0x26
|Item to create when unit is unconscious/dead (index into obdata.dat).

NKF: If you set this value to that of a usable item, the item that is created in place of the unconscious or dead soldier can be used like the ordinary item. Elerium pods, for example, can be recovered for 50 elerium each after the battle. Weapons can be used as you normally use them, etc.

For unconscious 'units', the item will be treated as the unconscious body - it will retain the name of the unconscious unit when looked at via the inventory screen. Picking up and using the 'item' will work, but when the unit wakes up, the 'item' image in the soldier's hands is not cleared, even though the item no longer 'exists' in the soldier's hands. Using this 'item' will just crash the battlescape.

Actually, I do not even want to think about what would happen if you 'prime' a grenade/stunned body.
|- valign="top"
!39
!0x27
|"Soldier value" a.k.a. victory points. You gain (or lose, as the case may be) score at the end of combat according to this value when the unit dies.
*For X-COM units: A soldier with 42 will be worth -42 points if killed. Note this doesn't seem to apply if the soldier is killed when unconscious. The soldier just vanishes.
*For aliens: A commander with 35 will give you +35 points if killed.
*This value is the same as [[SOLDIER.DAT]] bytes 15-16 (a Word) and equals:
20 + Missions + Rank Bonus

with [[Rank]] Bonus as follows: SGT +1, CPT +3, COL +6, CDR +10
Note that although this equation holds true, the value is not actually computed per se. Instead, 1 is added directly to it each mission, as is a rank-bonus delta if you advance (e.g. COL to CDR, delta +4). In other words, hacking the Missions or Rank fields does not affect this value.
|- valign="top"
!40
!0x28
|Index into [[SOLDIER.DAT]], so game knows what to update. 255 = does not belong to anyone (i.e., it's not a soldier). ''NKF: This byte is critical for player controlled units. If this doesn't refer to anything, the unit ceases to exist at the end of the game. If it points to a valid soldier entry in soldier.dat, the soldier.dat entry will be updated.''
|- valign="top"
!41
!0x29
|Animation frame counter for the unit. Used by eg [[Celatid]]s and [[Silacoid]]s.
|- valign="top"
!42
!0x2A
|Rank. Affects morale loss and interface icon (hull for tanks). Only X-COM troopers display rank icons.
X-COM
0: Rookie ''Civvies are 0 too''
1: Squaddie
2: Sergeant
3: Captain
4: Colonel
5: Commander
255: Dead/unused

Aliens
1: Commander
2: Leader
3: Engineer
4: Medic
5: Navigator
6: Soldier
7: Terrorist
255: Dead/unused

Hull shape for X-COM tanks:
0: Treaded
1: Hover
''I don't see 255 set for three dead mutons in a current game... [[#13|[13]]] (Health=0) seems to be the only reliable death indicator for them. Compare [[#120|[120]]]. -[[User:MikeTheRed|MikeTheRed]]''
|- valign="top"
!43
!0x2B
|0 or 1? In Hobbes' savegame, civvies and sectoids are 1. All others are 0 (soldiers, aliens, terrorists, tank).

''MTR: If the next byte is "aggression", and civvies and sectoids have a 1 here, could this be "cowardliness"? Likelihood to panic; to do something dumb/random? We've all seen civvies running around in a mad / random panic.''
|- valign="top"
!44
!0x2C
|Alien aggression. The higher it is, the less likely an alien will take cover. Maximum of 2. ''MTR: This is true for aliens in Hobbes game, but soldiers have values from 4 to 254. Garbage? Delete this comment if so.''
|- valign="top"
!45
!0x2D
|Used to calculate energy loss when walking or turning as: INT( TUs / 2[45] ). See [[Energy#Usage]]; compare [[#35|[35]]] (energy recharge per turn). Set this byte to 4 to ensure no energy use whatsoever (maximum map [[Time Units#Time_Unit_Walking_Usage_Tables|tile TU cost]] is 12). ''In Hobbes game, many aliens are 0 and all soldiers are 1, but a dozen aliens have higher values ranging all the way up to 112! Garbage and/or the game doesn't care if they are garbage?''
|- valign="top"
!46
!0x2E
|HWP turret image. Only used (and only appears) if unit type [[#0|[0]]]=3 (X-COM tanks):
0: Cannon
1: Rocket
2: Laser
3: Plasma
4: Blaster
5,6: ? Blanks
'''Note:''' For non-tanks, this controls the inventory layout. ''Only'' 0 and 1 are valid. 0 is the standard layout seen on all soldiers. 1 is an alternate layout that may have been intended for custom tank equipment. Larger values only crash the game due to missing files. Also see [[#113|[113]]] and [[#117|[117]]].
|- valign="top"
!47
!0x2F
|This is a direct copy of offset[48] from the [[MCD]] record of the tile the unit is standing on. A signed byte.
|- valign="top"
!48
!0x30
|Values for this byte always equal [[#52|[52]]] and are:
2 (3x3 square; legacy 5 pixels): Sectoid
3 (5x5 square, corners removed; legacy 7 pixels): Celatid, Chryssalid, Civvie,
Ethereal, Floater, Muton, Snake, '''Soldier'''
4 (7x7 octagon; legacy 9 pixels): Cyberdisc, Hovertank, Reaper, Sectopod, Tank
5 (9x9 square, Ls with 3-pixel legs removed; legacy 11 pixels): Silacoid
Based on copious research by [[User:Bomb_Bloke|Bomb_Bloke]], [[User:Seb76|Seb76]], [[user:Zombie|Zombie]], and others, this has been found to be a LOF Template look-up for the shape of targets; Loftemps 2 to 5 define the "3D" shape of units relative to Line Of Fire as a cylinder, where 2 (Sectoid) is a thin cylinder and 5 (Silacoid) is very wide. The pixel width of each "silhoutte" that [[LOFTEMPS.DAT]] corresponds to has been added to the list above (see LOFTemps images 2-5). Tiles are 16 pixels wide in the X or Y direction (that's what this byte is about), and 24 pixels high (compare [[#49|[49]]]).

This cylindrical shape is used in conjunction with height [[#49|[49]]] to define the silhouette that targets present to a shooter. Combine the pixel-width cross-section from Loftemps with height to find the cross-sectional area presented to shooters (sorted on increasing cross-section):

LOF LOF Cross Percent
Lookup Width Height Section of 384 Float 4x?
Type ''UR[48] Pixels UR[[#49|[49]]] Pxls X Ht (16x24) UR[[#51|[51]]]''
---- ------ ------ ------ --------- ------- ------ ---
Sectoid 2 5 16 80 20.8% - -
Celatid 3 7 12 84 21.9% 6 -
Soldier (Kneeling) 3 7 14 98 25.5% - -
Hovertank 4 9 12 108 28.1% 6 Yes
Silacoid 5 11 10 110 28.6% - -
Snakeman 3 7 18 126 32.8% - -
Zombie 3 7 18 126 32.8% - -
Ethereal 3 7 20 140 36.5% - -
Cyberdisc 4 9 15 135 35.2% 2 Yes
Chryssalid 3 7 21 147 38.3% - -
Civilian 3 7 21 147 38.3% 2 -
Floater 3 7 21 147 38.3% 2 -
Muton 3 7 21 147 38.3% - -
Tank 4 9 16 144 37.5% - Yes
Soldier 3 7 22 154 40.1% - -
Reaper 4 9 23 207 53.9% - Yes
Sectopod 4 9 23 207 53.9% - Yes
Units take up an amount of the whole tile (as seen in cross-section by a shooter) as shown in the "Percent of 384" column. In reality, though, the [[Firing Accuracy|accuracy]] of shots makes this a more complex topic than the percents suggest. Also, dividing by 384 is an oversimplification, since it implies a directly rectangular shot (shooting right down the X or Y axis). While it's useful to see, keep in mind that this column only shows relative numbers.

: [[User:Zaimoni|Zaimoni]]: actual cross section depends on shot facing. The table is close to correct for pure diagonal shots, so leaving alone for now.

The unit Float number ([[#51|[51]]], below) is shown simply for convenience. It does not enter into the cross-sectional computations. "4x" units actually consist of four units grouped in tight 2x2 formation (making their cross section effectively much larger then the percentage stated).

Note that causing an X-Com soldier to kneel causes their cross section to fall by 36.36~% of that of when they are standing.
|- valign="top"
!49
!0x31
|[[height|Standing height]].
|- valign="top"
!50
!0x32
|[[height|Kneeling height]].
|- valign="top"
!51
!0x33
|Floating [[height]]. A unit 'floats' this high above the ground, thus allowing shots to fly underneath. The heighest point of a unit can be found by adding this to the units height stat. Does this have an effect on explosive damage?
|- valign="top"
!52
!0x34
|Always the same as [[#48|[48]]] in all known saved games. XCOMmies are trying to test its significance, as seen at [[Talk:UNITREF.DAT#Offsets_0x30_.26_0x34|Talk:UNITREF.DAT#Offsets_0x30_&_0x34]] ([48] and [52]).
|- valign="top"
!53
!0x35
|Image index for item in left hand. 255 for none. Indexes into [[OBDATA.DAT]], not [[OBPOS.DAT]].
|- valign="top"
!54
!0x36
|Image index for item in right hand. 255 for none. Indexes into [[OBDATA.DAT]], not [[OBPOS.DAT]].
|- valign="top"
|colspan="3"|''NKF:'' If there is no item in the unit's hands, but one of the above two bytes are set, the 'image' that represents the item will still be displayed in the battlescape. If these phantom items are clicked on, the game crashes. If the image is not the right type for the real item in hand, the ammo count doesn't get displayed. Otherwise, it'll work as normal.
|- valign="top"
!55
!0x37
|[[Damage#Susceptible_to...|Damage Modifier]] Category

This field is simply a look-up table, or more directly, a way to categorize the units into similar groups. The actual modifiers are listed in the executable. A value of 1 indicates the first DM category, a value of 4 indicates the 4th, etc. The values of 2 and 3 are not seen in the alien stats as they refer to X-COM soldier armor info. I'm not sure about 13 as the Zombie's stats haven't been found yet, but I think there is a category in the DM's for it.

'''Value''' '''Unit Type(s)'''
'''0''' Terrain and Items
'''1''' Civilian, Sectoid, Celatid, Floater
'''2''' Personal Armor
'''3''' Power Suit, Flying Suit
'''4''' Tanks, Hovertanks
'''5''' Snakemen
'''6''' Ethereal
'''7''' Muton
'''8''' Silacoid
'''9''' Chryssalid
'''10''' Reaper
'''11''' Sectopod
'''12''' Cyberdisc
'''13''' Zombie
|- valign="top"
!56
!0x38
|[[Melee Accuracy]] ([[SOLDIER.DAT]] bytes 50 (initial) & 60 (increase) added together)
|- valign="top"
!57
!0x39
|[[Psionic Strength]]
|- valign="top"
!58
!0x3A
|Current [[Morale]]. Base morale is hardcoded to 100.
|- valign="top"
!59
!0x3B
|[[Bravery]] = 110 - (10 * ''this value'')
|- valign="top"
!60
!0x3C
|Panic mode. This takes effect at the start of the unit's next turn. Since it is cleared at that point, you'll never see it at anything other then 0 in the save files. You can manually change it to other values to force a specific panic attack on the next turn.
0: None
1: Freeze
2: Running
3: Berserk
|- valign="top"
!61
!0x3D
|[[#62|[62]]] will increment by this amount whenever the unit moves.
3: Sectiod ''- Hobbes''
4: Soldiers, civs, and all other aliens (but Hobbes had no Large aliens)
30: Tank/Laser
|- valign="top"
!62
!0x3E
|Visibility via motion scanner. The bigger it is, the bigger the blip. Test this one out for values.
|- valign="top"
!63
!0x3F
|Number of [[Fatal Wounds]] to head.
|- valign="top"
!64
!0x40
|Number of fatal wounds to torso.
|- valign="top"
!65
!0x41
|Number of fatal wounds to right arm.
|- valign="top"
!66
!0x42
|Number of fatal wounds to left arm.
|- valign="top"
!67
!0x43
|Number of fatal wounds to right leg.
|- valign="top"
!68
!0x44
|Number of fatal wounds to left leg.
|- valign="top"
!69-70
!0x45-0x46
|Indexes into [[ROUTES.DAT]]. To start with, aliens will be located at the same position as the node indicated by byte 69.
:For patrol AI (no X-COM units sighted in turn 1, either X-COM or alien):
::Byte 69 is the index of the node of the start of the planned move.
::Byte 70 is the index of the node of the end of the planned move.
:Note that the move may be multi-turn, and byte 69 is not guaranteed to update during a multi-turn move. I think it will if the alien ends its move on a node, however. -- Zaimoni
|- valign="top"
!71
!0x47
|''NKF:'' Always 16 for XCom units, 1 for cyberdisc, 0 for others? Perhaps involves mobile lighting - see the [[Talk:UNITREF.DAT#Offset_0x47|Talk]] page.
|- valign="top"
!72
!0x48
|The amount of [[Morale]] that has been restored using the [[Medi-Kit (EU)|Medkit's]] painkillers. The amount that ''can'' be restored is equal to the maximum health of the unit (index 26) minus their current health (index 13) further minus this.
|- valign="top"
!73
!0x49
|Intelligence. Rated from 2 - 8. Indicates for how many turns the alien will know the location of spotted soldiers. ''Hey - why do humans have zero intelligence? :(''
|- valign="top"
!74
!0x4A
|''NKF:'' Could be the unit spotted icon identifier? Could point to visible enemy units?

''MikeTheRed:'' XCOMs always have 0, but Mutons have values of 0-3 (usually 0 or 2, and often fluctuating) in a firing squad situation.

''Zaimoni:'' [http://www.strategycore.co.uk/forums/UFO-AI-patch-t8908.html&st=20&start=20|This] indicates AI mode: 0:PATROL, 1:SNIPER, 2:COMBAT, 3:ESCAPE
|- valign="top"
!75
!0x4B
|Always 0?
|- valign="top"
!76-77
!0x4C-0x4D
|Mission count. Signed integer (low byte, high byte) also found in [[SOLDIER.DAT]] ''MTR: Wonder why they bothered to put this in Unitref since this will never change '''during''' a mission; compare how soldier stats are actually read from SOLDIER (not UNITREF) on return to geoscape. Is Missions shown anywhere on the combatscape?
|- valign="top"
!78-79
!0x4E-0x4F
|Kill count. Signed integer (low byte, high byte) also found in [[SOLDIER.DAT]]. Number of kills this unit has made for ALL missions, not just this one. This one '''can''' vary "unpredictably" and thus is the only byte known to directly carry forward into the geoscape / Soldier.Dat!
|- valign="top"
!80
!0x50
|[[Reactions]] experience counter, for number of reaction shots. It doesn't matter if they hit the target; reactions still count. See Note 2 re: Experience counters. (Also note: Aliens do not use experience counters.)

''NKF:'' Where does death by fire (overexposure rather than incendiary shell impact) fit into the experience counters? It becomes a non-assigned kill, I guess, like death by wounds, or death by a grenade that hasn't got an owner?
|- valign="top"
!81
!0x51
|[[Firing Accuracy]] experience counter, for number of hits on an enemy (lethal or not, grenades or bullets). Each Autoshot hit counts as 1, so you can get 3 hits from one Autoshot burst. Likewise, grenades and blaster bombs can hit multiple targets with one explosion. Also, if you miss the intended target but hit a different alien, it still counts. Finally, if your shot actually has zero [[Damage]], it does still count as a hit. (Not due to armor blockage; a pure roll of 0 coming out of the gun.)
|- valign="top"
!82
!0x52
|[[Melee Accuracy]] experience counter, for number of times stun rod has been used (not stun bombs).
|- valign="top"
!83
!0x53
|[[Throwing Accuracy]] experience counter, for number of times unit has thrown any object.
|- valign="top"
!84
!0x54
|<div id="Psi_Skill_Experience_Counter"></div>[[Psionic Skill]] experience counter, for number of psi attacks performed. 1 is added if attempt was unsuccessful, 3 if it was successful. Note: if this value goes over 255, all psi experience is lost. That's 85 successful psis (255/3). So be careful of marathon psi'ing (a minimum of 43 turns at 2 psis/turn, 29 turns at 3/turn).
|- valign="top"
!85
!0x55
|[[Bravery]] experience counter, for number of times unit has ''resisted'' panicking, despite Morale < 50. Being mind-controlled, panicking, or going berserk does ''not'' increase this stat -- although Panic Unit attacks will reduce Morale to the point where panic checks will be performed by the game.
|- valign="top"
!86-110
!0x56-0x6E
|Unit's Name. Standard string ended by null byte. The rest can hold garbage.
|- valign="top"
!111
!0x6F
|Set to 1 when the unit fires, then back to 0 afterwards - determines whether to render the gun and firing arm in the "pointing weapon" position, or whether the weapon is being held against the chest. If manually set to a value above 0, the unit will hold its weapon out until such time as it actually uses it.

Note that this value is only used by units holding two-handed weapons. A unit holding for eg a pistol will ''always'' point the weapon, and uses a different arm sprite for the purposes of doing so (regardless of whether or not the weapon is being fired).
|- valign="top"
!112
!0x70
|0; sometimes 1 for aliens.
|- valign="top"
!113
!0x71
|If 1, then you can't use the inventory button and the unit will be immune to stun. Used for tanks. Mind controlled units don't use this but their button disables anyway.

''BombBloke:'' This is the only way to access tank inventories.
*Tank/Cannon has a normal inventory and uses man_1m0.spk.
*Tank/Rocket Launcher has a different layout and uses man_1m0.spk.
*Tank/Laser Cannon uses man_œ.spk, which doesn't exist normally. Providing this file still crashes.
*Hovertank/Plasma simply crashes.
*Hovertank/Launcher simply crashes.

[[#1|[1]]] actually determines the inventory screen used, might be worth playing with that. [[#46|[46]]] determines the layout.
|- valign="top"
!114
!0x72
|If not 0, then unit is on fire, and will burn for this amount of turns.
|- valign="top"
!115
!0x73
|Gender: 0 = male, 1 = female.
|- valign="top"
!116
!0x74
|Hair/skin colour (for inventory; all other units = 0):
0: Blond caucasian
1: Brunette caucasian
2: Asian
3: Black
|- valign="top"
!117
!0x75
|Turret weapon. Over-rides hand held weapon. Turret images are not centered; that would be impossible because they aren't all 'objects' (e.g. Celatid). ''(Mix of notes by BB and NKF)''
F.A. TUs F.A. TUs
0: HWP cannon (bigobs[40])....................Aimed 90% 80% Snap 60% 33%
1: HWP rocket (bigobs[42])....................Aimed 115% 75% Snap 55% 45%
2: HWP laser (bigobs[54]).....................Aimed 85% 75% Snap 50% 33%
3: HWP plasma cannon (bigobs[43]).............Aimed 100% 60% Snap 86% 30%
4: HWP blaster (bigobs[43]) (looks like ordinary cannon?)......Aimed 120% 80%
5: Celatid plasma cannon (bigobs[38]).........Aimed 110% 60% Snap 75% 30%
6: Cyberdisc plasma cannon (bigobs[34]).......Aimed 110% 60% Snap 75% 30%
7: Sectopod Laser* cannon (bigobs[34])as cyberdisk, above, plus Auto 50% 35%
22: Invalid - Incredibly powerful armour piercing shell. Overpowering.
255: Unused
Note: This item will take precendence over any item carried in the hand slots. It can be installed on non-tanks, but then the unit won't be able to use any carried weapons or items. This weapon is NOT affected by the kneeling modifier, but it is affected by the current unit's accuracy stat. Also note, this byte does NOT determine the turret image for HWPs in the battlescape.

[*]The damage type for the Sectopod is indeed set to (3)laser in the executable! Graphical/sound effects of a turret weapon is set there as well, via a reference to a weapon in OBDATA.DAT (HWP Cannon=4=Heavy Cannon, Sectopod=34=Heavy Plasma) ''When I changed HWP Cannon to 2, it looked/sounded like rifle fire - Crus8r''

Also see [[#46|[46]]], [[#113|[113]]], and [[#118|[118]]].
|- valign="top"
!118
!0x76
|Ammo for [[#117|[117]]] turret weapon
|- valign="top"
!119
!0x77
|Movement related? Large unit related? Possible bitfield.
''MTR:''
00000000 0 Chryssalid(2), Civilian(9), Ethereal(2), Floater(2), Muton,
00000001 1 Muton, PA Soldier(2) Sectoid(2), Silacoid(2),
00000011 3 PA Soldier PA Soldier(2), Tank/Laser
00000101 5 Snakeman
00001010 10 Celatid ''- Hobbes game - could have some garbage''
00001101 13 Muton, PA Soldier '' (parens) is count, if more than 1 unit''
00010011 19 Snakeman
00100110 38 PA Soldier
00101010 42 Muton(3)
00110001 49 Muton
00110010 50 PA Soldier
00110101 53 Silacoid(2)
00111011 59 Celatid
00111111 63 Silacoid
01001110 78 PA Soldier
01100111 103 PA Soldier
01111111 127 Muton
10010000 144 Muton
11000000 192 Celatid
11111110 254 Muton
|- valign="top"
!120
!0x78
|Unit bit flags, mainly re: mobility. They do NOT affect the soldier in inventory screen: ''(Mix of notes by BB and NKF)''
( 1) 1: 1 = Dead. ''This was only set for 2 of 3 dead aliens in my current game.''
''[[#13|[13]]] (Health=0) is the most reliable indicator for me.''
''-[[User:MikeTheRed|MikeTheRed]]''
( 2) 2: 1 = Unit can fly.
( 4) 3: 1 = Unit is flying. (Toggles leg sprites for power armour.)
( 8) 4: ??? Seems to flag if the unit has been selected this turn.
( 16) 5: 1 = Unit has been disabled for selection.
(Stops the unit tab button from selecting this soldier.)
( 32) 6: 0 = Unit has left hand object selected, 1 = right hand object selected.
( 64) 7: 1 = Unit is kneeling.
(128) 8: 1 = Unit is wearing power/flying suit. (Can't be stunned by smoke flag?
Seems to work for fire, too.)
If a unit is carrying something in either hand, it is impossible to get him to appear as if he is carrying nothing - in the game, at least. If he is carrying nothing, bit 6 can flag (as though the unit was using it's right hand item). But maybe it's just the order of dropped items affecting this?

Note: A unit is only considered as flying if it is not on the ground. For example, a hover tank is not always considered as flying.

What if a hovertank is half on the ground, half in the air? What about a treaded tank, or large alien unit? What about units in lifts?
|- valign="top"
!121
!0x79
|Possible Values: 0 or 16. All units in unitref.dat get a value of 0 except for the second unit in the list which gets 16. Doesn't matter if the second unit is a soldier, a tank, or an alien. It's always 16. Editing it to 0 doesn't crash the game or have any dire consequences.
|- valign="top"
!122
!0x7A
|Always 0?
|- valign="top"
!123
!0x7B
|Always 0?
|- valign="top"
!124
!0x7C
|TFTD ONLY - Appears to be a count as to which frame of bubbles the soldier is on. Can be 0 to 16 (0x0F), most likely 125/7D is included with this.
|- valign="top"
!125
!0x7D
|TFTD ONLY, unknown.
|- valign="top"
!126
!0x7E
|TFTD ONLY, unknown.
|- valign="top"
!127
!0x7F
|TFTD ONLY, unknown.
|- valign="top"
!128
!0x80
|TFTD ONLY, unknown.
|- valign="top"
!129
!0x81
|TFTD ONLY, unknown.
|- valign="top"
!130
!0x82
|TFTD ONLY, unknown.
|- valign="top"
!131
!0x83
|TFTD ONLY, unknown.
|-
|}

== Notes ==
1) The original/base values for soldier stats (offsets [[#23|[23]]]-[[#28|[28]]], etc.) correspond to the initial+increase bytes from [[SOLDIER.DAT|Soldier.Dat]] (bytes 43-62). Changes to these Unitref bytes are lost when the mission ends; instead, XCOM re-reads them from Soldier at that time. This makes sense because base soldier stats don't change during a mission per se (although they might increase when the mission ends); in this way, the programmers didn't have to bother with separately storing and/or adding initial+increase during combat. (It's also why you don't see the initial+increase in the soldier stat display during combat, that you can see back at base.) On a practical note, if you are testing soldier stat increases versus experience counters, change the experience counters in Unitref, but change the soldier stats in Soldier. (IOW, it doesn't matter what the soldier stats are in the combat mission.)

The Kill count (offset [[#78-79|[78-79]]]) is the only Unitref value I know of that is directly carried forward into the geoscape and Soldier.dat. However, some others do indirectly carry forward, for example: experience (offsets [[#80|[80]]]-[[#85|[85]]]) causes stat and rank increases, and decreased health (offset [[#26|[26]]] - offset [[#13|[13]]]) means hospital time. And, of course, death is permanent. Heh.

2) Experience counters (offsets [[#80|[80]]]-[[#85|[85]]]) determine the likelihood of soldier stat increases at the end of the combat mission, according to the formula for Primary Stats shown [[Experience#How_Experience_Points_Are_Applied|here]]. The Bravery counter (offset [[#85|[85]]]) affects Bravery as shown [[Bravery|here]].

Also, if at least one of the experience counters (except Throws) has a count, your secondary stats will increase, as discussed [[Experience#Secondary_Stats|here]]. All you need is at least a 1 in offsets [[#80|[80]]]-[[#82|[82]]] or [[#84|[84]]]-[[#85|[85]]]; more than 1 and/or multiple counters has no additional effect.

3) BombBloke's additional "To be Done" notes - can we cross some of these off yet?

Need to research:
Stun recovery rate, does it exist?
Hand to hand attacks
<strike>Offset of weapon from unit image?</strike>
''Based on unit height and nothing else. There may be values to determine what arm sprites to use,''
''but I doubt it.''
Firing sprite offset?
''Probably just based on unit height and some hardcoded values in the executable.''
<strike>Inventory lockout?</strike> ''All mind controlled units are locked out.''
Kneel lockout?
''Probably the same as above, I seem to remember that using XcomUtil to "swap sides" would make it''
''possible to kneel small alien units.''
<strike>Aliens seen?</strike> ''Not used in unitref.dat, only in unitpos.dat. -[[User:Zombie|Zombie]] 23:48, 29 September 2006 (PDT)''
<strike>Whether a unit slides/floats/hovers/rolls/walks (movement noise)?</strike> ''Set according to unit type.''
What else? The more to look for, the easier it is...

Know 111 values.
Unknown values (13 in total):
[[#34|[034 / 0x22]]] - Always 0?
[[#36|[036 / 0x24]]] - Always 0?
[[#43|[043 / 0x2B]]] - Set to 1 on occasion, usually 0.
[[#52|[052 / 0x34]]] - Seems to be a mirror of 48 / 0x30, the LOFTemp index for the unit.
[[#71|[071 / 0x47]]] - Appears to relate to lighting caused by the unit, [[Talk:UNITREF.DAT#Offset_0x47|discussion here]].
[[#74|[074 / 0x4A]]] - Appears to relate to the AI-mode used by the unit, [[Talk:UNITREF.DAT#Offset_0x4A_.2874.29|discussion here]].
[[#75|[075 / 0x4B]]] - Always 0?
[[#112|[112 / 0x70]]] - Set to 1 for some aliens, 0 otherwise.
[[#119|[119 / 0x77]]] - No idea, possible bitfield, could be anything.
[[#120|[120 / 0x78]]] - Unit bit flags, mainly re: mobility. Only one bit not 100% identified.
[[#121|[121 / 0x79]]] - Second unit gets a value of 16. Everyone else gets 0. No obvious purpose.
[[#122|[122 / 0x7A]]] - Always 0?
[[#123|[123 / 0x7B]]] - Always 0?

Know 1 TFTD value.
Unknown TFTD values (7 in total):
[[#125|[125]]] [[#126|[126]]] [[#127|[127]]] [[#128|[128]]] [[#129|[129]]] [[#130|[130]]] [[#131|[131]]]

4) Hobbes posted a savegame with a TON of different aliens in it [http://www.xcomufo.com/forums/index.php?showtopic=8591 here] (message 6). Interesting for testing. But note it was made with XCOMUTIL and there may(?) be concerns over vailidity of unit info - see [[Talk:UNITREF.DAT]].

5) A [[HackerTools|Hex Workshop]] Structure Library for UNITREF.DAT created by Danial is [[UNITREF_DAT_HSL|here]].

== For More Information ==
*[[SOLDIER.DAT]]
*[[Soldiers|Soldier Stats]]
*[[Experience]]
*[[HackerTools|Hex editing]]

Return to [[Saved_Game_Files|Saved Game Files]]
[[Category:Game Files]]

User talk:Bomb Bloke:Firing Accuracy

2012-03-04T06:26:19Z

Zaimoni:

{{tocright}}Consider this [[User:Bomb Bloke|Bomb Bloke's]] draft/discussion about firing accuracy. This topic has been dragging on for quite some time now, so I figure it to about time I had a stab at it.

My view on the matter is this: When you fire a gun, UFO works out the horizontal and vertical angles between your unit and the target, then modifies these depending on your [[Accuracy_formula|overall accuracy stat]].

Say for example you have a perfect 100% (or better) "accuracy". The lines are nearly unmodified, and so near guaranteed to hit (assuming there are no obstructions, in which case you should get a "No LOF!" message when you attempt to fire. Note that the game doesn't ALWAYS give this message and will sometimes allow you to attempt "impossible" shots. In these cases, less-then-perfect aim might still allow the shot to land).

As your rated accuracy decreases, target size and distance become all important: As size decreases and distance increases, the range of angles that could land a hit fall. As accuracy decreases, the range of angles that a shot can take rises and so it becomes less likely that a given shot will fall within the "hitting" range of angles.

(As for why multiple angles can "hit", think of your target as a dartboard: Perfect aim would result in a bullseye, approximate aim would still hit the board, and bad aim would miss altogether. However, in X-Com, you get full "points" so long as the bullet hits the target at all).

That is to say, the ultimate firing accuracy formula would be (range of acceptable hitting angles)/(range of possible firing angles). Assuming, of course, that when firing you're just as likely to fire at your maximum "worst" angle as you are your "best", the range of angles that can hit is determined by target distance and size, and the range of angles that can be fired along is determined by your rated firing accuracy.

However, as it turns out, the angle your shots take isn't entirely random - they follow a bell curve. You're more likely to at least hit near the target then you are to get a massive "air ball" shot. So the formula in truth will end up looking a bit more complex then that.

== Firing Point Origin ==

To get the absolute range of angles a unit can fire along, you first need to know where a unit is firing from. To this end I created a copy of my game folder and modified a save game, some terrain files, and the LOF templates.

[[image:BBFiringPointTest2.png|right|thumb|200px|A basic map of a tile. As it turns out the Y axis really points the other way.]]Now, when we talk about UFO maps, we generally refer to their dimensions in terms of how many tiles there are. However, each tile is really made up of smaller "points": A 16x16x24 point space. This means that a 30x30x4 map has 3,600 tiles in it, and 22,118,400 points within those. When a unit fires, he doesn't aim from his tile at his target's tile, he aims from a point within his tile at a point within his target's tile.

This first test was aimed at discovering exactly where a shot originates from, by creating tiles on units to selectively block their LOF. By seeing which tiles did and which did not, it could be seen exactly (or, at least, as accurately as I think I'm going to get it) where the shots were coming from.

[[image:BBFiringPointTest3.png|right|thumb|200px|The Empire's got nothing on BB's clone army.]]The first row of units served as targets for the second, which stood on tiles similar to the large earth blocks you see in bases but with one layer removed from each. Each therefore entirely blocked LOF so long as the removed layer wasn't at the same height as the unit's firing origin point. The only unit able to fire through the gap was the one sitting on the tile with the third layer down removed.

However, when defining tiles with [[LOFTEMPS.DAT|LOFTemps]], you can only stack the layers 12 high. Presumably the game "double stacks" them to make the resulting 24 point high object. Because of this, the removed layers accounted for two possible Z co-ordinates, meaning the exact value there is still unknown. Might be able to work something out to get it more precise, I dunno.

The third row stood on walls facing to the east/west. Unlike the second row, in this example I moved a single thin wall through each tile, as opposed to moving a "gap". This meant that only one unit would not be able to fire, and that was the one sitting on the ninth tile (made up of my layers from LOFTemps[15]).

[[image:BBFiringPointTest1.png|right|thumb|200px|LOFtemps used, as opposed to the [[LOFTEMPS.DAT|usual set]].]]The forth row followed more or less the same concept, with the walls facing north/south. Only the first unit was unable to fire (LOFTemps[23]).

So! With this information, getting a (x,y,z) co-oridinate is easy enough: It's either (8,15,18) or (8,15,19) (the Z co-ord being imprecise due to the 12 LOFTemp layer limitation).

Note that this value only goes for units with a facing of north. When I get time I'll go through and work it out for the other directions. Furthermore, Sectoids are likely to have a lower firing point (as their guns are rendered lower on the screen).

----

[[Image:origins.png|frame]]

I found an interesting piece of code (offset 40D8E0 for the curious). The formula for the starting zpos when firing looks like this:
''unitpos.zpos*24+unitref.terrain_height-unitref.standing_height+27-unitref.floating_height''
and for kneeling units:
''unitpos.zpos*24+unitref.terrain_height-unitref.kneeling_height+27-unitref.floating_height''
(unitref.terrain_height is offset 0x27 in unitref.dat)
I did a live check with a debugger, for a standing unit on the lowest level it gives this:
''3*24+0-16+27-0=77''
Since the engine seems to use zpos=0 for the ceiling of the topmost level, then the floor must be at offset 4*24=96. floor_level-firing_level=96-77=19, in accord with your empirical results.

Now for xpos and ypos, the engine uses several tables, indexed by the facing orientation (offset 0xa in unitref.dat):
''.data:0046B5E4 dw 8,0Eh,0Fh,0Fh, 8, 1, 1, 1''
for xpos, and
''.data:0046B5C4 dw 1, 1, 8,0Fh,0Fh,0Fh, 8, 1''
for ypos. When facing north, the shot should come from 8x1x19. Note that it is in disaccord with your experience. Maybe you don't use the same point of origin as the engine? [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

You are correct. Moving my origin to match yours brings my data into line (I was limited to guessing it's correct location). Awesome to see the ceiling size confirmed at long last. :D - [[User:Bomb Bloke|Bomb Bloke]] 02:52, 8 May 2008 (PDT)

----

Big units use 2 other tables located at offsets 46B604 and 46B624. I did not try to change these values to see if it changes the position where the shots come from. [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

The xpos/ypos information agrees with my own in vivo research (it explains several LOS different than LOF paradoxes I have explicitly verified). -- [[User:Zaimoni|Zaimoni]] 11:49, 3 May 2008 (CDT)

== Rated Accuracy Vs Angle Range ==
===Empirical Results & Discussion===
[[image:BBFiringPointTest4.png|thumb|200px]][[image:BBFiringPointTest5.png|thumb|200px]]Just a few results before I go off camping for the weekend. First off, note that [http://www.strategycore.co.uk/forums/index.php?act=ST&f=22&t=5805 the logger] used on this occasion is one I wrote up a year ago. It's not entirely accurate, and needs to approximate values (this is because I can only get it to think in terms of angles between tiles, as opposed to angles between points - as a result you see "steps" in the line graphs provided here). I've thought up some improvements for it (like sticking a roof in the map used so I can get some decent vertical angle stats), but even if I implemented those it'd still never be "accurate".

That said, I got [http://pastebin.com/mcbc752a 2550 results for 0% firing accuracy] overnight and [http://pastebin.com/mdf60034 1876 for 50%] today. I've got the system in concern running trials for 25% until tomorrow.

The graphs displayed summarise these angles. Essentially they go from "those that went to the left" across to "those that went to the right". The longer the line stays at a given level, the more shots took that angle.

At 0% accuracy, the largest horizontal angle I got AWAY from the target was 27.5 degrees (that is to say, a shot could go anywhere within a range of 55 degrees), the average angle being 7.32 degrees. With the side graph you can get an idea of the distribution: Your shots are more likely to hit or at least get close then they are to be far away.

Bumping the rated accuracy to 50% lowered the maximum angle to 17.01 degrees (average of 2.75). Again, you're a lot more likely to get close to the target then you are to reach the possible extremes.

I've since done tests at 100% accuracy and found that the same curve exists, just squished right down. You still have a chance to miss, but only by slight amounts. A formula should be apparent in there somewhere.

At a glance I think it's an exponential equation divided by your rated accuracy? With a few more tests I suppose it'd be more apparent.

: My theory is this that the program first runs "was shot accurate?" check. If yes, then shot deviates 0 and hits the target. If shot misses, calculate path of bullet. Path of bullet follows formula that gives that bell curve.
: I rather suspect that at 25% accuracy, 25% of your shots will be on target, at 50%, 50% will be on target, so on and so forth.
: There might be some additional weird "random drift" that makes 100% and higher accuracy still miss. *Shrugs*. - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: I am absolutely convinced that there is no "was shot accurate?" check. If there was one, I reckon it'd be apparent on the graphs here. I could be wrong, but I believe I've seen no data that supports the theory. No, finding that a certain accuracy rating "seems right" when firing from a certain distance is not supporting data, in that this is the case regardless of whether an "accurate shot" check exists. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)

: Despite the fact it will make your life even harder, I have to remind you that there is also PARTIAL COVER to factor into the tests... what happens when the target is behind a window (modded to be indestructible?), behind a hedge, only his head is visible poking out through the floor (bug here lol)... sometimes a shot will go THROUGH a window, sometimes it will HIT the window... - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: Remember, the "accuracy formula" I'm looking to determine simply returns an angle, which, dependant on your overall accuracy score an the random number generator, will go off on some who knows what direction. Whether that angle leads to the target is dependent on the visible target area versus the angles you'll get based on your accuracy stat (this "target area" concept is the purpose of the next section down, mostly unwritten because it's pointless until THIS formula is figured out).

:: That is to say, there's no real formula that can tell you the REAL chance to hit a target without actually inputting all the tile data in addition to using the "angles formula" I'm after here. Luckily, once the angle formula is determined, it shouldn't be too hard to have my battlescape editor calculate the "true" chance of a shot hitting. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)

: I wonder if it's possible that the game's maximum firing angle (e.g. at zero accuracy) is one radian - about 57.3 degrees? This is near your observed limit of 55 degrees. The game engine would probably use trig functions based on radians as I believe they are the most efficient. Given the power of the computers they were programming for, this vector work was pushing the envelope so they would need to be efficient. - [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)
::I would say that yes, given the close proximity (and the inherent inaccuracy of my logger, due to the inability to pick up on the precise ''point'' a bullet hit), one radian is correct.

::The [[COS.DAT]] page will probably be relevant at some point, dunno if you've read that. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Also could you clarify the axes on these 2 graphs/histograms? I'm having a lot of trouble understanding them. Is it possible that the vertical axis should be frequency, and the angle should be on the horizontal axis? Or am I being dumb? If I'm understanding them correctly, we are not seeing a linear distribution of error angles - as you would get from say

ActualAngle=AngleToTarget+(rand(57)-(57/2))

:what we are getting is angles that cluster together near the correct aimpoint, and frequency falls off quickly as you move away from the correct aimpoint.

:: You are reading the charts correctly. The vertical axis shows how often a specific angle was picked to fire along by the game, and the horizontal axis shows the angles themselves. The reason the charts are symetrical is because shots can either go to the left or right of the target (an angle of 0 means it hit). Even with 0 FFA, you're a lot more likely to send a bullet near the target then you are to send one on the maximum diverging angle - hence my statement, "I think it's an exponential equation divided by your rated accuracy". - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Guess: The graphs look not unlike a tangent or inverse tangent function. That might suggest that the firing function injects a linear amount of perpendicular drift (horizontal and maybe vertical) onto the bullet's vector. Maybe try graphing the tan() or arctan() of the data from the "zero accuracy" tests, and see if you get a horizontal straight line.

: arctan (0.5), which might be relevant if maximum "perpendicular error" is 1 map square wide per map distance unit, is 26.565 degrees, near to your value of 27.5 degrees. Arctan (0.25), which corresponding to half that "perpendicular error", half a map square wide per map distance unit (and maybe corresponding to 50% FFA????), is 14.036 degrees, again near to your value of 17 degrees for 50% FFA. But only 'near', and higher. Hmm. Your data have a horizontal granularity of 1/16th of a map square distance unit, is that right? So there could be some data slightly outside the true upper limit for angles. It depends on the range to your target in your test setup I guess. [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)

:: This is where my brain starts to melt, mind you, it's 3:15am here so I'm probably not good for any number crunching right now. But I reckon you're onto something even if I can't wrap my brain around what!

:: I put the target about 25 squares back (middle of the map). Really can't remember. Ideally I'd've set him to be a pixel in size, but back then the "using LOFTemps for unit size" thing was just a theory I had, not a proven fact (I never got around to updating this page when it WAS proven, that's how long these notes have been here).

:: Yes, granularity is a 16th of a standard user-visible map tile. On the horizontal plane anyway. Can't remember if I set it to 24ths on the vertical, but I probably did. The problem is, of course, that it can only pick up data according to whether a bullet hit a tile or not (as opposed to data on where the tile was hit), so although the range of angles should be "close to accurate" there's still those nasty steps everywhere which have to be "guesstamated".

:: I never really bothered much with the vertical data as I was mostly "proving the concept", figured I'd get to that later. I know I logged it (I was even able to draw an ellipse to show where all the bullets would fall, your maximum vertical angles are of course no where near your maximum horizontal ones), but I can't find the charts in concern. They weren't that good anyway as the test map had no ceiling.

:: I distinctly remember logging and graphing the 100% FFA data but can't find that either. Probably deleted it from my system (in the misguided belief that I'd uploaded it all here). I cannot find any of my related logs at all, in fact, just a single zip file with the logger, test map and automated script file ready to go. Again, this may be because I've deleted them, or because I have nearly ten thousand files in my UFO directory. My main one, anyway. I have a few such directories. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

: OK. The curve you graph above for "zero accuracy" looks not unlike what happens if you graph tan(x) (in degrees), where x is from +0.5 to +0.5. But I think that's a coincidence, since your graph is not a standard histogram - you are showing "frequency" by the length of lines on the x axis, rather than by the height of bars along the y axis as in a standard histogram. In order to turn your graph into a standard histogram it would need to be more or less inverted I think.
: The link to the "zero accuracy" data set is broken now. From what you said above, the data is lost now, which is a shame as it would be nice to do a histogram of tan(a) for all the angles "a" in that data set. You might see a flat line, linear distribution. Or not. If the angles are "bunching up" in frequency toward the target centre, then that suggests a ''linear perpendicular'' distribution of angles. With a linear perpendicular distribution (eg varies by +/- 0 to N units, perpendicular to the path to target, per unit of distance), you would expect a "bunched" angular distribution, i.e. if you sorted all the angles in the data set, the separation between one angle and the next widest would steadily increase.
: The Z component is going to complicate things and prevent finding an exact solution. For example, say that the Z (vertical) error/cone and X (lateral) error/cone are not independent of each other. For example, they might be constrained to add up to some constant N that's related to FFA: Z + Y < N. Or in fact, it might be more like (vertical x 4 + horizontal x 1) < N (since we suspect the actual 'bullet group' is an oval, wider than it is high, rather than a circle). A circle is almost the simplest case, but again unless Z and X are totally independent, you're not going to find a close fit for the function without knowing both terms. Hopefully the oval is very 'flat' and so the horizontal-only function will be a good enough approximation of the data to get in the right ballpark. Or even better, maybe the Z component is a totally independent function. Hope so.
: Let me make a prediction or a series of predictions then for maximum angle off-target:
:* 0% FFA = 1.0 perpendicular error per unit distance = +/ 0.500, arctan(0.500) = +/- 26.6 degrees
:* 50% FFA = 0.5 perpendicular error per unit distance = +/ 0.250, arctan(0.250) = +/- 14.0 degrees
:* 75% FFA = .25 perpendicular error per unit distance = +/ 0.125, arctan(0.125) = +/- 7.1 degrees
:* in general, horizontal maximum angle off target = +/- arctan(((100-FFA)/100)/2)
: Well that's most likely wrong but it's good to have a starting point for testing! [[User:Spike|Spike]] 17:40, 15 March 2009 (EDT)

Hey, guess what? First thing on completing a fresh round of tests, I discover all my old logs.

Of course.

Originals (with no roof on the map so the vertical shot data is a bit iffy): [[User_talk:Bomb_Bloke:0acc1|0%]] - [[User_talk:Bomb_Bloke:25acc1|25%]] - [[User_talk:Bomb_Bloke:50acc1|50%]] - [[User_talk:Bomb_Bloke:75acc1|75%]] - [[User_talk:Bomb_Bloke:100acc1|100%]]

New data (with a roof, vertical shot data might actually be worth something): [[User_talk:Bomb_Bloke:0acc2|0%]] - [[User_talk:Bomb_Bloke:25acc2|25%]] - [[User_talk:Bomb_Bloke:50acc2|50%]] - [[User_talk:Bomb_Bloke:75acc2|75%]] - [[User_talk:Bomb_Bloke:100acc2|100%]]

Comma separated data, one shot per line. First three columns are the absolute tile x/y/z co-ords of where the shot ended up hitting (keeping in mind the shooter is at tile 24/49/2). Next three columns are the x/y/z of where the shot landed, relative to where the shooter is. Final two columns are the important ones, they cover the horizontal and vertical angles the shot took, respectively.

Yes, the wiki doesn't represent it very neatly. Use the edit button to get the line breaks back.

Hrm. Looks like the max angle at 75% comes out to 11.53 degrees... Not 7.1. :(

- [[User:Bomb Bloke|Bomb Bloke]] 09:37, 18 March 2009 (EDT)

----

[[image:BBFiringPointTest6.png|thumb|200px]]
Here is a graph that somewhat better displays the results of my initial 0FA results. The blue line represents the recorded numbers (2550 different values). The red line represents an equal number of results generated by the spreadsheet formula "SIN(RAND()*1.5)*28.64788975*IF(RAND()>0.5;-1;1)".

(Which is, effectively, "The sine of a random number between -1.5 and 1.5 multiplied by half a radian").

Unfortunately the two formulas don't line up (even if you mirror 'em on the diagonal), but they're fairly close. Much closer then the exponential equations I tried graphing, at any rate. I'm thinking I might be able to get something better still with TAN, but I don't seem to be having much luck with that...

- [[User:Bomb Bloke|Bomb Bloke]] 02:18, 15 April 2009 (EDT)

: tan eyeballs great if you assume the distribution going in is some flavor of "sum of linear distributions". tan-1(25°)=0.466307658155; halving this and taking the tangent again gets me ~13.1°, which is reached about 1/16th of the way across. I'm assuming some sort of discretization error for the asymmetry. (My initial gut reaction was "sum of two linear distributions", but that isn't correct; that would have landed about 1/8th of the way across. The quick-and-dirty way to fake a bell curve is to sum three linear distributions.) -- [[User:Zaimoni|Zaimoni]] 11:52, 15 April 2009
(CDT)

: Per geometric check; tan works if the incoming angle is from a sum of three linear distributions. That is: tan(K*rand()*rand()*rand()) should recover the graph up to discretization error, for some K. -- [[User:Zaimoni|Zaimoni]] 12:02, 15 April 2009 (CDT)

:: Is there any chance it's some function of (Kx rand(x), Ky rand(y), Kz rand(z)? [[User:Spike|Spike]] 17:53, 15 April 2009 (EDT)

::: It depends on what you mean...

::: I was presuming rand() was a zero-parameter function that needed "massaging" to get to any range other than its default. C rand() would be 0..RAND_MAX. XCOM almost certainly has a wrapper that returns values in a range 0..N. Given when XCOM was written, I don't think it has any sort of floating-point RNG. I wrote K to subsume all of the range-massaging that was needed.

::: That said, a general sum of three linear distributions would have been tan(K1*rand()+K2*rand()+K3*rand()-AVERAGE) [ignoring overflow issues], where AVERAGE is the statistical average expected from K1*rand()+K2*rand()+K3*rand(). The geometric check almost certainly wouldn't pass if the three constants were obviously distinct. The actual expression I'd try retrofitting is tan(K*(rand()+rand()+rand())-AVERAGE). -- [[User:Zaimoni|Zaimoni]] 14:07, 16 April 2009 (CDT)

:::: If rand() was to receive any parameter at all, it'd be a seed; but calling the function three times should result in three different numbers anyway (typically you seed the RNG first). I'd be surprised if even the original game didn't have a floating RNG. Even back on the Spectrums/Commodores/BBCs you could generate within most any range by typing something like RNG*N. I tried graphing TAN(RAND()*1.5) then TAN(1.5*(RAND()+RAND()+RAND())-2.25), though the first formula wasn't right and the second was worse. :( It's a bit too steep (a little like what you get from 1/x but flopped around). Maybe something a bit higher then 1.5 would sort that out, but I dunno how high you can legally go with TAN? - [[User:Bomb Bloke|Bomb Bloke]] 20:36, 16 April 2009 (EDT)

::::: tan goes unbounded at ±π/2 radians i.e. ±90° Given that the initial bounds appear to be ~±25°, I'd calibrate things so that we were looking at a total span of 50° i.e. ~0.872 radians. In radians, with rand() being a uniform distribution 0..1: TAN(0.872*(rand()+rand()+rand())-0.436) would be my guess.

::::: XCOM 1.2 had some source code comments indicating that the C source targeted Watcom C. That means the "easy rand" available is the C standard library rand(), which without processing returns an integer from 0..RAND_MAX, where RAND_MAX may be as low as 32,767. -- [[User:Zaimoni|Zaimoni]] 12:36, 17 April 2009 (CDT)

: 55 degrees horizontal deviation range corresponds to 440 1/8 degree units; quick-but-lousy-RNG C source for the eighths-of-degrees input to the tangent function at accuracy 0 should be <code>(rand()%147+rand()%147+rand()%147)-219</code> . This plausibly is from a "deviation output" function that returns 73 at accuracy 0, 45 at accuracy 50, and 31 at accuracy 75. Corresponding psuedocode:
<pre>const int tmp = acc_func(...);
const int rng_scale = 2*tmp+1;
const int rng_bias = 3*tmp;

....

(rand()%rng_scale+rand()%rng_scale+rand()%rng_scale)-rng_bias;</pre>

: -- [[User:Zaimoni|Zaimoni]] 13:58, 26 December 2010 (CST)

: That means the deviation output function should be something like <tt>73-INT(14*Accuracy/25)</tt>. -- [[User:Zaimoni|Zaimoni]] 14:31, 26 December 2010 (CST)

::[[image:acc50zaitest.png|thumb|200px]]That's pretty good, I reckon you've nailed the angle caps, probably perfectly - though the "average" values returned by the final formula are still somewhat out of sync with those observed. Here's a graph comparing the two at accuracy 50. On average, the game is getting more shots going along at a 0 (or near 0) degree angle (shown in the red, in case the jagged mess doesn't make it obvious ;) ), whereas the formula is getting the same spread (of course) but with far more "misses" overall. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:18, 28 December 2010 (EST)

::: I'll have to cross-check that graph of the theoretical curve. Thing is, since I play with the projectiles in slowest-speed possible by default I'm pretty sure that I'm not getting 50% perfect shots at 50% accuracy. That would be the snap impression from the current graph: 50% perfect shots, 50% deviated shots. -- [[User:Zaimoni|Zaimoni]] 18:15, 28 December 2010 (CST)

:::: I'm getting a flatter candidate theoretical distribution than your graph, but not as flat as the empirical graph. Much depends on the exact rounding/truncating behavior.

:::: I see that the graph has steps at the 1° points; the theoretical distribution being considered is in steps of 1/8°.

:::: The simplest classical approximation at range 40 for an on-axis shot at a north wall (due north of the firer; corresponding range for due south of the firer is range 41), would read any horizontal error angle with absolute value less than arctan(1/81) ~ 0.7073° as perfect. The corresponding candidate theoretical rate (for shots with error between -5/8° and 5/8° inclusive) is approximately 9.05%.

:::: A better classical approximation would use the actual origin of the shot in voxelspace, rather than the impossible midpoint. -- [[User:Zaimoni|Zaimoni]] 19:41, 28 December 2010

::::: Two problems with the above.

::::: First, the firing origin for due north has been measured: it's (8,1). That means the fast approximation would have been arctan(1/80) [which numerically doesn't change anything].

::::: To set up the classical approximation at range 40 due north, the actual arctangents needed are -arctan(8.5/(16*40)) and arctan(7.5/(16*40)) [these correspond to the west and east edges of the north wall section]. Numerically, this is ~ -0.7609° and ~ 0.6714° . That is, the actual corresponding theoretical error rate is for shots with error between -3/4° and 5/8°, which is approximately 9.87%. -- [[User:Zaimoni|Zaimoni]] 20:14, 28 December 2010

: Just realized that the targeting center should be (8,8) (all of the [[LOFTEMPS.DAT]] templates used by units are centered there). -- [[User:Zaimoni|Zaimoni]] 20:19, 30 December 2010

 
===Stuff from the code===
I found this in the code. It uses some sort of '''"divergence factor"''' (I am unsure of its real function).

Processus:
1) Check "actual" Firing accuracy (aFA, the result of Acc. formula) against x=RND (100).
2a) Failed. The '''Divergence factor = x - aFA + 50'''.
2b) Successful. '''Divergence factor = x - aFA + 10'''.
3) If Divergence factor <0 then Divergence factor =1. --- This basically explains why even 100%
accuracy shots will sometimes not make
the target, but at 110% they should
always hit (can anybody confirm it?
- or maybe the minimal divergence factor
of 1 still makes them sometimes miss).

Note that for 2a), x-aFA is a positive number, while for 2b) it is negative.

An example: you have 100% actual Firing accuracy. You fire. The game rolls x = 95. The divergence factor is then 95 - 100 + 10 = 5. You may miss on long distances. --[[User:Kyrub|kyrub]] 11:17, 8 December 2011 (EST)

:If 2a is always positive and 2b always negative, does that mean x = aFA is treated as a failure?

:An interesting observation is that you've got a one-in-a-hundred chance of x + 10 = aFA, so long as aFA is from 10 to 109 (getting it higher makes it impossible to achieve, given that x will be ranging from 0 to 99). When this happens DF = 0. This shot SHOULD always hit, as it will take the perfect angle with no deviation - no terrain will block it, because if there were anything in the way of this particular shot, the game wouldn't let you attempt it in the first place.

:This means I was incorrect in my theory that the game never rolls a "this bullet will hit" shot. It does, but this chance has very little to do with your actual accuracy score (if you qualify for it, you've got a 1% chance of getting it, and that's that). The much more common DF = 1 shots, on the other hand, aren't always perfect - but I don't think it's possible for them to miss if the target has no cover, though. Maybe if you're shooting a sectoid at really long range perhaps.

:[[image:Horizontal_Firing_Angles.png|thumb|200px]]
:Anyway! Based on the stuff I logged in the above section, I made the simple assumption that the horizontal angle of your shot (that is to say, how far to the left/right of the target it'll go) is plus or minus half a radian times RND (DF) over 150 (on the basis that the highest DF the above code can throw is 150, and the furthest a shot can diverge from a target is half a radian). I generated a few thousand shot angles based on this idea and graphed them over the ones I logged from the game itself.

:For whatever reason OpenOffice kept crashing on me when I tried to graph accuracy scores of 100 (I guess it didn't like dealing with so many low values. Perhaps I should update it or something). For the most part, the results are ''near identical'', but the in-game results curve ''slightly'' more then the generated ones do (that is to say, in-game shots tend to be closer to the target slightly more often then predicted). Using the DF with this "simple" formula is not quite right, but the real one will be something very similar.

:(A refresher on what the graphs mean: They basically measure odds of getting a given shot angle. As the line gets steeper, the odds are lower. Flatter means better odds. For example, 75 has a long near-flat line at around 0, caused by DF rolling as 1 to 10 about 75% of the time - this means you've got a great chance of firing on a near-perfect angle. The lines are at their steepest near the edges, indicating you will hardly ever fire as badly as you ''can''. The blue line, representing the data measured from in-game tests, is jagged due to inaccuracies in the testing process).

:Scratching my head a little over what the vertical angle formula might be. I was thinking it might be the same, only using an eighth of a radian instead of just half a one; doesn't match up at all when I graph it though. But I don't think I've been able to log enough data in that area to compare the results properly. Might have to design another map for that, assuming you can't spot any more related code. ;) -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 00:01, 4 March 2012 (EST)

:: You may recall that the game goes through COS.DAT and SIN.DAT rather than C sin() and cos(); angle units are 1/8th of a degree, rather than radians. I bet the graph will work much better that way. -- [User:Zaimoni|Zaimoni], 00:25, 4 March 2012 (CST)

 
===Vertical Error vs Horizontal Error===

Hmmm.... I don't know about you guys, but I notice that in my games, when firing from Level 0 at enemies on level 0, my soldiers seem like their vertical deviation tends to be very small, even with high inaccuracy. Their horizontal deviation seems much much larger. Is this my imagination?

- [[User:Jasonred|Jasonred]]

----

You're quite right, they're two different things. There's enough error there to miss at point blank range against a short target, but still nothing like what you get in the horizontal scheme of things.

- [[User:Bomb Bloke|Bomb Bloke]] 08:46, 17 April 2009 (EDT)

== Target Size ==

Units are cylinders, made up of a [[LOFTEMPS.DAT]] layer determined by [[UNITREF.DAT|UnitRef[48]/[52]]], stacked according to their [[Height]].

The full purpose of UnitRef[52] is still in doubt, though it always seems to mirror the value held at [48]. My personal guess is that one is (or at least, was supposed to be) used when bullets come in on one angle, and the other value is used when bullets come in on a perpendicular-ish angle (hence allowing the cylinder to act more like a squished tube, which is closer to the shape of a real person - or it would do if 48/52 didn't always match).

So, yeah, set [48] to 0, all your units get set to an empty LOFTemps record, they cannot be seen/hit by the aliens. Hurrah.

== See Also ==

Pages relevant to this subject:
*[[Firing Accuracy]]
*[[Accuracy formula]]
*[[Firing Accuracy Testing]]
*[[Height]]
*[[LOFTEMPS.DAT]]
*[[Blind Spots From First Principles]]

Talk:Agents (Apocalypse)

2011-10-16T04:48:24Z

Zaimoni:

Figured I'd throw this out here as an interesting thing: Androids appear to have infinite Stamina (at least in Real-Time Tactical Combat). I've not thoroughly checked this out yet, but I have looked at it a few times and never noticed their stamina to be anything less than max. Usefull to let your Androids sprint to the far UFO door and still be able to sprint BACK if he runs into a Popper or something.
~~Sunflash; Jan 2, '10; 9:47PM CT

: This is not unique to androids. I'm not sure what the exact limits are, but in general a high strength combined with "low" loading results in most if not all actions having zero stamina cost.

: Androids just invariably have high strength. -- [[User:Zaimoni|Zaimoni]], 19:31 Jan 3 2010 CST

: Oh, really? So in theory you could load down an Android to the point where he'd show a loss of stamina? I'm at work for awhile yet so I can't test that just yet. --Sunflash
:: Well, looks like I'd just never managed to actually get my Androids loaded down enough. Awoup. D: [[User:Sunflash|Sunflash]] 22:34, 5 January 2010 (EST)

== Edited the Ranks section to reflect the Agent Ranks page ==

Just updated to include others' and my own findings regarding rank progression, which were discussed in the [[Agent Ranks (Apocalypse)]] discussion page. - [[User:KingGale|KingGale]] 14:14, 13 October 2011 (EDT)

== Human and Gravball League Relations ==

It's not related to the last edit, but it came to mind as I was skimming over the page. Has there been any evidence that humans and the Gravball League (or any other company) are directly related? -[[User:NKF|NKF]] 00:48, 14 October 2011 (EDT)

: It's empirical at best unless you know of any way to check the game code. I tried it just now and for 20 days the average number of Agents available with Gravball League allied was 2.4. With them hostile the average number of Agents available for hire was 1.9. Not extremely significant. Also, these numbers vary from game to game depending on how many personnel slots you have available, I believe. I had only 5 slots when I checked, so the numbers are a bit low. [[User:KingGale|KingGale]] 15:15, 14 October 2011 (EDT)

:: It also doesn't help that changes to the recruit list is randomly determined each day, as you can reload the same week over and over again and the results will be different as to who appears and who vanishes off the list. -[[User:NKF|NKF]] 16:53, 14 October 2011 (EDT)

::: Five slots is enough to test. The normal available range per day is 0-3 humans, 0-1 hybrids, 0-1 androids (theoretical average/day 2.5). Gravball league hostile figures look more like 0-2 humans per day. -[[User:Zaimoni|Zaimoni]] 23:47 Oct. 15 2011 (CDT)

Talk:OBDATA.DAT

2011-04-03T05:34:56Z

Zaimoni:

Would anyone know how to change the TUs needed to work the psi-amp? I don't see anything in OBDATA (all its TU fields are set to 0). It would be helpful to [[MTR_Psi_Testing|psi testing]]. NKF? ---[[User:MikeTheRed|MikeTheRed]] 16:29, 7 September 2006 (PDT)

:In case someone is still interested, I located these pieces of code that may be related to psi attacks (note that 25 = 0x19) :
.text:0041F163 8B 15 88 3E 4A 00 mov edx, currentUnit_pUnitRef
.text:0041F169 80 7A 0C '''19''' cmp byte ptr [edx+0Ch], 25 ; current TUs
.text:0041F16D 0F 82 94 01 00 00 jb loc_41F307
:and
.text:0041F230 A1 88 3E 4A 00 mov eax, currentUnit_pUnitRef
.text:0041F235 80 40 0C '''E7''' add byte ptr [eax+0Ch], -25 ; consume TUs
:(-25 = 0xE7).
:You may want to change the values I hilighted and see what happens when you try to panic a unit ;-)
:Same for mind control:
.text:0041EE89 80 7A 0C 19 cmp byte ptr [edx+0Ch], 19h
:and
.text:0041EF55 80 40 0C E7 add byte ptr [eax+0Ch], 0E7h
Have fun! [[User:Seb76|Seb76]] 14:39, 28 April 2008 (PDT)

IT WORKS. Seb76, you're a genius. TUs for MControl and MPanic, tested. Just one glitch, the pop-up menus show the old values. Could you please tell us what more should be changed? --[[User:Kyrub|Kyrub]] 16:44, 30 August 2008 (PDT)
----

Unfortunately obdata doesn't store all weapon stats. Unique actions like the costs for priming grenades, throwing stuff, mind probe, psi amp, etc are tucked away in tactical.exe. Hmm, I'm positive that they can be located, but there are so many iterations of similar values that it could take a long while to discover them.

What could make thi worse is the possibility that these in-built actions (perhaps even the in-built alien melee attacks) will not be clustered together near each other.

- [[User:NKF|NKF]]

----

Arg. Well it's not a real big deal. The psi equations are now known quite well; it'll be posted shortly. Reducing psi-amp TUs would make it easier to ultra-tune the psi equations, but it wouldn't make any difference to players. Don't knock yourself out, but if you can find it, that'd be nice! Thanks for the reply ---[[User:MikeTheRed|MikeTheRed]] 18:40, 8 September 2006 (PDT)

==Lazar Blastas!!1==
It occurs to me that I have no idea what it is that allows the laser weapons to fire without a clip. At first I thought simply giving them a base power rating (something other weapons don't have) was the key, but apparently giving a clip a power of 0 doesn't render it useless...

Can someone provide some details on this?

-[[User:Bomb Bloke|Bomb Bloke]] 03:32, 4 October 2007 (PDT)

-----

Just a quick gaze at obdata, it seems that the laser's three clip types appear to be set to 255 (or -1 if we think in terms of signed values) to mark that they're not used and the item has a power rating. Apart from that, I can't see anything terribly out of the ordinary. - [[User:NKF|NKF]]

-----

To make a weapon clip-less and ammo-less you must set the clip references all to 255 like NKF mentioned. Make sure to set a power rating in [022] (if you want the weapon to do damage that is, this field is not a requirement for a laser-type weapon) and don't forget to switch the damage type in [031] from 255 to a valid number. That combination should create a laser-type weapon without ammo or clips. Hope that's what you were looking for. --[[User:Zombie|Zombie]] 20:02, 4 October 2007 (PDT)

-----

That sounds about right. Thanks guys. :)

- [[User:Bomb Bloke|Bomb Bloke]] 20:10, 4 October 2007 (PDT)

----

For clipless weapons, it might be enough just to set the ''first'' clip type to xff/255 - the game then doesn't look for the 2nd and 3rd clip type. I think. I did that by accident and I didn't check it terribly rigorously. [[User:Spike|Spike]] 19:39, 22 November 2008 (CST)

== Damage Type Hacking ==

A lot of the damage type behaviour seems to be hardcoded. For example here was some of my experience. (Maybe I made some mistakes, please check for yourselves.)

* If you hack a ranged weapon's damage type to Stun, it automatically becomes a Stun Explosion (area effect), like the Small Launcher Stun Bomb. (Tested 4 weapons)
** (To implement a non-area ranged stun weapon, give it weapon power 5 so it will never affect outside its target square. Give it high ammo and low %TUs - fire continuously!)
* If you hack a non-IN weapon to IN, it doesn't create a fire effect. (Tested AutoCannon - but as a laser-style clipless weapons as per previous section)
* If you hack a Grenade to Stun, it still does normal damage (no Stun) and it still destroys objects on the ground

This is a shame because I wanted to implement a Flamethrower or Tank/Flamethrower - an Incendiary weapon with a weapon power of about 10 IN, but %TUs/shot of 1% and infinite ammo. Oh well! I guess I can still do it using AC-IN and giving it low %TUs, high ammo capacity.

On the other hand, these things work as expected:

* Hacking a non-IN ammo type to IN seems to work. So I could hack AC-AP, AC-HE to IN. Both started IN-type fires. The hacked AC-HE did not damage objects.
* I could hack AC-IN to AP and it did not retain any area affect (or fire effect).
* I could hack all HC- ammo types to Stun and they did not produce fire, nor damage to objects, nor permanent health damage.

So maybe only ''ammo'' types (not weapon types) are allowed to generate area effects? (apart from Stun, as discussed immediately above).

[[User:Spike|Spike]] 19:39, 22 November 2008 (CST)

:It would be real fun if the blaster bomb could be turned into a huge area-of-effect ''stun'' bomb. :) -[[User:MikeTheRed|MikeTheRed]] 13:22, 24 November 2008 (CST)

== Field 0x2D (45) ==

This field used by AI for "Worth to take" estimation (function at address .text:004043E0). This value meant to be ''max_distance+5''.

worthtotake = obdata_addr->field_2D;
...
return (worthtotake - xc_BF_Get_Distance(v_Selected_Unit_Xpos, v_Selected_Unit_Ypos,
a_ObPos_DAT[obj_num]->x, a_ObPos_DAT[obj_num]->y)) > 5;

I've patched ObData.Dat file (replaced all field_2d values of 0x01 with 0x10) and observed AI picking up dropped items. I don't know why this field was disabled, though I can presume it could be heavily used as "bait" like cheat because this estimation function cannot "skip" items if AI unit already has attacking weapons and clips (maybe this "taking" function ain't even called if unit is fully equiped - I didn't check that). Probably it wasn't finished... Which is weird. --[[User:Volutar|Volutar]] 08:07, 26 March 2011 (EDT)

:This is really good news that you found this function for aliens to pick things up . Finding a way to activate it could eliminate the silly problem of unarmed aliens who won't pick up weapons. You are right there is a risk of a "item bait" tactic being used. The trick would be to make sure that item pickup is only used by aliens who are unarmed or (better) for aliens who lack a weapon that is effective against X-Com, to pick up a weapon that ''is'' effective. [[User:Spike|Spike]] 17:28, 28 March 2011 (EDT)

As far as I tested it, this pickup function ain't used when alien have some attacking weapon. So there are no ways to use it as bait cheat. And actual code doesn't require any patching, only "obdata.dat" does. I wish to know the reasons why they made insufficient this "AI combat value" for attacking objects, because I don't see any. --[[User:Volutar|Volutar]] 21:59, 28 March 2011 (EDT)

:So if I understand correctly, if you set this ''worthtotake'' field to any value above 5, the alien will move to pick it up, if the alien is unarmed, and the (worthtotake of object - distance to object) is greater than 5? Excellent. [[User:Spike|Spike]] 15:19, 29 March 2011 (EDT)

If you set this field 10, maximum ''worth distance'' will be 5 (10-5), value of 20 will become 15 tiles (very valuable weapon, like blasterlauncher). Value of 5 will be ignored and 6 mean, alien willtake item only if he stands over it (occasionaly, or just dropped due to panic)...
The only presumable reason of disabling this AI feature is - it makes "panic unit" a bit obsolete, because there are small chances they won't take dropped weapon back...
Apart from this "worth distance" AI has another conditions for taking weapon from ground, so if you set this field to 200, they won't be ALWAYS running all over for weapon if they haven't one. When I set this field 10, about 70% of aliens were taken dropped weapons back at first turn, and about 90% at second...

:So two questions that come up are, 1, Who will do this mod?, and 2, what values to set?
:Seb76 has said that he "doesn't do" data file fixes in his Loader, which is a shame. That means that we would want to prevail on BladeFireLight, the new maintainer of XComUtil, to incorporate this fix into a release of XCU. I do think it's fair to consider this a bug fix, though fixing it also doubtless "makes the game harder" (another category for XCU mods). At the moment, a Panicked alien is almost your ideal result in combat, at least against weapon-only aliens, because they are permanently disarmed and harmless. You can then use them for target practice, capture them, do what you like with no risk.
:In my [[Talk:Alien_Inventory_Use#AI_Weapon_Preferences_Table|research on alien weapon preferences]], when their main weapon is missing or out of ammo, they select weapons out of their inventory more or less in priority of the base damage of the weapon (highest first). So it would be consistent, and simple, just to copy the base damage value into this field 24. Question: if there are multiple weapons out in the open, does the Alien go for the nearest one, regardless of the field 24 value, or will it go for a more distant weapon, if the 0x24 value is significantly higher? If there's no difference in behaviour, then it makes no difference, you might as well just set all the value to 0x10, as in your tests. If it does make a difference, then it might be best to set the 0x24 value to something like the Firepower Factor of the weapon, to help the Alien make the 'right' choice of weapon. Most of the time, the weapon with the highest base damage IS the best weapon to use against XCom, especially as XCom is often heavily armoured. It's not clear if the AI recognises that auto weapons and HE weapons are more effective than their base damage alone suggests. So you could tweak the 0x24 values to reflect that. [[User:Spike|Spike]] 06:15, 1 April 2011 (EDT)

:: If we can agree on the details of the fix, I can try to splice it into my Python-based editor suite. [[User:Zaimoni|Zaimoni]] 00:02, 2 April 2011 (CDT)

::: OK, well my initial suggestion would be use the standard damage, field 0x16 (decimal 22) of the weapon (or of the clip loaded into the weapon). These values would work well given that the ranking of 'most worthy' is done by dividing by range+1. That means the unarmed alien will go a little further to pick up a Blaster Launcher.
:::Valutar, does the code check whether the weapon is loaded or empty? If not, that might be one of the reasons the developers abandoned this code. Also, can you tell if the AI uses any modifiers in selecting a weapon to attack with from out of the alien's current inventory? Does it add some % for HE weapons, subtract some % for Stun weapons, add some % for Auto weapons? If the AI uses any rule like that for selecting a weapon to attack with out of its inventory, we should use the same rule for selecting a weapon to pick up off the ground. [[User:Spike|Spike]] 15:24, 2 April 2011 (EDT)

:::: So this needs balancing. At least the formula is known, so an educated guess can be made before testing, but I'm not sure how to do a reasonable test. [Ideally we'd use a borg, but the effort required to write one would be awesome.] [[User:Zaimoni|Zaimoni]] 00:33, 3 April 2011 (CDT)

Firstly it fills some buffer (maximum length is 50 elements) with items, having flag field (+0x0c) with bit1 set (& 0x02). Then it calculates most worthy item as maximum of ''worthToTake/(distance+1)''. And only after that it will try to pick this item up if distance is less than ''worthToTake-5''. So this value is matter when AI choosing object to pickup. And of course when AI sees some attacking options, it chooses most effective. When estimating grenade efectiveness it thinks that 1 friendly unit equal 2 enemy. So if there will be 1 friend with 2 enemies at very close distance, AI won't even try to blow them up.--[[User:Volutar|Volutar]] 12:55, 1 April 2011 (EDT)

Talk:OBDATA.DAT

2011-04-02T05:03:00Z

Zaimoni:

Talk:Accuracy formula

2011-04-02T04:55:17Z

Zaimoni:

From experience I think the chance of hitting an alien tends to be best if in an exact straight line (orthagonal or diagonal), and on the same level as it. This probably is explained by the misses that hit anyway, because you can miss slightly short and kneecap them, or long and hit them in the face, but I think this is less likely if you are at an oblique or acute angle (because there are less squares that are behind him you can scatter to, but still hit him - especially as you get further and further away so the aliens width becomes less of a factor). Equally with height, the further up you are, the less squares the fire can scatter to but still intersect with the alien.

Does this match up with other peoples experiences?

--[[User:Sfnhltb|Sfnhltb]] 12:59, 27 February 2007 (PST)

-----

Hmm, I'm not sure what I'd say. In theory the "silhouette" wouldn't change much, if the angle were not a multiple of 45 degrees (that's what you mean, right?). I'm willing to bet that the engine is more influenced by things that might truncate values here and there, than anything else. And/or the interaction with exactly how they "draw" the "3D" target that the shot's trying to intersect. I'm sure it's crude but effective... but crude in what ways? shrug. - [[User:MikeTheRed|MikeTheRed]] 15:50, 28 February 2007 (PST)

----

Does the accuracy displayed in-game for the auto-fire apply to each individual shot or to all three shots?

: It applies to each individual shot. -[[User:NKF|NKF]] 22:39, 1 December 2008 (CST)

:: Indeed. Note that the displayed "chance to hit" isn't really your ''chance to hit''... It's more a measurement of the ranges of angles you can fire along. - [[User:Bomb Bloke|Bomb Bloke]] 00:37, 2 December 2008 (CST)

::: In Laser Squad Nemesis, that is explicit - units have a stat called "inaccuracy", defined as "The average deviation from true for a weapon shot, in degrees." Has anyone made tests in X-Com, what is the relation of distance to target and displayed and actual chance to hit? - Quantifier 05:14, 2 December 2008 (CST)

::::[[User_talk:Bomb_Bloke#Firing_Accuracy|Yes, this has been done.]] [[User:Arrow Quivershaft|Arrow Quivershaft]] 08:49, 2 December 2008 (CST)

: As in "spread" of your shots, BB? Where bigger spread means, less accurate? -[[User:MikeTheRed|MikeTheRed]] 04:15, 2 December 2008 (CST)

----

What, exactly, happens when you miss? Does the game shift your aim by pivoting around the fire point or actually pick a random location in 3D that's close'ish to the target? It seems to me like it's the latter due to your ability to miss and shoot the ground right at your feet when shooting at nearby aliens. This doesn't seem to happen for farther away targets. Would this then suggest that aiming behind your target could potentially result in more hits on target due to more "misses" hitting? I haven't tried this tactic in practice.

:This is one of the unanswered questions, but the working hypothesis is that there is no specific hit/miss determination. That is, the game engine just fires the shot and introduces a random angular error. The maximum angular error is inversely proportional to the adjusted Chance to Hit. If the angular error is wide enough, the path of the shot no longer intersects the silhouette of the target defined by LOFTEMPS. Horizontal angular error seems to be greater than vertical angular error. But, most of this is conjecture. I was talking to Mike The Red about doing some histograms, analysing multiple shots with a wall of some vertical "destructible terrain" positioned behind a target. But we did not make any progress on that. [[User:Spike|Spike]] 14:13, 1 April 2011 (EDT)

:: Seb76 has obtained the firing point from the executable. I have a reverse-engineering of the horizontal angle the game pivots around the fire point (cf. [[User_talk:Bomb_Bloke:Firing_Accuracy]]), but I haven't been able to convince Bomb Bloke that it's completely correct. (We disagree on how my formula graphs. It does exactly match the extreme bounds by construction.) I am getting empirically correct predictions in-game combining my horizontal accuracy formula with [[Blind_Spots_From_First_Principles]]. It's very nice being able to directly calculate the best possible ambush locations in a landed Supply ship :) [[User:Zaimoni|Zaimoni]] 23:51, April 1, 2011 (CDT)

Talk:Damage

2011-01-31T07:29:57Z

Zaimoni:

I remember reading in a thread somewhere, that weapons do up to double damage at all times, not just on X-COM soldiers. This means that the rated in-game values are actually the averages. I think it was in Zombie's "[http://www.strategycore.co.uk/forums/index.php?s=c04cf11b996e56f4020a526d9964a895&showtopic=746 Damage Modifiers]" thread. Can anyone confirm or deny this, because the formula at the top of the page, with the 0.5 and 2 in it, is confusing to me?

In my understanding, it was simply like this:

A rifle, rated as 30 damage, will actually do anywhere from 0-60 damage. Then you multiply this by the [[Damage Formula#Damage Modifiers|damage modifiers]] and then subtract the armour...

--[[User:Danial|Danial]] 18:08, 23 Oct 2005 (PDT)
----

That's the impression I'm getting from what I've seen... that actually it's the average that's being shown in the game. So I'm with you. Want to ask Zombie? Or I can. --[[User:MikeTheRed|MikeTheRed]] 11:17, 24 Oct 2005 (PDT)

----

Exactly correct guys. All damage numbers listed by the game's UFOpaedia are averages. I believe I mentioned this fact in my 3rd or 4th post in the Damage Modifiers thread at the StrategyCore forums. For most weapons/ammo, the Minimum is 0 and the Maximum is Average * 2. The weapons/ammo in this category include Armor Piercing, Laser, Plasma, Stun Rod and the Small Launcher's Stun Bomb.

The types of ammo that don't quite follow that category are Incendiary and High Explosives. The HE Minimum is AVE/2, while the Maximum is AVE*3/2. However, if you average the min and the max, it is still what the game mentions. Overall, it's a smaller range of damage that can be inflicted, and that means the probability of the higher damages showing up is greater than an ammo with the same max.

'''Example 1:'''

HE ammo with 100 listed strength
Min = 50
Ave = 100
Max = 150
Probability of max showing up = 1/(150-50+1) = 0.990%

AP ammo with 75 listed strength
Min = 0
Ave = 75
Max = 150
Probability of max showing up = 1/(150-0+1) = 0.662%
Conclusion: if you have the choice between HE with 100 listed damage and a normal weapon with 75, choose the HE. However, if you have two types of ammo with the same average, things become different.

'''Example 2:'''

HE ammo with 100 listed strength
Min = 50
Ave = 100
Max = 150
Probability of max showing up = 1/(150-50+1) = 0.990%

AP ammo with 100 listed strength
Min = 0
Ave = 100
Max = 200
Probability of max showing up = 1/(200-0+1) = 0.498%

Unfortunately, we are comparing apples to oranges in this case since the max for the AP is much greater than HE. In reality, AP ammo will out-perform the HE according to this: 1 / (AP max - HE Max + 1), or 1 / (200-150+1) = 1.961%. That's almost double the HE doing it's max of 0.990%. By this you would be tempted to outfit all your troopers with AP instead of HE with the same listed damage. But wait. HE will actually out-perform AP according to this: 1 / (HE min - AP min + 1), or 1 / (50-0+1) = 1.961%.

Conclusion: Is either ammo better? Nope, it's a crap-shoot. The probability of the AP under-performing the HE's min negates its probability of out-performing the HE's max. But there is one fact than still remains: the HE always does a minimum damage > 0, and it's damage affects an area instead of a single tile. This might be beneficial to soldiers since every shot that connects (or even falls a bit short) will damage the target.

Incendiary weapon strength is theorized to determine the area of flames, not the damage inflicted. Damage for that type is either 0 or between 5 and 10 depending if the unit catches fire, or between 1 and 12 if the unit is standing in fire. Hope this helps. --[[User:Zombie|Zombie]] 15:06, 24 Oct 2005 (PDT)

----

Great stuff, Z! Thanks for clarifying. Danial or I will move this to the Damage Formula page soon. It's great to have sweeping generalities in black and white :) -[[User:MikeTheRed|MikeTheRed]] 17:39, 24 Oct 2005 (PDT)

== Melee damage ranges ==

What's the damage range used for melee attacks (stun rods/alien terrorists)? 0 to x2, x0.5 to x1.5, or something else?--[[User:Ethereal Cereal|Ethereal Cereal]] 00:36, 14 March 2007 (PDT)

----
For Stun Rods and HTH alien attacks the range is 0-2x.--[[User:Zombie|Zombie]] 08:45, 14 March 2007 (PDT)

== Cool Table, Zombie ==

Thanks so much for making the time to put that there. It must have taken some tweaking.

To me, though, the mind's eye notices differences more quickly. Which is to say, here, to have made all the 100s be "-" and then the rest be +20 or -10 or whatever.

Just a thought. Please delete this after reading it! - [[User:MikeTheRed|MikeTheRed]] 00:14, 6 July 2007 (PDT)

== Probabilities ==

So weapons may do anything from zero to twice their nominal damage. I have the impression that this isn't totally random, but sort of a bell-curvish distribution. Laser Rifle vs Floater should require two hits about 1/3rd of the time and it feels as if one-shot kills were a lot more common. However, I don't have any actual data to back this up.

Also, can it be that the soldier's firing accuracy does matter? That good marksmen not only have a higher to-hit chance to begin with, but also receive a bonus on their damage roll? --[[User:Schnobs|Schnobs]] 18:45, 10 November 2007 (PST)

== Typo in damage modifiers table ==

Looks like there is a typo in the table for incendiary damage against personal armor. 0 is listed while it should be 80. I spotted this one, there might be others. Here is the raw data I have:

.data:0046DE58 damageModifierAP dw 64h,64h,64h,64h,64h,64h,64h,3Ch,64h,64h,64h,64h,50h,3Ch; 0
.data:0046DE74 damageModifierIncendiary dw 64h,64h,50h, 0,28h,46h,46h,64h, 0,50h,0AAh,64h,64h,64h; 0
.data:0046DE90 damageModifierHE dw 64h,64h,64h,64h,4Bh,64h,64h,64h,82h,64h,64h,50h,3Ch,50h; 0
.data:0046DEAC damageModifierLaser dw 64h,64h,64h,64h,64h,64h,64h,64h,64h,64h,64h,96h,64h,46h; 0
.data:0046DEC8 damageModifierPlasma dw 64h,64h,64h,64h,64h,64h,64h,64h,64h,64h,64h,50h,64h,46h; 0
.data:0046DEE4 damageModifierStun dw 64h,64h,5Ah,50h,64h,64h,50h,64h,64h,5Ah,64h,64h,64h, 0; 0
.data:0046DF00 damageModifierMelee dw 64h,78h,64h,64h,5Ah,64h,64h,64h,64h,64h,64h,64h,64h,64h; 0
.data:0046DF1C damageModifierAcidSpit dw 64h,0A0h,6Eh,64h,28h,64h,64h,64h,64h,64h,64h,64h,64h,64h; 0

:I've personally stood my soldiers in personal armor in flames without them taking any damage. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:16, 9 February 2008 (PST)

The damage modifiers from the executable are correct, it's just that certain armor types override those values. For instance, Personal Armor is listed at 80% against incendiary in the executable, but in real-life situations soldiers wearing this armor type are completely safe from fire. I suppose we should make a note of this. --[[User:Zombie|Zombie]] 21:33, 13 February 2008 (PST)

== Damage Doubling ==

Sirgalahadwizard's last edit got me wondering:

{| {{StdDescTable}}
|-
|(edit: In TFTD, the listed weapon damage in the UFOpaedia is still the average damage caused, but the difference from UFO is that random weapon damage is rolled twice and averaged, which produces values which are more often closer to the average)
|}

Doesn't that just result in the same thing? I mean, it still results in damage being anywhere between 0 - 200%. Even in UFO, most of the damage does tends to fall somewhere along the average.

However, it has got me wondering about how the number is actually doubled. I don't think we've ever chronicled how UFO doubles the damage. Whether it's doubled by rolling a random number and feeding the doubled damaged as the range for the random value, or like the one mentioned: rolled twice, added up and then halved.

- [[User:NKF|NKF]] 21:53, 13 March 2008 (PDT)

:Statistically, the more dice you roll, the closer you'll get to the average. Take a d6. Rolling 1d6, you have an equal chance of getting any value, 1-6. With 2d6, you have 36 different combos, of which nearly half of them (16) are 6, 7, or 8, all right in the middle. Whereas the chances of getting a 2 or 12 are only 1 in 36 each! So no, they aren't the same; rolling twice means that, statistically, you'll get values in the middle far more often than outliers.

:As for how damage was calculated...I think it multiplies the average by a random interger between 0 and 2, with decimals out to hundereths. Or something along those lines. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:57, 13 March 2008 (PDT)

:: Oh, no question about the difference in value distribution of the two methods. I just meant that either method still allows for values between 0 to 200%. I'm just wondering what the game actually uses and to find out if UFO uses a different method from TFTD. - [[User:NKF|NKF]] 22:38, 13 March 2008 (PDT)

:That, I have no idea on. Sorry. I'd actually suspect that the method used is the same...TFTD was just a quick skin change of UFO. Very little actual code got changed, they just played around with the number bits for stats to change stuff. And the names and graphics, obviously. The thicker skin(higher armor) of the TFTD aliens may mask this, though. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:46, 13 March 2008 (PDT)
----
One thing I'm not clear on from reading the above is whether the damage roll for UFO Defense is rolled once or twice. In other words, is it linear or bell-curved. Sounds like we believe TFTD is rolled twice and averaged, and it does seem reasonable to suppose that UFO is also rolled twice since it's substantially the same game engine. Can anyone provide any more information? I'm trying to get an exact formula for effective average damage vs armourin UFO Defence, so I need to know if the function is linear or gaussian, and if gaussian, how many rolls. Also do we know what the range & granularity is. E.g. is it 0% to 100% in units of 1%, or 0 to maximum damage in units of 1, etc? [[User:Spike|Spike]] 07:02, 5 April 2008 (PDT)

: [[User:Zombie|Zombie]] has explicitly verified that the damage roll for UFO Defense is only once. Also, the result of rolling twice and averaging is pretty much a right triangle, not a bell curve. [Not exactly, because of integer truncation; there are three ways to roll zero but only one way to roll maximum, for instance.] -- [[User:Zaimoni|Zaimoni]] 13:38, 6 Apr 2008 (CDT)

: In contrast: rolling twice, and then adding, is as close to a right triangle as a discrete probability distribution can get. -- [[User:Zaimoni|Zaimoni]] 16:10, 6 Apr 2008 (CDT)

Thank you Zaimoni. And what about the rolled range and steps? Is is e.g. 0.00 - 2.00 x Average, or (zero) to (2 * Average) in integer steps, or ? That's probably a hard thing to deduce, it might need code inspection. [[User:Spike|Spike]] 11:54, 7 April 2008 (PDT)

: I think I identified the code for this. Standard damage goes like this:
.text:0040DF58 66 8B 0D E8 83 47 00 mov cx, currentWeapon_damage
.text:0040DF5F 66 D1 E1 shl cx, 1
.text:0040DF62 51 push ecx ; rndMax
.text:0040DF63 E8 E8 F8 02 00 call GetRandom_0_n
.text:0040DF68 83 C4 04 add esp, 4
.text:0040DF6B 8B C8 mov ecx, eax
: which means damage*2*rand()
: For HE damage:
.text:0040DF36 66 A1 E8 83 47 00 mov ax, currentWeapon_damage
.text:0040DF3C 50 push eax ; rndMax
.text:0040DF3D E8 0E F9 02 00 call GetRandom_0_n
.text:0040DF42 66 8B C8 mov cx, ax
.text:0040DF45 83 C4 04 add esp, 4
.text:0040DF48 0F BF 05 E8 83 47 00 movsx eax, currentWeapon_damage
.text:0040DF4F 99 cdq
.text:0040DF50 2B C2 sub eax, edx
.text:0040DF52 D1 F8 sar eax, 1
.text:0040DF54 03 C8 add ecx, eax
: which is damage*rand()+damage/2
: rand() is base on a linear congruent generator:
.text:0045FA65 A1 58 68 47 00 mov eax, rand_internal_state
.text:0045FA6A 69 C0 FD 43 03 00 imul eax, 214013
.text:0045FA70 05 C3 9E 26 00 add eax, 2531011
.text:0045FA75 A3 58 68 47 00 mov rand_internal_state, eax
.text:0045FA7A C1 F8 10 sar eax, 10h
.text:0045FA7D 25 FF 7F 00 00 and eax, 7FFFh
.text:0045FA82 C3 retn
: (For the curious, it is the [http://en.wikipedia.org/wiki/Linear_congruential_generator#LCGs_in_common_use Microsoft Visual/Quick C/C++ version])). HTH. [[User:Seb76|Seb76]] 13:06, 7 April 2008 (PDT)

== Acid Spit Damage Range? ==

An obscure question, but what's the damage range for Acid Spit? Is it a 0-2 or a 0.5-1.5, or ??? My spreadsheet of Battlescape weapons & attacks is nearly complete, I just need to get the Celatid attach right. [[User:Spike|Spike]] 15:09, 5 September 2008 (PDT)

:Celatid Acid spit operates on the same damage as a normal weapon. 0-2. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:35, 5 September 2008 (PDT)

== TFTD Damage rolls ==

Can someone confirm that in TFTD, the damage multiplier is rolled twice and averaged?
If so, this will have a big impact (upwards) on the effectiveness of armour in TFTD, particularly when the armour level is greater than the average damage of a given weapon.

Also, does the doubling-rolling also aply to HE, or just for weapons? [[User:Spike|Spike]] 13:25, 8 October 2008 (CDT)

:In all honesty, I suspect not. That'd be a bit of a complex change for the otherwise hacked-out mod of UFO. So I really suspect there is no difference; IMO, that was idle conjecture based on an incorrect edit. As it currently stands, I'd say treat TFTD damage calculations as identical to UFO damage calculations up until we find conclusive evidence to the contrary. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:22, 8 October 2008 (CDT)

::Great news, otherwise the weapon vs armour damage averages are fiendish to calculate. That means I can use my TFTD weapon firepower analysis pretty much as is. Time to format it up! [[User:Spike|Spike]] 17:08, 8 October 2008 (CDT)

== Incendiary vs. Sectopod ==

Does Incendiary damage mean that it is a plausibly useful technique to hit 3 sectopods with a Incendiary rocket... then have some team members auto-fire incendiary rounds into the ground? I haven't had a chance to test this out yet, but I'm considering giving it a shot... [[User:Jasonred|Jasonred]] 03:48, 6 March 2009 (CST

: The sectopods will behave the same as any other alien with respect to the mystery incendiary impact-damage pops. Unfortunately, they have heaps of health. Then again, let's assume that all four segments are affected independently... well then it may just be a viable strategy. Give it a shot (or several - as the case may be!) against them anyway. -[[User:NKF|NKF]] 04:18, 6 March 2009 (CST)

:: I'm sure the incendiary exploit would work, but there's not much honour in exploiting such an illogical bug. Standing in a corner autofiring AC-IN into a bush, and watching Sectopods die on the other side of the map? It's a bit silly. Having said that, if you did it in a non-exploit way, just firing incendiaries at one Sectopod at a time until each one died, that would be cool. A similar thing happened to me. I was running tests where the aliens were trying to shoot me using every possible weapon. I had amped all the armour levels of my guys up to 255 all over and under (a bit like a Sectopod). The only thing that killed me was the incendiary rounds.

::[[User:Spike|Spike]] 04:30, 6 March 2009 (CST)

== Vertical Damage==
Oh yes, one more thing... when shooting from directly underneath a target, can you hit under armor? Or would you still hit front/read/side armor? [[User:Jasonred|Jasonred]] 03:48, 6 March 2009 (CST)

: As for hitting from underneath: It's directional I'm afraid. -[[User:NKF|NKF]] 04:18, 6 March 2009 (CST)

:: Does seem strange that you don't hit under armour even if the target is directly above you, and you are both in the (horizontal) centre of the square. If it does not hit Under armour, what side does it hit? How can it possibly calculate / know which side, or whether it's "front"? That doesn't really make sense?

::[[User:Spike|Spike]] 04:30, 6 March 2009 (CST)

:: Easy to see which side it hits... just check which armor is damaged! Penetrating shots always damage armor, IIRC. [[User:Jasonred|Jasonred]] 05:41, 6 March 2009 (CST)

::: What I mean is, how does the game engine ''determine'' which side/front ''will be'' damaged. If the shooter and the target have exactly the same X and Y coordinates, and differ only in Z, there is no way to calculate if the shooter is 'in front of' or 'at (a) side of' the target - it's meaningless. Maybe the firing position is offset from the dead centre of the square. Or they might effectively project the shooter and target back away from each other along the axis they are facing. That might work. But it still wouldn't make sense. I wonder why they gave Floaters such high Under armour if it's impossible to hit the Under armour when they are in the air? [[User:Spike|Spike]] 06:24, 6 March 2009 (CST)

I think the answer to this may be fairly simple. For basic non-explosive attacks, compass directions may be the key. The direction the shooter facing is compared against the recipient's facing. If shooter is facing north and receiver is facing east, then the recipient's right plates get damaged. If both are facing north, then the recipient gets hit in the back.

Obviously, for explosive attacks, it's based on the direction the target is facing away from ground-zero and (for whether it hits under or directional armour ) how far away it is from it.

You have to be facing a particular direction even if you are standing on the same tile's x/y coordinates - and since there's no upward facing, it'll be in one of the 8 compass directions. I guess the next question is: How is your firing angle determined when you're firing a vertical shot? -[[User:NKF|NKF]] 06:48, 6 March 2009 (CST)

: I'm sure you're right about it being determined by facing. It's the easy way to do it, and actually works when you are on the same level so it would be impressive if they wrote code that could handle the vertical case. It leads to the tactical tip that if you are attacking someone from directly above or below, face the same way as them, to hit their rear armour. It also leads to the slightly odd situation where 2 opponents on the same map square, facing the same way, are both firing into each other's rear armour. :) [[User:Spike|Spike]] 07:03, 6 March 2009 (CST)

Recall that when you fire in true vertical directions, your soldier is only able to shoot when facing to the North West. So there is no way you would be able to control where the hits actually go. --[[User:Zombie|Zombie]] 09:41, 6 March 2009 (CST)

== Armour Damage (armour reduction) mechanics? ==

It's not clear to me from the main article, how damage ''to'' Armour works, i.e. how Armour levels are reduced by damage. The section on Armour vs. Health Damage sort of implies the answer. It talks about Armour Damage as if this was equivalent to Penetrating Damage. In fact, I suspect Penetrating Damage would be a better term to use in that section (maybe rename it too). Let me restate my understanding, please check if this is correct.

*Non-penetrating damage, i.e. any damage less than or equal to the current Armour level, has no effect on armour level (or Health)
*"Penetrating Damage" means the amount by which (final, modified) damage exceeds the current Armour level on the affected facing
<s>*Each point of Penetrating Damage causes 1 point of permanent damage (reduction) to Armour level (on that facing)</s>
**Of course the Armour level on a facing can't be reduced below zero
<s>*N points of Penetrating Damage causes (N-1) * 10 + 1-9 points of Health Damage (reduction) (where N > 0)</s>

And when we get this clarified, my follow up question will be, "Do ''all'' damage types (e.g. Stun, HE) reduce armour in the same way?"

[[User:Spike|Spike]] 04:52, 30 January 2011 (EST)

: These deeply technical articles aren't really my forte, but I always thought the formula '''Armor Damage = INT( Health Damage / 10 ) + 1''' followed by the table succinctly describes how much armour is damaged depending on how much penetrating damage is dealt. It could certainly be rewritten or summarized for clarity.

: Most direct damage types should follow the armour damage model. Stun doesn't damage armour. Fire doesn't either, not its initial impact damage or its persistent damage. I verified that on an unarmoured rookie, having only 5 back and 2 under armour. While testing that I discovered that units on fire but not standing in a fire patch are also affected by the incendiary 'hit-everything-in-fire' bug. -[[User:NKF|NKF]] 05:59, 30 January 2011 (EST)

:: Thanks NKF. I will rewrite the main section so that it's more clear to me - and hopefully to others. I will leave in that formula, since it seems succinct to you. Cheers [[User:Spike|Spike]] 08:13, 30 January 2011 (EST)

== Effect of Armour Degradation on TUs-To-Kill ==

The section above was prompted by thinking about the best weapons for attacking Lobstermen. It also made me think that to ''correctly'' model using weapons against Lobstermen, or anything else that is really hard to kill, you have to model the progressive degradation of their armour under prolonged, sustained attack. Luckily they don't tend to change facing much during active combat. This would particularly affect my "TUs to Kill" metric, which currently doesn't assume any armour degradation while trying to kill (the same) target.

Assuming the target isn't moving around too much but is presenting the same facing, and assuming none of the attackers are able to flank the target to attack a different facing...

In the case of a more effective weapon, typically armour reduction will be equal to, or slightly greater than, ( target's total Health / 10). So a target with 100 Health is not going to lose a lot more than 10 Armour during the process of dying.

I guess if we take the case with a weak, borderline-effective weapon, where killing the target takes a l-o-n-g time, each penetrating hit reduces armour level by one. It's conceivable (unlikely) that the target's Armour could be reduced by as much as it's total Health, before it dies. Of course, the more the target's armour degrades, the less likely that scenario becomes.

Calculating the effect on target survivability vs a specific weapon (TUs-to-Kill) is difficult because this is a non linear function. Each reduction in Armour level makes the target easier to kill. I don't think I have the mathematical brainpower to model it correctly, with a derivative. Even this would only be an approximation, because of all the integer rounding. So to get the right number, you would need to solve it iteratively, with an algorithm. I'd be interested to do that, just to see how much of a difference it makes.

My instinct, from experience, is that it does make a difference. For example, in theory GC-HE is almost useless against Lobstermen, but if you persist at it, and everyone fires loads of rounds, it is do-able and "easier than it ought to be". Paricularly if you soften them up with Sonic Pulsers first. And of course, wherever you fire from, you're targeting the same armour facing - Under Armour - with all your weapons, which is much more efficient than spreading damage across multiple facings of the target.

[[User:Spike|Spike]] 09:04, 30 January 2011 (EST)

: I hammered together a quick C++ program to simulate GC-HE damage against a lobsterman. I've gone over the formulas a couple of times and it seems to be working fine. Here are 3 samples of the various results I got.

<pre>
Lobsterman Soldier
Health: 90
Armour: 10
HE resist: 30%
HE Weapon average strength: 65

Dumping results:

Pass 1: HP: 88 ARM: 9 WPN Dmg: 43 WPN P. Dmg: 2 ARM Dmg: 1
Pass 2: HP: 88 ARM: 9 WPN Dmg: 33 WPN P. Dmg: 0 ARM Dmg: 0
Pass 3: HP: 73 ARM: 7 WPN Dmg: 80 WPN P. Dmg: 15 ARM Dmg: 2
Pass 4: HP: 68 ARM: 6 WPN Dmg: 42 WPN P. Dmg: 5 ARM Dmg: 1
Pass 5: HP: 58 ARM: 4 WPN Dmg: 55 WPN P. Dmg: 10 ARM Dmg: 2
Pass 6: HP: 40 ARM: 2 WPN Dmg: 76 WPN P. Dmg: 18 ARM Dmg: 2
Pass 7: HP: 30 ARM: 0 WPN Dmg: 40 WPN P. Dmg: 10 ARM Dmg: 2
Pass 8: HP: 14 ARM: 0 WPN Dmg: 54 WPN P. Dmg: 16 ARM Dmg: 2
Pass 9: HP: -9 ARM: 0 WPN Dmg: 79 WPN P. Dmg: 23 ARM Dmg: 3
</pre>

<pre>
Lobsterman Soldier
Health: 90
Armour: 10
HE resist: 30%
HE Weapon average strength: 65

Dumping results:

Pass 1: HP: 82 ARM: 9 WPN Dmg: 63 WPN P. Dmg: 8 ARM Dmg: 1
Pass 2: HP: 69 ARM: 7 WPN Dmg: 76 WPN P. Dmg: 13 ARM Dmg: 2
Pass 3: HP: 51 ARM: 5 WPN Dmg: 85 WPN P. Dmg: 18 ARM Dmg: 2
Pass 4: HP: 31 ARM: 2 WPN Dmg: 86 WPN P. Dmg: 20 ARM Dmg: 3
Pass 5: HP: 21 ARM: 0 WPN Dmg: 42 WPN P. Dmg: 10 ARM Dmg: 2
Pass 6: HP: 3 ARM: 0 WPN Dmg: 60 WPN P. Dmg: 18 ARM Dmg: 2
Pass 7: HP:-23 ARM: 0 WPN Dmg: 89 WPN P. Dmg: 26 ARM Dmg: 3
</pre>

<pre>
Lobsterman Soldier
Health: 90
Armour: 10
HE resist: 30%
HE Weapon average strength: 65

Dumping results:

Pass 1: HP: 83 ARM: 9 WPN Dmg: 59 WPN P. Dmg: 7 ARM Dmg: 1
Pass 2: HP: 66 ARM: 7 WPN Dmg: 89 WPN P. Dmg: 17 ARM Dmg: 2
Pass 3: HP: 48 ARM: 5 WPN Dmg: 86 WPN P. Dmg: 18 ARM Dmg: 2
Pass 4: HP: 33 ARM: 3 WPN Dmg: 69 WPN P. Dmg: 15 ARM Dmg: 2
Pass 5: HP: 9 ARM: 0 WPN Dmg: 92 WPN P. Dmg: 24 ARM Dmg: 3
Pass 6: HP:-13 ARM: 0 WPN Dmg: 76 WPN P. Dmg: 22 ARM Dmg: 3
</pre>

: I ran this over and over and 5 shots seems to be the lowest and 10 shots the most to take this lobsterman down. -[[User:NKF|NKF]] 18:09, 30 January 2011 (EST)

:: Ah, great stuff! I can picture the determined squad of Aquanauts, firing repeatedly and focusing all their fire on a lone Lobsterman, until he goes down. Nice. From experience of doing this - the biggest problem is carrying enough GC-HE ammunition to finish the mission. Thanks for modelling it, NKF. [[User:Spike|Spike]] 22:01, 30 January 2011 (EST)

:: I had to augment XCOM1.py to handle this. Ignoring stunning and assuming I have things entered correctly (I distrust both the exact HE damage distribution before damage reduction, and the exact damage reduction implementation), the absolute mininum number of HE rounds needed to kill a lobsterman is 4 with theoretical probability 2/3,570,125 of success (less than 1 in a million). Corresponding theoretical probability of surviving ten hits is ~0.24%.

:: These numbers assume that the theoretical HE distribution is a uniform discrete distribution with range 33-97 [INT(65/2)=32], and that the damage reduction is implemented as a truncating multiply INT(3*damage/10). Note that raw high explosive damage 36 is reduced to damage 10. -- [[User:Zaimoni|Zaimoni]] 1:23, 31 January 2011 (CST)

::: Also, unless exceptional care was taken in choosing the RNG (Mother-of-All was on USENET by then), there will be enough correlation to keep the lobsterman from being awesomely lucky. -- [[User:Zaimoni|Zaimoni]] 1:29, 31 January 2011 (CST)

Talk:Damage

2011-01-31T07:24:43Z

Zaimoni:

User talk:Bomb Bloke:Firing Accuracy

2011-01-01T11:04:55Z

Zaimoni:

{{tocright}}Consider this [[User:Bomb Bloke|Bomb Bloke's]] draft/discussion about firing accuracy. This topic has been dragging on for quite some time now, so I figure it to about time I had a stab at it.

My view on the matter is this: When you fire a gun, UFO works out the horizontal and vertical angles between your unit and the target, then modifies these depending on your [[Accuracy_formula|overall accuracy stat]].

Say for example you have a perfect 100% (or better) "accuracy". The lines are nearly unmodified, and so near guaranteed to hit (assuming there are no obstructions, in which case you should get a "No LOF!" message when you attempt to fire. Note that the game doesn't ALWAYS give this message and will sometimes allow you to attempt "impossible" shots. In these cases, less-then-perfect aim might still allow the shot to land).

As your rated accuracy decreases, target size and distance become all important: As size decreases and distance increases, the range of angles that could land a hit fall. As accuracy decreases, the range of angles that a shot can take rises and so it becomes less likely that a given shot will fall within the "hitting" range of angles.

(As for why multiple angles can "hit", think of your target as a dartboard: Perfect aim would result in a bullseye, approximate aim would still hit the board, and bad aim would miss altogether. However, in X-Com, you get full "points" so long as the bullet hits the target at all).

That is to say, the ultimate firing accuracy formula would be (range of acceptable hitting angles)/(range of possible firing angles). Assuming, of course, that when firing you're just as likely to fire at your maximum "worst" angle as you are your "best", the range of angles that can hit is determined by target distance and size, and the range of angles that can be fired along is determined by your rated firing accuracy.

However, as it turns out, the angle your shots take isn't entirely random - they follow a bell curve. You're more likely to at least hit near the target then you are to get a massive "air ball" shot. So the formula in truth will end up looking a bit more complex then that.

== Firing Point Origin ==

To get the absolute range of angles a unit can fire along, you first need to know where a unit is firing from. To this end I created a copy of my game folder and modified a save game, some terrain files, and the LOF templates.

[[image:BBFiringPointTest2.png|right|thumb|200px|A basic map of a tile. As it turns out the Y axis really points the other way.]]Now, when we talk about UFO maps, we generally refer to their dimensions in terms of how many tiles there are. However, each tile is really made up of smaller "points": A 16x16x24 point space. This means that a 30x30x4 map has 3,600 tiles in it, and 22,118,400 points within those. When a unit fires, he doesn't aim from his tile at his target's tile, he aims from a point within his tile at a point within his target's tile.

This first test was aimed at discovering exactly where a shot originates from, by creating tiles on units to selectively block their LOF. By seeing which tiles did and which did not, it could be seen exactly (or, at least, as accurately as I think I'm going to get it) where the shots were coming from.

[[image:BBFiringPointTest3.png|right|thumb|200px|The Empire's got nothing on BB's clone army.]]The first row of units served as targets for the second, which stood on tiles similar to the large earth blocks you see in bases but with one layer removed from each. Each therefore entirely blocked LOF so long as the removed layer wasn't at the same height as the unit's firing origin point. The only unit able to fire through the gap was the one sitting on the tile with the third layer down removed.

However, when defining tiles with [[LOFTEMPS.DAT|LOFTemps]], you can only stack the layers 12 high. Presumably the game "double stacks" them to make the resulting 24 point high object. Because of this, the removed layers accounted for two possible Z co-ordinates, meaning the exact value there is still unknown. Might be able to work something out to get it more precise, I dunno.

The third row stood on walls facing to the east/west. Unlike the second row, in this example I moved a single thin wall through each tile, as opposed to moving a "gap". This meant that only one unit would not be able to fire, and that was the one sitting on the ninth tile (made up of my layers from LOFTemps[15]).

[[image:BBFiringPointTest1.png|right|thumb|200px|LOFtemps used, as opposed to the [[LOFTEMPS.DAT|usual set]].]]The forth row followed more or less the same concept, with the walls facing north/south. Only the first unit was unable to fire (LOFTemps[23]).

So! With this information, getting a (x,y,z) co-oridinate is easy enough: It's either (8,15,18) or (8,15,19) (the Z co-ord being imprecise due to the 12 LOFTemp layer limitation).

Note that this value only goes for units with a facing of north. When I get time I'll go through and work it out for the other directions. Furthermore, Sectoids are likely to have a lower firing point (as their guns are rendered lower on the screen).

----

[[Image:origins.png|frame]]

I found an interesting piece of code (offset 40D8E0 for the curious). The formula for the starting zpos when firing looks like this:
''unitpos.zpos*24+unitref.terrain_height-unitref.standing_height+27-unitref.floating_height''
and for kneeling units:
''unitpos.zpos*24+unitref.terrain_height-unitref.kneeling_height+27-unitref.floating_height''
(unitref.terrain_height is offset 0x27 in unitref.dat)
I did a live check with a debugger, for a standing unit on the lowest level it gives this:
''3*24+0-16+27-0=77''
Since the engine seems to use zpos=0 for the ceiling of the topmost level, then the floor must be at offset 4*24=96. floor_level-firing_level=96-77=19, in accord with your empirical results.

Now for xpos and ypos, the engine uses several tables, indexed by the facing orientation (offset 0xa in unitref.dat):
''.data:0046B5E4 dw 8,0Eh,0Fh,0Fh, 8, 1, 1, 1''
for xpos, and
''.data:0046B5C4 dw 1, 1, 8,0Fh,0Fh,0Fh, 8, 1''
for ypos. When facing north, the shot should come from 8x1x19. Note that it is in disaccord with your experience. Maybe you don't use the same point of origin as the engine? [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

You are correct. Moving my origin to match yours brings my data into line (I was limited to guessing it's correct location). Awesome to see the ceiling size confirmed at long last. :D - [[User:Bomb Bloke|Bomb Bloke]] 02:52, 8 May 2008 (PDT)

----

Big units use 2 other tables located at offsets 46B604 and 46B624. I did not try to change these values to see if it changes the position where the shots come from. [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

The xpos/ypos information agrees with my own in vivo research (it explains several LOS different than LOF paradoxes I have explicitly verified). -- [[User:Zaimoni|Zaimoni]] 11:49, 3 May 2008 (CDT)

== Rated Accuracy Vs Angle Range ==

[[image:BBFiringPointTest4.png|thumb|200px]][[image:BBFiringPointTest5.png|thumb|200px]]Just a few results before I go off camping for the weekend. First off, note that [http://www.strategycore.co.uk/forums/index.php?act=ST&f=22&t=5805 the logger] used on this occasion is one I wrote up a year ago. It's not entirely accurate, and needs to approximate values (this is because I can only get it to think in terms of angles between tiles, as opposed to angles between points - as a result you see "steps" in the line graphs provided here). I've thought up some improvements for it (like sticking a roof in the map used so I can get some decent vertical angle stats), but even if I implemented those it'd still never be "accurate".

That said, I got [http://pastebin.com/mcbc752a 2550 results for 0% firing accuracy] overnight and [http://pastebin.com/mdf60034 1876 for 50%] today. I've got the system in concern running trials for 25% until tomorrow.

The graphs displayed summarise these angles. Essentially they go from "those that went to the left" across to "those that went to the right". The longer the line stays at a given level, the more shots took that angle.

At 0% accuracy, the largest horizontal angle I got AWAY from the target was 27.5 degrees (that is to say, a shot could go anywhere within a range of 55 degrees), the average angle being 7.32 degrees. With the side graph you can get an idea of the distribution: Your shots are more likely to hit or at least get close then they are to be far away.

Bumping the rated accuracy to 50% lowered the maximum angle to 17.01 degrees (average of 2.75). Again, you're a lot more likely to get close to the target then you are to reach the possible extremes.

I've since done tests at 100% accuracy and found that the same curve exists, just squished right down. You still have a chance to miss, but only by slight amounts. A formula should be apparent in there somewhere.

At a glance I think it's an exponential equation divided by your rated accuracy? With a few more tests I suppose it'd be more apparent.

: My theory is this that the program first runs "was shot accurate?" check. If yes, then shot deviates 0 and hits the target. If shot misses, calculate path of bullet. Path of bullet follows formula that gives that bell curve.
: I rather suspect that at 25% accuracy, 25% of your shots will be on target, at 50%, 50% will be on target, so on and so forth.
: There might be some additional weird "random drift" that makes 100% and higher accuracy still miss. *Shrugs*. - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: I am absolutely convinced that there is no "was shot accurate?" check. If there was one, I reckon it'd be apparent on the graphs here. I could be wrong, but I believe I've seen no data that supports the theory. No, finding that a certain accuracy rating "seems right" when firing from a certain distance is not supporting data, in that this is the case regardless of whether an "accurate shot" check exists. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)
: Despite the fact it will make your life even harder, I have to remind you that there is also PARTIAL COVER to factor into the tests... what happens when the target is behind a window (modded to be indestructible?), behind a hedge, only his head is visible poking out through the floor (bug here lol)... sometimes a shot will go THROUGH a window, sometimes it will HIT the window... - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: Remember, the "accuracy formula" I'm looking to determine simply returns an angle, which, dependant on your overall accuracy score an the random number generator, will go off on some who knows what direction. Whether that angle leads to the target is dependent on the visible target area versus the angles you'll get based on your accuracy stat (this "target area" concept is the purpose of the next section down, mostly unwritten because it's pointless until THIS formula is figured out).

:: That is to say, there's no real formula that can tell you the REAL chance to hit a target without actually inputting all the tile data in addition to using the "angles formula" I'm after here. Luckily, once the angle formula is determined, it shouldn't be too hard to have my battlescape editor calculate the "true" chance of a shot hitting. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)

: I wonder if it's possible that the game's maximum firing angle (e.g. at zero accuracy) is one radian - about 57.3 degrees? This is near your observed limit of 55 degrees. The game engine would probably use trig functions based on radians as I believe they are the most efficient. Given the power of the computers they were programming for, this vector work was pushing the envelope so they would need to be efficient. - [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)
::I would say that yes, given the close proximity (and the inherent inaccuracy of my logger, due to the inability to pick up on the precise ''point'' a bullet hit), one radian is correct.

::The [[COS.DAT]] page will probably be relevant at some point, dunno if you've read that. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Also could you clarify the axes on these 2 graphs/histograms? I'm having a lot of trouble understanding them. Is it possible that the vertical axis should be frequency, and the angle should be on the horizontal axis? Or am I being dumb? If I'm understanding them correctly, we are not seeing a linear distribution of error angles - as you would get from say

ActualAngle=AngleToTarget+(rand(57)-(57/2))

:what we are getting is angles that cluster together near the correct aimpoint, and frequency falls off quickly as you move away from the correct aimpoint.

:: You are reading the charts correctly. The vertical axis shows how often a specific angle was picked to fire along by the game, and the horizontal axis shows the angles themselves. The reason the charts are symetrical is because shots can either go to the left or right of the target (an angle of 0 means it hit). Even with 0 FFA, you're a lot more likely to send a bullet near the target then you are to send one on the maximum diverging angle - hence my statement, "I think it's an exponential equation divided by your rated accuracy". - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Guess: The graphs look not unlike a tangent or inverse tangent function. That might suggest that the firing function injects a linear amount of perpendicular drift (horizontal and maybe vertical) onto the bullet's vector. Maybe try graphing the tan() or arctan() of the data from the "zero accuracy" tests, and see if you get a horizontal straight line.

: arctan (0.5), which might be relevant if maximum "perpendicular error" is 1 map square wide per map distance unit, is 26.565 degrees, near to your value of 27.5 degrees. Arctan (0.25), which corresponding to half that "perpendicular error", half a map square wide per map distance unit (and maybe corresponding to 50% FFA????), is 14.036 degrees, again near to your value of 17 degrees for 50% FFA. But only 'near', and higher. Hmm. Your data have a horizontal granularity of 1/16th of a map square distance unit, is that right? So there could be some data slightly outside the true upper limit for angles. It depends on the range to your target in your test setup I guess. [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)

:: This is where my brain starts to melt, mind you, it's 3:15am here so I'm probably not good for any number crunching right now. But I reckon you're onto something even if I can't wrap my brain around what!

:: I put the target about 25 squares back (middle of the map). Really can't remember. Ideally I'd've set him to be a pixel in size, but back then the "using LOFTemps for unit size" thing was just a theory I had, not a proven fact (I never got around to updating this page when it WAS proven, that's how long these notes have been here).

:: Yes, granularity is a 16th of a standard user-visible map tile. On the horizontal plane anyway. Can't remember if I set it to 24ths on the vertical, but I probably did. The problem is, of course, that it can only pick up data according to whether a bullet hit a tile or not (as opposed to data on where the tile was hit), so although the range of angles should be "close to accurate" there's still those nasty steps everywhere which have to be "guesstamated".

:: I never really bothered much with the vertical data as I was mostly "proving the concept", figured I'd get to that later. I know I logged it (I was even able to draw an ellipse to show where all the bullets would fall, your maximum vertical angles are of course no where near your maximum horizontal ones), but I can't find the charts in concern. They weren't that good anyway as the test map had no ceiling.

:: I distinctly remember logging and graphing the 100% FFA data but can't find that either. Probably deleted it from my system (in the misguided belief that I'd uploaded it all here). I cannot find any of my related logs at all, in fact, just a single zip file with the logger, test map and automated script file ready to go. Again, this may be because I've deleted them, or because I have nearly ten thousand files in my UFO directory. My main one, anyway. I have a few such directories. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

: OK. The curve you graph above for "zero accuracy" looks not unlike what happens if you graph tan(x) (in degrees), where x is from +0.5 to +0.5. But I think that's a coincidence, since your graph is not a standard histogram - you are showing "frequency" by the length of lines on the x axis, rather than by the height of bars along the y axis as in a standard histogram. In order to turn your graph into a standard histogram it would need to be more or less inverted I think.
: The link to the "zero accuracy" data set is broken now. From what you said above, the data is lost now, which is a shame as it would be nice to do a histogram of tan(a) for all the angles "a" in that data set. You might see a flat line, linear distribution. Or not. If the angles are "bunching up" in frequency toward the target centre, then that suggests a ''linear perpendicular'' distribution of angles. With a linear perpendicular distribution (eg varies by +/- 0 to N units, perpendicular to the path to target, per unit of distance), you would expect a "bunched" angular distribution, i.e. if you sorted all the angles in the data set, the separation between one angle and the next widest would steadily increase.
: The Z component is going to complicate things and prevent finding an exact solution. For example, say that the Z (vertical) error/cone and X (lateral) error/cone are not independent of each other. For example, they might be constrained to add up to some constant N that's related to FFA: Z + Y < N. Or in fact, it might be more like (vertical x 4 + horizontal x 1) < N (since we suspect the actual 'bullet group' is an oval, wider than it is high, rather than a circle). A circle is almost the simplest case, but again unless Z and X are totally independent, you're not going to find a close fit for the function without knowing both terms. Hopefully the oval is very 'flat' and so the horizontal-only function will be a good enough approximation of the data to get in the right ballpark. Or even better, maybe the Z component is a totally independent function. Hope so.
: Let me make a prediction or a series of predictions then for maximum angle off-target:
:* 0% FFA = 1.0 perpendicular error per unit distance = +/ 0.500, arctan(0.500) = +/- 26.6 degrees
:* 50% FFA = 0.5 perpendicular error per unit distance = +/ 0.250, arctan(0.250) = +/- 14.0 degrees
:* 75% FFA = .25 perpendicular error per unit distance = +/ 0.125, arctan(0.125) = +/- 7.1 degrees
:* in general, horizontal maximum angle off target = +/- arctan(((100-FFA)/100)/2)
: Well that's most likely wrong but it's good to have a starting point for testing! [[User:Spike|Spike]] 17:40, 15 March 2009 (EDT)

Hey, guess what? First thing on completing a fresh round of tests, I discover all my old logs.

Of course.

Originals (with no roof on the map so the vertical shot data is a bit iffy): [[User_talk:Bomb_Bloke:0acc1|0%]] - [[User_talk:Bomb_Bloke:25acc1|25%]] - [[User_talk:Bomb_Bloke:50acc1|50%]] - [[User_talk:Bomb_Bloke:75acc1|75%]] - [[User_talk:Bomb_Bloke:100acc1|100%]]

New data (with a roof, vertical shot data might actually be worth something): [[User_talk:Bomb_Bloke:0acc2|0%]] - [[User_talk:Bomb_Bloke:25acc2|25%]] - [[User_talk:Bomb_Bloke:50acc2|50%]] - [[User_talk:Bomb_Bloke:75acc2|75%]] - [[User_talk:Bomb_Bloke:100acc2|100%]]

Comma separated data, one shot per line. First three columns are the absolute tile x/y/z co-ords of where the shot ended up hitting (keeping in mind the shooter is at tile 24/49/2). Next three columns are the x/y/z of where the shot landed, relative to where the shooter is. Final two columns are the important ones, they cover the horizontal and vertical angles the shot took, respectively.

Yes, the wiki doesn't represent it very neatly. Use the edit button to get the line breaks back.

Hrm. Looks like the max angle at 75% comes out to 11.53 degrees... Not 7.1. :(

- [[User:Bomb Bloke|Bomb Bloke]] 09:37, 18 March 2009 (EDT)

----

[[image:BBFiringPointTest6.png|thumb|200px]]
Here is a graph that somewhat better displays the results of my initial 0FA results. The blue line represents the recorded numbers (2550 different values). The red line represents an equal number of results generated by the spreadsheet formula "SIN(RAND()*1.5)*28.64788975*IF(RAND()>0.5;-1;1)".

(Which is, effectively, "The sine of a random number between -1.5 and 1.5 multiplied by half a radian").

Unfortunately the two formulas don't line up (even if you mirror 'em on the diagonal), but they're fairly close. Much closer then the exponential equations I tried graphing, at any rate. I'm thinking I might be able to get something better still with TAN, but I don't seem to be having much luck with that...

- [[User:Bomb Bloke|Bomb Bloke]] 02:18, 15 April 2009 (EDT)

: tan eyeballs great if you assume the distribution going in is some flavor of "sum of linear distributions". tan-1(25°)=0.466307658155; halving this and taking the tangent again gets me ~13.1°, which is reached about 1/16th of the way across. I'm assuming some sort of discretization error for the asymmetry. (My initial gut reaction was "sum of two linear distributions", but that isn't correct; that would have landed about 1/8th of the way across. The quick-and-dirty way to fake a bell curve is to sum three linear distributions.) -- [[User:Zaimoni|Zaimoni]] 11:52, 15 April 2009
(CDT)

: Per geometric check; tan works if the incoming angle is from a sum of three linear distributions. That is: tan(K*rand()*rand()*rand()) should recover the graph up to discretization error, for some K. -- [[User:Zaimoni|Zaimoni]] 12:02, 15 April 2009 (CDT)

:: Is there any chance it's some function of (Kx rand(x), Ky rand(y), Kz rand(z)? [[User:Spike|Spike]] 17:53, 15 April 2009 (EDT)

::: It depends on what you mean...

::: I was presuming rand() was a zero-parameter function that needed "massaging" to get to any range other than its default. C rand() would be 0..RAND_MAX. XCOM almost certainly has a wrapper that returns values in a range 0..N. Given when XCOM was written, I don't think it has any sort of floating-point RNG. I wrote K to subsume all of the range-massaging that was needed.

::: That said, a general sum of three linear distributions would have been tan(K1*rand()+K2*rand()+K3*rand()-AVERAGE) [ignoring overflow issues], where AVERAGE is the statistical average expected from K1*rand()+K2*rand()+K3*rand(). The geometric check almost certainly wouldn't pass if the three constants were obviously distinct. The actual expression I'd try retrofitting is tan(K*(rand()+rand()+rand())-AVERAGE). -- [[User:Zaimoni|Zaimoni]] 14:07, 16 April 2009 (CDT)

:::: If rand() was to receive any parameter at all, it'd be a seed; but calling the function three times should result in three different numbers anyway (typically you seed the RNG first). I'd be surprised if even the original game didn't have a floating RNG. Even back on the Spectrums/Commodores/BBCs you could generate within most any range by typing something like RNG*N. I tried graphing TAN(RAND()*1.5) then TAN(1.5*(RAND()+RAND()+RAND())-2.25), though the first formula wasn't right and the second was worse. :( It's a bit too steep (a little like what you get from 1/x but flopped around). Maybe something a bit higher then 1.5 would sort that out, but I dunno how high you can legally go with TAN? - [[User:Bomb Bloke|Bomb Bloke]] 20:36, 16 April 2009 (EDT)

::::: tan goes unbounded at ±π/2 radians i.e. ±90° Given that the initial bounds appear to be ~±25°, I'd calibrate things so that we were looking at a total span of 50° i.e. ~0.872 radians. In radians, with rand() being a uniform distribution 0..1: TAN(0.872*(rand()+rand()+rand())-0.436) would be my guess.

::::: XCOM 1.2 had some source code comments indicating that the C source targeted Watcom C. That means the "easy rand" available is the C standard library rand(), which without processing returns an integer from 0..RAND_MAX, where RAND_MAX may be as low as 32,767. -- [[User:Zaimoni|Zaimoni]] 12:36, 17 April 2009 (CDT)

: 55 degrees horizontal deviation range corresponds to 440 1/8 degree units; quick-but-lousy-RNG C source for the eighths-of-degrees input to the tangent function at accuracy 0 should be <code>(rand()%147+rand()%147+rand()%147)-219</code> . This plausibly is from a "deviation output" function that returns 73 at accuracy 0, 45 at accuracy 50, and 31 at accuracy 75. Corresponding psuedocode:
<pre>const int tmp = acc_func(...);
const int rng_scale = 2*tmp+1;
const int rng_bias = 3*tmp;

....

(rand()%rng_scale+rand()%rng_scale+rand()%rng_scale)-rng_bias;</pre>

: -- [[User:Zaimoni|Zaimoni]] 13:58, 26 December 2010 (CST)

: That means the deviation output function should be something like <tt>73-INT(14*Accuracy/25)</tt>. -- [[User:Zaimoni|Zaimoni]] 14:31, 26 December 2010 (CST)

::[[image:acc50zaitest.png|thumb|200px]]That's pretty good, I reckon you've nailed the angle caps, probably perfectly - though the "average" values returned by the final formula are still somewhat out of sync with those observed. Here's a graph comparing the two at accuracy 50. On average, the game is getting more shots going along at a 0 (or near 0) degree angle (shown in the red, in case the jagged mess doesn't make it obvious ;) ), whereas the formula is getting the same spread (of course) but with far more "misses" overall. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:18, 28 December 2010 (EST)

::: I'll have to cross-check that graph of the theoretical curve. Thing is, since I play with the projectiles in slowest-speed possible by default I'm pretty sure that I'm not getting 50% perfect shots at 50% accuracy. That would be the snap impression from the current graph: 50% perfect shots, 50% deviated shots. -- [[User:Zaimoni|Zaimoni]] 18:15, 28 December 2010 (CST)

:::: I'm getting a flatter candidate theoretical distribution than your graph, but not as flat as the empirical graph. Much depends on the exact rounding/truncating behavior.

:::: I see that the graph has steps at the 1° points; the theoretical distribution being considered is in steps of 1/8°.

:::: The simplest classical approximation at range 40 for an on-axis shot at a north wall (due north of the firer; corresponding range for due south of the firer is range 41), would read any horizontal error angle with absolute value less than arctan(1/81) ~ 0.7073° as perfect. The corresponding candidate theoretical rate (for shots with error between -5/8° and 5/8° inclusive) is approximately 9.05%.

:::: A better classical approximation would use the actual origin of the shot in voxelspace, rather than the impossible midpoint. -- [[User:Zaimoni|Zaimoni]] 19:41, 28 December 2010

::::: Two problems with the above.

::::: First, the firing origin for due north has been measured: it's (8,1). That means the fast approximation would have been arctan(1/80) [which numerically doesn't change anything].

::::: To set up the classical approximation at range 40 due north, the actual arctangents needed are -arctan(8.5/(16*40)) and arctan(7.5/(16*40)) [these correspond to the west and east edges of the north wall section]. Numerically, this is ~ -0.7609° and ~ 0.6714° . That is, the actual corresponding theoretical error rate is for shots with error between -3/4° and 5/8°, which is approximately 9.87%. -- [[User:Zaimoni|Zaimoni]] 20:14, 28 December 2010

: Just realized that the targeting center should be (8,8) (all of the [[LOFTEMPS.DAT]] templates used by units are centered there). -- [[User:Zaimoni|Zaimoni]] 20:19, 30 December 2010

 
===Vertical Error vs Horizontal Error===

Hmmm.... I don't know about you guys, but I notice that in my games, when firing from Level 0 at enemies on level 0, my soldiers seem like their vertical deviation tends to be very small, even with high inaccuracy. Their horizontal deviation seems much much larger. Is this my imagination?

- [[User:Jasonred|Jasonred]]

----

You're quite right, they're two different things. There's enough error there to miss at point blank range against a short target, but still nothing like what you get in the horizontal scheme of things.

- [[User:Bomb Bloke|Bomb Bloke]] 08:46, 17 April 2009 (EDT)

== Target Size ==

Units are cylinders, made up of a [[LOFTEMPS.DAT]] layer determined by [[UNITREF.DAT|UnitRef[48]/[52]]], stacked according to their [[Height]].

The full purpose of UnitRef[52] is still in doubt, though it always seems to mirror the value held at [48]. My personal guess is that one is (or at least, was supposed to be) used when bullets come in on one angle, and the other value is used when bullets come in on a perpendicular-ish angle (hence allowing the cylinder to act more like a squished tube, which is closer to the shape of a real person - or it would do if 48/52 didn't always match).

So, yeah, set [48] to 0, all your units get set to an empty LOFTemps record, they cannot be seen/hit by the aliens. Hurrah.

== See Also ==

Pages relevant to this subject:
*[[Firing Accuracy]]
*[[Accuracy formula]]
*[[Firing Accuracy Testing]]
*[[Height]]
*[[LOFTEMPS.DAT]]
*[[Blind Spots From First Principles]]

Blind Spots From First Principles

2011-01-01T11:03:33Z

Zaimoni: First pass at calculating blind spots from first principles. Needs empirical testing.

(Strictly speaking for XCOM1, but should generalize to XCOM2 and Apocalypse.)

[[User:Zaimoni|Zaimoni]]: It's a parallelogram problem: the two lines of fire are not coincident, and the displacement between the firing point and the center is "just enough" to create the blind spot.

Example: north wall in square 1 south of unit, ambusher unit facing SE (facing 3). Defender facing when returning fire is 7. Assuming a "sane" pixel-line drawing algorithm:
* If the resulting firing line has classical SE slope strictly exceeding 2, the ambusher's firing line should hit the north wall and not be an issue.
* If the classical SE slope is exactly 2, we have an edge case and the actual line-tracing algorithm determines whether the ambusher has a line of fire.
* Due SE isn't a blind spot.
* In both cases, we have a 8-pixel diagonal line (containing the endpoints) between the unit's centroid at (8,8) and the firing origin. The defender can return fire if his line of fire goes through the ambusher's firing origin, otherwise he is blind. [This only makes sense because we're analyzing in voxelspace.) The critical classical SE slope is 15/14; for this slope, the actual line-tracing algorithm determines whether the ambusher has a line of fire.

Without loss of generality, consider the ambusher to be at (0,0); we wish to identify squares with range 19 or less in (1..18,1..18) that should be ambushable.

{|
! target || ambush line of fire || SE slope || targetable? || ambush?
|-
| (2,1) || ((-15, 15), (-40, 24)) || 25/9 || no ||
|-
| (3,2) || ((-15, 15), (-56, 40)) || 41/25 || yes || yes
|-
| (4,2) || ((-15, 15), (-72, 40)) || 57/25 || no ||
|-
| (4,3) || ((-15, 15), (-72, 56)) || 57/41 || yes || yes
|-
| (5,3) || ((-15, 15), (-88, 56)) || 73/41 || no ||
|-
| (5,4) || ((-15, 15), (-88, 72)) || 73/57 || yes || yes
|-
| (6,4) || ((-15, 15), (-104, 72)) || 89/57 || yes || yes
|-
| (7,4) || ((-15, 15), (-120, 72)) || 105/57 || yes || yes
|-
| (8,4) || ((-15, 15), (-136, 72)) || 121/57 || yes || yes
|-
| (6,5) || ((-15, 15), (-104, 88)) || 89/73 || yes || yes
|-
| (7,5) || ((-15, 15), (-120, 88)) || 105/73 || yes || yes
|-
| (8,5) || ((-15, 15), (-136, 88)) || 121/73 || yes || yes
|-
| (9,5) || ((-15, 15), (-152, 88)) || 137/73 || yes || yes
|-
| (10,5) || ((-15, 15), (-168, 88)) || 153/73 || no ||
|-
| (7,6) || ((-15, 15), (-120, 104)) || 105/87 || yes || yes
|-
| (8,6) || ((-15, 15), (-136, 104)) || 121/87 || yes || yes
|-
| (9,6) || ((-15, 15), (-152, 104)) || 137/87 || yes || yes
|-
| (10,6) || ((-15, 15), (-168, 104)) || 153/87 || yes || yes
|-
| (11,6) || ((-15, 15), (-184, 104)) || 169/87 || yes || yes
|-
| (12,6) || ((-15, 15), (-200, 104)) || 185/87 || no ||
|-
| (8,7) || ((-15, 15), (-136, 120)) || 121/103 || yes || yes
|-
| (9,7) || ((-15, 15), (-152, 120)) || 137/103 || yes || yes
|-
| (10,7) || ((-15, 15), (-168, 120)) || 153/103 || yes || yes
|-
| (11,7) || ((-15, 15), (-184, 120)) || 169/103 || yes || yes
|-
| (12,7) || ((-15, 15), (-200, 120)) || 185/103 || yes || yes
|-
| (13,7) || ((-15, 15), (-216, 120)) || 201/103 || yes || yes
|-
| (14,7) || ((-15, 15), (-232, 120)) || 217/103 || no ||
|-
| (9,8) || ((-15, 15), (-152, 136)) || 137/119 || yes || yes
|-
| (10,8) || ((-15, 15), (-168, 136)) || 153/119 || yes || yes
|-
| (11,8) || ((-15, 15), (-184, 136)) || 169/119 || yes || yes
|-
| (12,8) || ((-15, 15), (-200, 136)) || 185/119 || yes || yes
|-
| (13,8) || ((-15, 15), (-216, 136)) || 201/119 || yes || yes
|-
| (14,8) || ((-15, 15), (-232, 136)) || 217/119 || yes || yes
|-
| (15,8) || ((-15, 15), (-248, 136)) || 233/119 || yes || yes
|-
| (10,9) || ((-15, 15), (-168, 152)) || 153/135 || yes || yes
|-
| (11,9) || ((-15, 15), (-184, 152)) || 169/135 || yes || yes
|-
| (12,9) || ((-15, 15), (-200, 152)) || 185/135 || yes || yes
|-
| (13,9) || ((-15, 15), (-216, 152)) || 201/135 || yes || yes
|-
| (14,9) || ((-15, 15), (-232, 152)) || 217/135 || yes || yes
|-
| (15,9) || ((-15, 15), (-248, 152)) || 233/135 || yes || yes
|-
| (11,10) || ((-15, 15), (-184, 168)) || 169/151 || yes || yes
|-
| (12,10) || ((-15, 15), (-200, 168)) || 185/151 || yes || yes
|-
| (13,10) || ((-15, 15), (-216, 168)) || 201/151 || yes || yes
|-
| (14,10) || ((-15, 15), (-232, 168)) || 217/151 || yes || yes
|-
| (12,11) || ((-15, 15), (-200, 184)) || 185/167 || yes || yes
|-
| (13,11) || ((-15, 15), (-216, 184)) || 201/167 || yes || yes
|-
| (14,11) || ((-15, 15), (-232, 184)) || 217/167 || yes || yes
|-
| (13,12) || ((-15, 15), (-216, 200)) || 201/183 || yes || yes
|}

[Yes, strictly speaking all of those classical slopes are negative, but that's implied (for this choice of coordinates) by specifying a southeast bearing.]

We have a dual analysis and table for ambusher with west wall one square east.

Python 2.6 source code for constructing the ambush line of fire for the above table follows (should also be in the next update to my XCOM editor suite as XCOM1.py):
<pre># Voxelspace: 0..15,0..15,0,23..0 internal coordinates
fire_voxel_x_y_from_facing = ((1,8),(1,14),(8,15),(15,15),(15,8),(15,1),(8,1),(1,1))

# coords are internal-square: row,col format with 0,0 at upper-left
# we need to self-test this
def facing_from_coords(src,dest):
delta = (dest[0]-src[0],dest[1]-src[1])
if 0==delta[0]:
if 0<delta[1]:
return 2
else:
return 6
elif 0==delta[1]:
if 0<delta[0]:
return 4
else:
return 0
elif 0<delta[0]:
if 0<delta[1]:
if 2*delta[0]<=delta[1]:
return 2
elif 2*delta[1]<delta[0]:
return 4
else:
return 3
else: #if 0>delta[1]
if 2*delta[0]<-delta[1]:
return 6
elif -2*delta[1]<=delta[0]:
return 4
else:
return 5
else: #if 0>delta[0]
if 0<delta[1]:
if -2*delta[0]<delta[1]:
return 2
elif 2*delta[1]<=-delta[0]:
return 0
else:
return 1
else: #if 0>delta[1]
if -2*delta[0]<=-delta[1]:
return 6
elif -2*delta[1]<-delta[0]:
return 0
else:
return 7

# yes, Voxelspace rows are reverse-order to coordinate rows
def convert_firearm_attack_unit_coords_from_map_to_voxels(src,dest):
fire_offset = fire_voxel_x_y_from_facing[facing_from_coords(src,dest)]
return ((-16*src[0]-fire_offset[0],16*src[1]+fire_offset[1]),(-16*dest[0]-8,16*dest[1]+8))
</pre>

==See Also==

[[Line of sight]]

[[User talk:Bomb Bloke:Firing Accuracy]]

User talk:Zaimoni

2011-01-01T09:31:08Z

Zaimoni:

"Welcome to Base Aleph-NULL in Nigeria. We managed to get the Prince of Darkness off of the base planning committee, so Aleph-NULL is a real base. Base Continuum near Tokyo has just started construction.

And ETA for the first pair of UFOs is 14:30 sharp."

<hr width="80%" align="center">

The redeeming feature of putting the first base in Nigeria is...it's nearly antipodal to Hawaii. Very good scummy Interceptor coverage for a single base. [Holes: Half of Australia, the entire Pacific Ocean, parts of Siberia and North America.] The second base completes scummy Interceptor coverage for all land masses of interest.

It's not like there shouldn't be an automatic alarm that goes off when UFO reports start coming in.

[[User:Zaimoni|Zaimoni]] -- 9:11AM, 18 July 2006 (CDT)

[[Exercising The AI]]

[[UFO Flight Patterns]]

[[Encumbrance (Apocalypse)]]

[[Sketching Executing Aliens Efficiently]]

[[Image:Zaimoni Strength vs. Throwing Distance.zip]]

[[Known Bugs (Apocalypse)]]

[[Zaimoni's Apocalypse Checklists]]

[[TU Threshold tables (Apocalypse)]]

[[Zaimoni's XCOM1 Editor]]

[[Blind Spots From First Principles]]

<hr width="80%" align="center">

=== Things to remember to do at some point (when work schedule not haywire) ===
* probability of MC plane graph (not sure whether to do this manually, or write C++ programs to automate)
* suite of Python game editing scripts; basically, cover holes in ClarkWehyr and XcomUtil editors. Curses module doesn't exist in Windows port; looks like it targets ncurses, which has not been ported to either Windows or DOS.
** Base layout: automatically handle radar detection from radars
** Battlescape saves: help out the AI (turn 1 alien facing, ROUTES.DAT fixups), probably will have to integrate with XcomUtil. Need to research LOS more carefully first.
** Advanced two-player hotseat (individual visibility support, allow aliens to fire alien weapons, working explosives).

[[User:Zaimoni|Zaimoni]] -- 6:29PM, 19 Sept 2006 (CDT)

=== Some working notes on advanced swap ===
* XcomUtil's default visibility hack is workable for the alien side (they're there first). Backup and restore [[SEEMAP.DAT]] to handle human visibility. [Done]
* Need two backups for [[MISDATA.DAT]]: human and alien. Alien has all alien tech enabled. [Done.]
* [[WGLOB.DAT]] probably can be automatically fixed when going from alien turn to human turn (backup when alien turn starts, then parse for changes and invert). [Done]
** May want to do something about turn counters.
* Autoclosing doors can be dealt with (it appears that whatever closes them in-game is silent). While it would be nice to parse the MCD files, a lookup table of indices by terrain type will work. [Done.]
* [[UNITREF.DAT]] experience counters cannot be automatically fixed for XCOM (they are not incremented in alien turn mode). Theoretically, they should be patched for alien units "just in case" (We have other reasons for backing up UNITREF.DAT).
* One of the StrategyCore posts mentioned that hacking a Stun Rod into a Chryssalid enabled the native melee attack. Need to check whether this gives the native attack speed (14 TU?)...if so, can automate this directly (leaving only grenades to deal with).
* Grenades, Alien Grenades, and melee aliens can be enabled as follows (to automate, need an environment that can inject mouse events into XCOM)
** "anchor" the shooting aliens using various current/recovery energy hack
** end the turn, then quit.
** backpatch energy/TU/facing-related values into non-melee aliens
** or we could just do the lazy thing and directly emulate the exploding grenade.
* If replacing XcomUtil's SWP function outright:
** be sure not to repair damaged armor.
** Fatal wounds can be handled properly ("wraith" problem is from not updating the [[UNITPOS.DAT]] entry). Remember to force the health of dead units to 0 to prevent the resurrection bug post-battle.

Note that my local copy of XcomUtil is patched to use <code>COPY /Y ...</code> rather than <code>COPY ...</code>; this prevents waiting for an interactive prompt in a batchfile. [Default behavior doesn't work right in Win2000.] I got this from some thread in the xcomufo forums.

The simpler parts will be implemented in Python.

[[User:Zaimoni|Zaimoni]] -- 11:50PM, 16 April 2007 (CDT)

=== Testing plans: Doomed to Decline Prices in Apocalypse ===
...because they don't go up even when completely bought out. Results go into the corresponding XCOMUFO thread, I just don't want to forget what I'm doing.

I got suspicious while experimenting with Sunday Inventory Management. Nothing with a base price of 30 or less went up when I bought them out...a 0% rate of return on the fiat money I parked in them. The following didn't go up
* vehicle autocannon ammunition (stayed at 5)
* Lawpistol clips (stayed at 10)
* M4000 ammunication (stayed at 20)
* AP autocannon clips (stayed at 30)

Note that more expensive items (e.g., autocannon explosive clips) did twang upwards.

[[User:Zaimoni|Zaimoni]] -- 14:58, 27 Jul 2007 (CDT)

Finally completed week 2. Vehicle autocannon ammunition and Lawpistol clips will be tested next; both prices did go down as expected, by 1.
* Ahem...need to be more careful; lawpistol clips were not testable after all. Worse, I had an attack of perfectionism: it turns out that firing biochemists also fires soldiers.... Restart game, and contemplate command-line utility.

[[User:Zaimoni|Zaimoni]] -- 10:13, 05 Aug 2007 (CDT)

Bungled a real-time game strategically (may restart), but did get in some testing.
* Buying out an item that costs 30, does not cause a price increase. Doing the same for 40, does. Results were consistent for more extreme prices (in both directions). [Ended up doing a doctrine change, so restart. Two LAW pistols as backup for a personal autocannon works very nicely in RT. Too bad there's very little ammunition for LAW pistols.]
* I was able to make smoke grenades go down from 30 to 29 by selling all of them. Likewise, 2100+ vehicle autocannon rounds appears to be a reliable way to drop the price from 5 to 4. Now, if these are truly irrecoverable....

[[User:Zaimoni|Zaimoni]] -- 19:51, 14 Sep 2007 (CDT)

=== Tactical notes, Apocalypse ===
* I use framestepping at 50% speed in hairy situations for real-time. This makes it possible to actually run from primed grenades, and occasionally dodge rockets and long-range fire.
* 10 biochemists...run out of projects near the end of week 2, temporarily. (Stalled by needing an advanced biochemistry lab, really should consider a new base the instant an advanced biochemistry lab is constructable).
* Jumping into empty space costs 0 TUs for non-flying units. Real-time is not so user-friendly. On the other hand, picking up objects appears to be free in real-time (but picking up live grenades doesn't stop them from detonating).
* It is unclear whether the martial art of dodging incorrectly aimed large rockets is a skill, or supernatural. On the other hand, kneeling may be a somewhat reliable way of assuring that it takes two large rockets to die rather than one.
* Real-time visibility updates appear to be closely related to full-second updates. Units with low reactions take more frames to see the same alien.
* Turn-based TU calculation for shots: aimed is per reference. INT(aimed/2) to get snap shot TUs. INT(aimed/4) to get autofire TUs. Yes, this means an aimed shot of 7TUs will grant an autoshot of 1 TU. An important special case for the M-4000, moderately useful for the LAW pistol.
* Early-game note: hovercars are much easier to hit than hoverbikes. Get over the ego trip and put the small Rendors on hoverbikes, at least until vehicle shields are researched.
* Stun raids do not trigger promotions, even if soldiers involved would otherwise qualify.
* Tired of dwarf maps when raiding the Cult of Sirius? There's a breakpoint at 20 X-COM Agents. 19 Agents or less gets you a 2x2 map just like 12 Agents, 20 Agents gets you a 3x2 map. This makes a disproportionate difference in how many [[Psiclone|Psiclones]] can be recovered. (Lower bound not verified, possibility of yet larger maps not verified.)
::This seems to be the case with traditional semi-random maps like the cult temples or maybe the Recyclotorium. Fixed maps, which are frequent in this game, aren't affected. But to make things interesting, later in the game there may even be a massive alien drop that will generate a two fixed map mission (aka two slum maps or fixed apartment maps side by side for example). Alien population could be a factor. -[[User:NKF|NKF]] 22:39, 13 January 2009 (CST)
::: Actually, total population is a factor. I probably should do a proper save-scum screening; I just ran across a case where 20 Agents + 9 CoS resulted in a 2x2 map, so it seems that the threshold is actually 30. Also, the map randomization varies by at least one of corporation or building type (stun-raiding Marsec's Arms One starts at 1x3, not 2x2). -- [[User:Zaimoni|Zaimoni]] 10:52, 17 Jan 2009 (CST)
* Turn-based abuse: wall-running. Not all diagonal jumps that start can be completed; those that don't end up being a free move. SE/SW jumps thoroughly obstructed by a north wall end up being E/W moves. NE/SE jumps thoroughly obstructed by a W wall end up being N/S moves. Note that the reverse (NE/NW and north wall, NW/SW and west wall) are not obstructed at all.
* Testing in hotseat mode suggests brainsuckers have problems with "unusual relative heights" in turn-based mode. (They have no need for attack controls; if they have at least 18MP and are no more than L1/Manhattan distance 1 they will athletically jump onto humans and hybrids. They do not jump onto androids.) In particular, launching from a 45° grade from below onto an agent kneeling on level ground is harmless to the agent. Not only that, the brainsucker will jump repeatedly until it has less than 18 MP.
* Some early-game kits
** base: Megapol armor, medikit, 2 frag grenades, 2 stun grenades. Deduct up to two grenades to reach a speed breakpoint. Note that real-time speeds are a multiple of 8 (they index how many 80ths of a square are covered when running in one frame); you'll look a bit faster in real-time than in turn-based. Haven't made up my mind what to use Marsec armor for.
** Rifleman: Marsec machine gun. Two spare clips.
** Disruptorman: light disruptor rather than machine gun.
** Autocannon: need STR 50 to qualify. Start with one AP clip loaded, 1 spare AP clip, and 1 explosive clip. The RT version ideally is equipped with two identical pistols and 2 spare clips for those pistols. Start with LAW pistols, upgrade to plasma pistols when available.
** LAWgunner: Real-time kit. A rifleman that both cannot be faster by losing grenades from his kit, and is not slowed by two LAW pistols with eight spare clips. The fastest average rate-of-fire kit in the early game. The analogous kit with plasma pistols would have four spare clips.

[[User:Zaimoni|Zaimoni]] -- 22:06, 13 Jan 2009 (CDT)

== Medium Scout Ambushing ==

[[Image:MediumScout.gif]]

So, the thought of directly covering the exit of a medium scout doesn't sound too good, for whatever reason. How about piling up on the side walls and getting some reaction shots that way?

Say...

<pre> _____
XX / \XX
RX | |XR
x | |R
| |
\_____/
o</pre>Oh, wait...those obnoxious fake walls are causing problems. x cannot fire on the alien at o, but o not only can fire at the agent at x but actually prefers x to the agent at R that can return fire.

User talk:Bomb Bloke:Firing Accuracy

2010-12-31T02:20:25Z

Zaimoni:

{{tocright}}Consider this [[User:Bomb Bloke|Bomb Bloke's]] draft/discussion about firing accuracy. This topic has been dragging on for quite some time now, so I figure it to about time I had a stab at it.

My view on the matter is this: When you fire a gun, UFO works out the horizontal and vertical angles between your unit and the target, then modifies these depending on your [[Accuracy_formula|overall accuracy stat]].

Say for example you have a perfect 100% (or better) "accuracy". The lines are nearly unmodified, and so near guaranteed to hit (assuming there are no obstructions, in which case you should get a "No LOF!" message when you attempt to fire. Note that the game doesn't ALWAYS give this message and will sometimes allow you to attempt "impossible" shots. In these cases, less-then-perfect aim might still allow the shot to land).

As your rated accuracy decreases, target size and distance become all important: As size decreases and distance increases, the range of angles that could land a hit fall. As accuracy decreases, the range of angles that a shot can take rises and so it becomes less likely that a given shot will fall within the "hitting" range of angles.

(As for why multiple angles can "hit", think of your target as a dartboard: Perfect aim would result in a bullseye, approximate aim would still hit the board, and bad aim would miss altogether. However, in X-Com, you get full "points" so long as the bullet hits the target at all).

That is to say, the ultimate firing accuracy formula would be (range of acceptable hitting angles)/(range of possible firing angles). Assuming, of course, that when firing you're just as likely to fire at your maximum "worst" angle as you are your "best", the range of angles that can hit is determined by target distance and size, and the range of angles that can be fired along is determined by your rated firing accuracy.

However, as it turns out, the angle your shots take isn't entirely random - they follow a bell curve. You're more likely to at least hit near the target then you are to get a massive "air ball" shot. So the formula in truth will end up looking a bit more complex then that.

== Firing Point Origin ==

To get the absolute range of angles a unit can fire along, you first need to know where a unit is firing from. To this end I created a copy of my game folder and modified a save game, some terrain files, and the LOF templates.

[[image:BBFiringPointTest2.png|right|thumb|200px|A basic map of a tile. As it turns out the Y axis really points the other way.]]Now, when we talk about UFO maps, we generally refer to their dimensions in terms of how many tiles there are. However, each tile is really made up of smaller "points": A 16x16x24 point space. This means that a 30x30x4 map has 3,600 tiles in it, and 22,118,400 points within those. When a unit fires, he doesn't aim from his tile at his target's tile, he aims from a point within his tile at a point within his target's tile.

This first test was aimed at discovering exactly where a shot originates from, by creating tiles on units to selectively block their LOF. By seeing which tiles did and which did not, it could be seen exactly (or, at least, as accurately as I think I'm going to get it) where the shots were coming from.

[[image:BBFiringPointTest3.png|right|thumb|200px|The Empire's got nothing on BB's clone army.]]The first row of units served as targets for the second, which stood on tiles similar to the large earth blocks you see in bases but with one layer removed from each. Each therefore entirely blocked LOF so long as the removed layer wasn't at the same height as the unit's firing origin point. The only unit able to fire through the gap was the one sitting on the tile with the third layer down removed.

However, when defining tiles with [[LOFTEMPS.DAT|LOFTemps]], you can only stack the layers 12 high. Presumably the game "double stacks" them to make the resulting 24 point high object. Because of this, the removed layers accounted for two possible Z co-ordinates, meaning the exact value there is still unknown. Might be able to work something out to get it more precise, I dunno.

The third row stood on walls facing to the east/west. Unlike the second row, in this example I moved a single thin wall through each tile, as opposed to moving a "gap". This meant that only one unit would not be able to fire, and that was the one sitting on the ninth tile (made up of my layers from LOFTemps[15]).

[[image:BBFiringPointTest1.png|right|thumb|200px|LOFtemps used, as opposed to the [[LOFTEMPS.DAT|usual set]].]]The forth row followed more or less the same concept, with the walls facing north/south. Only the first unit was unable to fire (LOFTemps[23]).

So! With this information, getting a (x,y,z) co-oridinate is easy enough: It's either (8,15,18) or (8,15,19) (the Z co-ord being imprecise due to the 12 LOFTemp layer limitation).

Note that this value only goes for units with a facing of north. When I get time I'll go through and work it out for the other directions. Furthermore, Sectoids are likely to have a lower firing point (as their guns are rendered lower on the screen).

----

[[Image:origins.png|frame]]

I found an interesting piece of code (offset 40D8E0 for the curious). The formula for the starting zpos when firing looks like this:
''unitpos.zpos*24+unitref.terrain_height-unitref.standing_height+27-unitref.floating_height''
and for kneeling units:
''unitpos.zpos*24+unitref.terrain_height-unitref.kneeling_height+27-unitref.floating_height''
(unitref.terrain_height is offset 0x27 in unitref.dat)
I did a live check with a debugger, for a standing unit on the lowest level it gives this:
''3*24+0-16+27-0=77''
Since the engine seems to use zpos=0 for the ceiling of the topmost level, then the floor must be at offset 4*24=96. floor_level-firing_level=96-77=19, in accord with your empirical results.

Now for xpos and ypos, the engine uses several tables, indexed by the facing orientation (offset 0xa in unitref.dat):
''.data:0046B5E4 dw 8,0Eh,0Fh,0Fh, 8, 1, 1, 1''
for xpos, and
''.data:0046B5C4 dw 1, 1, 8,0Fh,0Fh,0Fh, 8, 1''
for ypos. When facing north, the shot should come from 8x1x19. Note that it is in disaccord with your experience. Maybe you don't use the same point of origin as the engine? [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

You are correct. Moving my origin to match yours brings my data into line (I was limited to guessing it's correct location). Awesome to see the ceiling size confirmed at long last. :D - [[User:Bomb Bloke|Bomb Bloke]] 02:52, 8 May 2008 (PDT)

----

Big units use 2 other tables located at offsets 46B604 and 46B624. I did not try to change these values to see if it changes the position where the shots come from. [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

The xpos/ypos information agrees with my own in vivo research (it explains several LOS different than LOF paradoxes I have explicitly verified). -- [[User:Zaimoni|Zaimoni]] 11:49, 3 May 2008 (CDT)

== Rated Accuracy Vs Angle Range ==

[[image:BBFiringPointTest4.png|thumb|200px]][[image:BBFiringPointTest5.png|thumb|200px]]Just a few results before I go off camping for the weekend. First off, note that [http://www.strategycore.co.uk/forums/index.php?act=ST&f=22&t=5805 the logger] used on this occasion is one I wrote up a year ago. It's not entirely accurate, and needs to approximate values (this is because I can only get it to think in terms of angles between tiles, as opposed to angles between points - as a result you see "steps" in the line graphs provided here). I've thought up some improvements for it (like sticking a roof in the map used so I can get some decent vertical angle stats), but even if I implemented those it'd still never be "accurate".

That said, I got [http://pastebin.com/mcbc752a 2550 results for 0% firing accuracy] overnight and [http://pastebin.com/mdf60034 1876 for 50%] today. I've got the system in concern running trials for 25% until tomorrow.

The graphs displayed summarise these angles. Essentially they go from "those that went to the left" across to "those that went to the right". The longer the line stays at a given level, the more shots took that angle.

At 0% accuracy, the largest horizontal angle I got AWAY from the target was 27.5 degrees (that is to say, a shot could go anywhere within a range of 55 degrees), the average angle being 7.32 degrees. With the side graph you can get an idea of the distribution: Your shots are more likely to hit or at least get close then they are to be far away.

Bumping the rated accuracy to 50% lowered the maximum angle to 17.01 degrees (average of 2.75). Again, you're a lot more likely to get close to the target then you are to reach the possible extremes.

I've since done tests at 100% accuracy and found that the same curve exists, just squished right down. You still have a chance to miss, but only by slight amounts. A formula should be apparent in there somewhere.

At a glance I think it's an exponential equation divided by your rated accuracy? With a few more tests I suppose it'd be more apparent.

: My theory is this that the program first runs "was shot accurate?" check. If yes, then shot deviates 0 and hits the target. If shot misses, calculate path of bullet. Path of bullet follows formula that gives that bell curve.
: I rather suspect that at 25% accuracy, 25% of your shots will be on target, at 50%, 50% will be on target, so on and so forth.
: There might be some additional weird "random drift" that makes 100% and higher accuracy still miss. *Shrugs*. - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: I am absolutely convinced that there is no "was shot accurate?" check. If there was one, I reckon it'd be apparent on the graphs here. I could be wrong, but I believe I've seen no data that supports the theory. No, finding that a certain accuracy rating "seems right" when firing from a certain distance is not supporting data, in that this is the case regardless of whether an "accurate shot" check exists. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)
: Despite the fact it will make your life even harder, I have to remind you that there is also PARTIAL COVER to factor into the tests... what happens when the target is behind a window (modded to be indestructible?), behind a hedge, only his head is visible poking out through the floor (bug here lol)... sometimes a shot will go THROUGH a window, sometimes it will HIT the window... - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: Remember, the "accuracy formula" I'm looking to determine simply returns an angle, which, dependant on your overall accuracy score an the random number generator, will go off on some who knows what direction. Whether that angle leads to the target is dependent on the visible target area versus the angles you'll get based on your accuracy stat (this "target area" concept is the purpose of the next section down, mostly unwritten because it's pointless until THIS formula is figured out).

:: That is to say, there's no real formula that can tell you the REAL chance to hit a target without actually inputting all the tile data in addition to using the "angles formula" I'm after here. Luckily, once the angle formula is determined, it shouldn't be too hard to have my battlescape editor calculate the "true" chance of a shot hitting. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)

: I wonder if it's possible that the game's maximum firing angle (e.g. at zero accuracy) is one radian - about 57.3 degrees? This is near your observed limit of 55 degrees. The game engine would probably use trig functions based on radians as I believe they are the most efficient. Given the power of the computers they were programming for, this vector work was pushing the envelope so they would need to be efficient. - [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)
::I would say that yes, given the close proximity (and the inherent inaccuracy of my logger, due to the inability to pick up on the precise ''point'' a bullet hit), one radian is correct.

::The [[COS.DAT]] page will probably be relevant at some point, dunno if you've read that. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Also could you clarify the axes on these 2 graphs/histograms? I'm having a lot of trouble understanding them. Is it possible that the vertical axis should be frequency, and the angle should be on the horizontal axis? Or am I being dumb? If I'm understanding them correctly, we are not seeing a linear distribution of error angles - as you would get from say

ActualAngle=AngleToTarget+(rand(57)-(57/2))

:what we are getting is angles that cluster together near the correct aimpoint, and frequency falls off quickly as you move away from the correct aimpoint.

:: You are reading the charts correctly. The vertical axis shows how often a specific angle was picked to fire along by the game, and the horizontal axis shows the angles themselves. The reason the charts are symetrical is because shots can either go to the left or right of the target (an angle of 0 means it hit). Even with 0 FFA, you're a lot more likely to send a bullet near the target then you are to send one on the maximum diverging angle - hence my statement, "I think it's an exponential equation divided by your rated accuracy". - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Guess: The graphs look not unlike a tangent or inverse tangent function. That might suggest that the firing function injects a linear amount of perpendicular drift (horizontal and maybe vertical) onto the bullet's vector. Maybe try graphing the tan() or arctan() of the data from the "zero accuracy" tests, and see if you get a horizontal straight line.

: arctan (0.5), which might be relevant if maximum "perpendicular error" is 1 map square wide per map distance unit, is 26.565 degrees, near to your value of 27.5 degrees. Arctan (0.25), which corresponding to half that "perpendicular error", half a map square wide per map distance unit (and maybe corresponding to 50% FFA????), is 14.036 degrees, again near to your value of 17 degrees for 50% FFA. But only 'near', and higher. Hmm. Your data have a horizontal granularity of 1/16th of a map square distance unit, is that right? So there could be some data slightly outside the true upper limit for angles. It depends on the range to your target in your test setup I guess. [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)

:: This is where my brain starts to melt, mind you, it's 3:15am here so I'm probably not good for any number crunching right now. But I reckon you're onto something even if I can't wrap my brain around what!

:: I put the target about 25 squares back (middle of the map). Really can't remember. Ideally I'd've set him to be a pixel in size, but back then the "using LOFTemps for unit size" thing was just a theory I had, not a proven fact (I never got around to updating this page when it WAS proven, that's how long these notes have been here).

:: Yes, granularity is a 16th of a standard user-visible map tile. On the horizontal plane anyway. Can't remember if I set it to 24ths on the vertical, but I probably did. The problem is, of course, that it can only pick up data according to whether a bullet hit a tile or not (as opposed to data on where the tile was hit), so although the range of angles should be "close to accurate" there's still those nasty steps everywhere which have to be "guesstamated".

:: I never really bothered much with the vertical data as I was mostly "proving the concept", figured I'd get to that later. I know I logged it (I was even able to draw an ellipse to show where all the bullets would fall, your maximum vertical angles are of course no where near your maximum horizontal ones), but I can't find the charts in concern. They weren't that good anyway as the test map had no ceiling.

:: I distinctly remember logging and graphing the 100% FFA data but can't find that either. Probably deleted it from my system (in the misguided belief that I'd uploaded it all here). I cannot find any of my related logs at all, in fact, just a single zip file with the logger, test map and automated script file ready to go. Again, this may be because I've deleted them, or because I have nearly ten thousand files in my UFO directory. My main one, anyway. I have a few such directories. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

: OK. The curve you graph above for "zero accuracy" looks not unlike what happens if you graph tan(x) (in degrees), where x is from +0.5 to +0.5. But I think that's a coincidence, since your graph is not a standard histogram - you are showing "frequency" by the length of lines on the x axis, rather than by the height of bars along the y axis as in a standard histogram. In order to turn your graph into a standard histogram it would need to be more or less inverted I think.
: The link to the "zero accuracy" data set is broken now. From what you said above, the data is lost now, which is a shame as it would be nice to do a histogram of tan(a) for all the angles "a" in that data set. You might see a flat line, linear distribution. Or not. If the angles are "bunching up" in frequency toward the target centre, then that suggests a ''linear perpendicular'' distribution of angles. With a linear perpendicular distribution (eg varies by +/- 0 to N units, perpendicular to the path to target, per unit of distance), you would expect a "bunched" angular distribution, i.e. if you sorted all the angles in the data set, the separation between one angle and the next widest would steadily increase.
: The Z component is going to complicate things and prevent finding an exact solution. For example, say that the Z (vertical) error/cone and X (lateral) error/cone are not independent of each other. For example, they might be constrained to add up to some constant N that's related to FFA: Z + Y < N. Or in fact, it might be more like (vertical x 4 + horizontal x 1) < N (since we suspect the actual 'bullet group' is an oval, wider than it is high, rather than a circle). A circle is almost the simplest case, but again unless Z and X are totally independent, you're not going to find a close fit for the function without knowing both terms. Hopefully the oval is very 'flat' and so the horizontal-only function will be a good enough approximation of the data to get in the right ballpark. Or even better, maybe the Z component is a totally independent function. Hope so.
: Let me make a prediction or a series of predictions then for maximum angle off-target:
:* 0% FFA = 1.0 perpendicular error per unit distance = +/ 0.500, arctan(0.500) = +/- 26.6 degrees
:* 50% FFA = 0.5 perpendicular error per unit distance = +/ 0.250, arctan(0.250) = +/- 14.0 degrees
:* 75% FFA = .25 perpendicular error per unit distance = +/ 0.125, arctan(0.125) = +/- 7.1 degrees
:* in general, horizontal maximum angle off target = +/- arctan(((100-FFA)/100)/2)
: Well that's most likely wrong but it's good to have a starting point for testing! [[User:Spike|Spike]] 17:40, 15 March 2009 (EDT)

Hey, guess what? First thing on completing a fresh round of tests, I discover all my old logs.

Of course.

Originals (with no roof on the map so the vertical shot data is a bit iffy): [[User_talk:Bomb_Bloke:0acc1|0%]] - [[User_talk:Bomb_Bloke:25acc1|25%]] - [[User_talk:Bomb_Bloke:50acc1|50%]] - [[User_talk:Bomb_Bloke:75acc1|75%]] - [[User_talk:Bomb_Bloke:100acc1|100%]]

New data (with a roof, vertical shot data might actually be worth something): [[User_talk:Bomb_Bloke:0acc2|0%]] - [[User_talk:Bomb_Bloke:25acc2|25%]] - [[User_talk:Bomb_Bloke:50acc2|50%]] - [[User_talk:Bomb_Bloke:75acc2|75%]] - [[User_talk:Bomb_Bloke:100acc2|100%]]

Comma separated data, one shot per line. First three columns are the absolute tile x/y/z co-ords of where the shot ended up hitting (keeping in mind the shooter is at tile 24/49/2). Next three columns are the x/y/z of where the shot landed, relative to where the shooter is. Final two columns are the important ones, they cover the horizontal and vertical angles the shot took, respectively.

Yes, the wiki doesn't represent it very neatly. Use the edit button to get the line breaks back.

Hrm. Looks like the max angle at 75% comes out to 11.53 degrees... Not 7.1. :(

- [[User:Bomb Bloke|Bomb Bloke]] 09:37, 18 March 2009 (EDT)

----

[[image:BBFiringPointTest6.png|thumb|200px]]
Here is a graph that somewhat better displays the results of my initial 0FA results. The blue line represents the recorded numbers (2550 different values). The red line represents an equal number of results generated by the spreadsheet formula "SIN(RAND()*1.5)*28.64788975*IF(RAND()>0.5;-1;1)".

(Which is, effectively, "The sine of a random number between -1.5 and 1.5 multiplied by half a radian").

Unfortunately the two formulas don't line up (even if you mirror 'em on the diagonal), but they're fairly close. Much closer then the exponential equations I tried graphing, at any rate. I'm thinking I might be able to get something better still with TAN, but I don't seem to be having much luck with that...

- [[User:Bomb Bloke|Bomb Bloke]] 02:18, 15 April 2009 (EDT)

: tan eyeballs great if you assume the distribution going in is some flavor of "sum of linear distributions". tan-1(25°)=0.466307658155; halving this and taking the tangent again gets me ~13.1°, which is reached about 1/16th of the way across. I'm assuming some sort of discretization error for the asymmetry. (My initial gut reaction was "sum of two linear distributions", but that isn't correct; that would have landed about 1/8th of the way across. The quick-and-dirty way to fake a bell curve is to sum three linear distributions.) -- [[User:Zaimoni|Zaimoni]] 11:52, 15 April 2009
(CDT)

: Per geometric check; tan works if the incoming angle is from a sum of three linear distributions. That is: tan(K*rand()*rand()*rand()) should recover the graph up to discretization error, for some K. -- [[User:Zaimoni|Zaimoni]] 12:02, 15 April 2009 (CDT)

:: Is there any chance it's some function of (Kx rand(x), Ky rand(y), Kz rand(z)? [[User:Spike|Spike]] 17:53, 15 April 2009 (EDT)

::: It depends on what you mean...

::: I was presuming rand() was a zero-parameter function that needed "massaging" to get to any range other than its default. C rand() would be 0..RAND_MAX. XCOM almost certainly has a wrapper that returns values in a range 0..N. Given when XCOM was written, I don't think it has any sort of floating-point RNG. I wrote K to subsume all of the range-massaging that was needed.

::: That said, a general sum of three linear distributions would have been tan(K1*rand()+K2*rand()+K3*rand()-AVERAGE) [ignoring overflow issues], where AVERAGE is the statistical average expected from K1*rand()+K2*rand()+K3*rand(). The geometric check almost certainly wouldn't pass if the three constants were obviously distinct. The actual expression I'd try retrofitting is tan(K*(rand()+rand()+rand())-AVERAGE). -- [[User:Zaimoni|Zaimoni]] 14:07, 16 April 2009 (CDT)

:::: If rand() was to receive any parameter at all, it'd be a seed; but calling the function three times should result in three different numbers anyway (typically you seed the RNG first). I'd be surprised if even the original game didn't have a floating RNG. Even back on the Spectrums/Commodores/BBCs you could generate within most any range by typing something like RNG*N. I tried graphing TAN(RAND()*1.5) then TAN(1.5*(RAND()+RAND()+RAND())-2.25), though the first formula wasn't right and the second was worse. :( It's a bit too steep (a little like what you get from 1/x but flopped around). Maybe something a bit higher then 1.5 would sort that out, but I dunno how high you can legally go with TAN? - [[User:Bomb Bloke|Bomb Bloke]] 20:36, 16 April 2009 (EDT)

::::: tan goes unbounded at ±π/2 radians i.e. ±90° Given that the initial bounds appear to be ~±25°, I'd calibrate things so that we were looking at a total span of 50° i.e. ~0.872 radians. In radians, with rand() being a uniform distribution 0..1: TAN(0.872*(rand()+rand()+rand())-0.436) would be my guess.

::::: XCOM 1.2 had some source code comments indicating that the C source targeted Watcom C. That means the "easy rand" available is the C standard library rand(), which without processing returns an integer from 0..RAND_MAX, where RAND_MAX may be as low as 32,767. -- [[User:Zaimoni|Zaimoni]] 12:36, 17 April 2009 (CDT)

: 55 degrees horizontal deviation range corresponds to 440 1/8 degree units; quick-but-lousy-RNG C source for the eighths-of-degrees input to the tangent function at accuracy 0 should be <code>(rand()%147+rand()%147+rand()%147)-219</code> . This plausibly is from a "deviation output" function that returns 73 at accuracy 0, 45 at accuracy 50, and 31 at accuracy 75. Corresponding psuedocode:
<pre>const int tmp = acc_func(...);
const int rng_scale = 2*tmp+1;
const int rng_bias = 3*tmp;

....

(rand()%rng_scale+rand()%rng_scale+rand()%rng_scale)-rng_bias;</pre>

: -- [[User:Zaimoni|Zaimoni]] 13:58, 26 December 2010 (CST)

: That means the deviation output function should be something like <tt>73-INT(14*Accuracy/25)</tt>. -- [[User:Zaimoni|Zaimoni]] 14:31, 26 December 2010 (CST)

::[[image:acc50zaitest.png|thumb|200px]]That's pretty good, I reckon you've nailed the angle caps, probably perfectly - though the "average" values returned by the final formula are still somewhat out of sync with those observed. Here's a graph comparing the two at accuracy 50. On average, the game is getting more shots going along at a 0 (or near 0) degree angle (shown in the red, in case the jagged mess doesn't make it obvious ;) ), whereas the formula is getting the same spread (of course) but with far more "misses" overall. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:18, 28 December 2010 (EST)

::: I'll have to cross-check that graph of the theoretical curve. Thing is, since I play with the projectiles in slowest-speed possible by default I'm pretty sure that I'm not getting 50% perfect shots at 50% accuracy. That would be the snap impression from the current graph: 50% perfect shots, 50% deviated shots. -- [[User:Zaimoni|Zaimoni]] 18:15, 28 December 2010 (CST)

:::: I'm getting a flatter candidate theoretical distribution than your graph, but not as flat as the empirical graph. Much depends on the exact rounding/truncating behavior.

:::: I see that the graph has steps at the 1° points; the theoretical distribution being considered is in steps of 1/8°.

:::: The simplest classical approximation at range 40 for an on-axis shot at a north wall (due north of the firer; corresponding range for due south of the firer is range 41), would read any horizontal error angle with absolute value less than arctan(1/81) ~ 0.7073° as perfect. The corresponding candidate theoretical rate (for shots with error between -5/8° and 5/8° inclusive) is approximately 9.05%.

:::: A better classical approximation would use the actual origin of the shot in voxelspace, rather than the impossible midpoint. -- [[User:Zaimoni|Zaimoni]] 19:41, 28 December 2010

::::: Two problems with the above.

::::: First, the firing origin for due north has been measured: it's (8,1). That means the fast approximation would have been arctan(1/80) [which numerically doesn't change anything].

::::: To set up the classical approximation at range 40 due north, the actual arctangents needed are -arctan(8.5/(16*40)) and arctan(7.5/(16*40)) [these correspond to the west and east edges of the north wall section]. Numerically, this is ~ -0.7609° and ~ 0.6714° . That is, the actual corresponding theoretical error rate is for shots with error between -3/4° and 5/8°, which is approximately 9.87%. -- [[User:Zaimoni|Zaimoni]] 20:14, 28 December 2010

: Just realized that the targeting center should be (8,8) (all of the [[LOFTEMPS.DAT]] templates used by units are centered there). -- [[User:Zaimoni|Zaimoni]] 20:19, 30 December 2010

 
===Vertical Error vs Horizontal Error===

Hmmm.... I don't know about you guys, but I notice that in my games, when firing from Level 0 at enemies on level 0, my soldiers seem like their vertical deviation tends to be very small, even with high inaccuracy. Their horizontal deviation seems much much larger. Is this my imagination?

- [[User:Jasonred|Jasonred]]

----

You're quite right, they're two different things. There's enough error there to miss at point blank range against a short target, but still nothing like what you get in the horizontal scheme of things.

- [[User:Bomb Bloke|Bomb Bloke]] 08:46, 17 April 2009 (EDT)

== Target Size ==

Units are cylinders, made up of a [[LOFTEMPS.DAT]] layer determined by [[UNITREF.DAT|UnitRef[48]/[52]]], stacked according to their [[Height]].

The full purpose of UnitRef[52] is still in doubt, though it always seems to mirror the value held at [48]. My personal guess is that one is (or at least, was supposed to be) used when bullets come in on one angle, and the other value is used when bullets come in on a perpendicular-ish angle (hence allowing the cylinder to act more like a squished tube, which is closer to the shape of a real person - or it would do if 48/52 didn't always match).

So, yeah, set [48] to 0, all your units get set to an empty LOFTemps record, they cannot be seen/hit by the aliens. Hurrah.

== See Also ==

Pages relevant to this subject:
*[[Firing Accuracy]]
*[[Accuracy formula]]
*[[Firing Accuracy Testing]]
*[[Height]]
*[[LOFTEMPS.DAT]]

UNITREF.DAT

2010-12-31T01:58:47Z

Zaimoni:

UNITREF.DAT has a row width of 124 bytes for UFO, 132 for TFTD. Bytes are unsigned, except for Missions and Kills. Some bytes represent bitfields. There are 80 records (not all of them necessarily used) for a fixed file size of 9,920 bytes (or 10,560 for TFTD). The same format is used by the files [[UNIREF.DAT]] and [[UNIREF2.DAT]]. These are images of UNITREF.DAT saved in [[Saved_Game_Files#Missdat_Files|MISSDAT]] as of, respectively, the beginning of the last "live" combat game (i.e., not loaded from a savegame) and the last finished combat.

Values are presented according to byte offset (0 to 123) followed by the equivalent hex offset (00 to 7B) in bold. Notes only apply to UFO (as opposed to TFTD) unless otherwise stated. Let us know what else you can find!!

== Structure ==
'''0 / 00:''' Type of unit. Unit scream and movement sound effects are based on this and gender. Gender and flying abilities affect the sprites as well. Not turrets. Specifically: [53] & [54] (weapons in hands), [115] (gender) and [120] (other flags) affect the final screen image. If the unit is a large unit, this will also determine the appearance of the last three quarters of the unit. This does NOT affect: the flying ability of the unit, the soldier image in the inventory screen, or the special abilities for certain aliens.
UFO TFTD
0: Male/female unarmored X-COM soldier 0: Male/female unarmored X-COM diver
1: Male/female personal armor soldier 1: Male/female plastic armor diver
2: Power/flying suit soldier 2: Power/flying suit diver
3: Tank 3: Tank
4: Sectoid 4: Aquatoid
5: Snakeman 5: Gillman
6: Ethereal 6: Lobster Man
7: Muton 7: Tasoth
8: Floater 8: Calcinite
9: Celatid 9: Deep One
10: Silacoid 10: BioDrone
11: Chryssalid 11: Tentaculat
12: Reaper 12: Triscene
13: Sectopod 13: Hallucinoid
14: Cyberdisc 14: Xarquid
15: Male civilian 15: Male civilians
16: Female civilian 16: Female civilians
17: Zombie 17: Zombie
18: Unused (but it made the sound of a tank?) 255: Unused
255: Unused

<blockquote>If the corresponding [[UNITPOS.DAT]] record is unused, then the record is unused.</blockquote>

'''1 / 01:''' Inventory paper doll image. File "UFOGRAPH\MAN_"+(char)(value + 48)+".SPK" will be used as the inventory sprite, unless the value is 0 or 1. In those cases, unitref[115] and unitref[116] are used to determine the picture.
0: No armor.
1: Personal armour.
2: Power suit.
3: Flying suit.

'''2 / 02:''' Bitflags. NKF: Seems to be consistent with different character models. ''MTR:'' I pulled those out of Hobbes' savegame (see Note 4). There seems to be some differences. Could it be a dynamic byte instead of e.g. static relative to model or whatever?
87654321
NKF: 00100100 36 Floater
10000000 128 Personal armour
10001100 140 Power suit/flying suits
11101000 232 Reaper
''BB:'' 00010000 16 Hovertank/Plasma
00111000 56 Psi unlocked soldier in flying suit
00110000 48 Psi locked soldier in kevlar
01010000 80 Aliens
01010100 84 Cyberdisc
''MTR:'' 00000100 4 Celatid
00100100 36 Chryssalid, Civvie, Ethereal, Floater, Muton, Snakeman,
11011100 220 Sectoid PA Soldier, Tank/Laser
11111000 248 Silacoid

( 1) 1: ?
( 2) 2: ?
( 4) 3: Common to Cyberdiscs
( 8) 4: Common to flying suits
( 16) 5: Common to all units
( 32) 6: Common to X-COM troopers
( 64) 7: Common to all enemies
(128) 8: ?

'''3 / 03:''' Bitflags:
87654321
''NKF:'' 00101110 46 Pers. armor
10000101 133 Floater
10111111 191 PS/FS
11101100 236 Reaper
''BB:'' 00100100 36 Psi locked soldier in kevlar
01010000 80 Hovertank/Plasma
10000001 129 Cyberdisc
10100101 165 Aliens
10110101 181 Psi unlocked soldier in flying suit
''MTR:'' 00000000 0 Chryssalid ''- from Hobbes' savegame''
00000100 4 Celatid
00100000 32 Floater
00110000 48 Muton, Snakeman, Tank/Laser
01110101 117 Sectoid
10100000 160 Ethereal
10110000 176 Civilian, PS (Power Suit) Soldier

( 1) 1: ?
( 2) 2: ?
( 4) 3: Small units
( 8) 4: ?
( 16) 5: Flying X-COM units
( 32) 6: Small units
( 64) 7: ?
(128) 8: ?

'''4 / 04:''' Possible bitflags.
87654321
''NKF:'' 10010001 145 PS/FS
10011011 155 PA Soldier, Floater, Reaper
''BB:'' 01100001 97 Hovertank/Plasma, Psi unlocked soldier in flying suit
01100010 98 Psi locked soldier in kevlar, Cyberdisc, Aliens
''MTR:'' 00100000 32 Silacoid ''- Hobbes' game''
00100100 36 Celatid, PA Soldier, Tank/Laser
00100101 37 Civilian, Muton, Snakeman
01010011 83 Sectoid
01011111 95 Chryssalid, Ethereal, Floater

'''5 / 05:''' Flags 1 for units in play, 0 otherwise. Possible bitflags.

'''6 / 06:''' Possible bitflags.
87654321
''NKF:'' 00000000 0 Reaper
00010000 16 Pers. armor
00100000 32 PS/FS
01010000 80 Floater
''BB:'' 01000000 64 Psi unlocked soldier in flying suit
01010000 80 Hovertank/Plasma
11000100 196 Aliens
11010100 212 Cyberdisc
11101000 232 Psi locked soldier in kevlar
''MTR:'' 00000100 4 Chryssalid '' - Hobbes' game''
01000000 64 Floater
10000100 132 Muton
10000100 132 Snakeman
10010100 148 Ethereal
10011000 152 Tank/Laser
10011100 156 Soldier psi locked in a power suit
10101000 168 Celatid
10101100 172 Sectoid
11011000 216 Civilian
11100100 228 Silacoid

( 1) 1: ?
( 2) 2: ?
( 4) 3: Enemies
( 8) 4: ?
( 16) 5: Large units
( 32) 6: ?
( 64) 7: Always flagged?
(128) 8: ?

'''7 / 07:''' NKF:
87654321
''BB:'' 00000000 0 Hovertank/Plasma
00010000 16 Cyberdisc
00010001 17 Psi unlocked flying suit troopers
00101011 43 Sectoid
00101101 45 Psi locked kevlar troopers
''MTR:'' 01001110 78 Chryssalid, Floater ''- Hobbes' game''
01111011 123 Tank/Laser
01111100 124 PA Soldier
01111101 125 Sectoid
01111110 126 Civilian
11001011 203 Ethereal
11011111 223 Celatid, Silacoid
11111011 251 Muton, Snakeman

( 1) 1: Small units
( 2) 2: Small aliens
( 4) 3: Psi locked kevlar troopers
( 8) 4: ?
( 16) 5: ?
( 32) 6: ?
( 64) 7: ?
(128) 8: ?

'''8 / 08:''' Same for all units? (171) (11000011)
87654321
''MTR:'' 00010011 19 Celatid, Silacoid ''- from Hobbes''
00011110 30 Civilian, Muton, Snakeman, PA Soldier, Tank/Laser
01001110 78 Sectoid
01011001 89 Chryssalid, Ethereal, Floater

''Zaimoni:'' Bit 3 (significance 4) sometimes changes during alien turn/patrol AI.

'''9 / 09:''' Always 0?

'''10 / 0A:''' Unit facing. Does NOT control HWP turret direction; see [024].
0: North (up right)
1: Northeast (right)
2: East (down right)
3: Southeast (down)
4: South (down left)
5: Southwest (left)
6: West (up left)
7: Northwest (up)

'''11 / 0B:''' Movement type. When entering a given map location, each tile is checked to see the TU requirements accordingly. [[MCD]][39+UnitRef[11]] is the offset used. Note: By default, this is 0 for ALL unit types.
0: Walking
1: Sliding
2: Flying

'''12 / 0C:''' Current TUs

'''13 / 0D:''' Current Health. Health of 0 = Dead. Compare [42], [120].

''For my [[Talk:Bravery|Bravery experience point testing]], I killed 15 of 16 aliens by setting this to zero, and my soldiers to 0 Morale. When I loaded the savegame, the aliens were still "alive" (i.e., up), then all died when I ended this turn. So death is probably only checked when injury happens, and at end of turn... to truly kill them dead on the ground through savegame editing must take more. And arg - when they all died, my soldiers all went to 100 Morale! So I edited them back to 0 Morale. But guess what... then all the aliens died '''again''' at the end of '''next''' turn, even though they were all on the ground (I heard screams, and all soldiers' Morale went to 100 again). What the heck? The aliens stayed down after that, though. --[[User:MikeTheRed|MikeTheRed]] 16:01, 3 November 2006 (PST)''

''Update: [[UNITPOS.DAT]] offset 10 bit 2 should be used to kill a unit entirely dead. Thanks, NKF & BB - MTR''

: ''While the game kills characters when Health<=Fatal Wounds (__ dies message), XComUtil will recover them based if their health is greater than 0. Haven't tested an unmodified game. --[[User:Zaimoni|Zaimoni]] 11:52, 14 April 2007 (CDT)''

'''14 / 0E:''' Current Stun level ''how much falloff of paralysis every turn? What determines it?''

'''15 / 0F:''' Current Energy

'''16 / 10:''' Current Reactions ''NKF: affected by health percentage''

'''17 / 11:''' Strength

'''18 / 12:''' Current Front Armour

'''19 / 13:''' Current Left Armour

'''20 / 14:''' Current Right Armour

'''21 / 15:''' Current Rear Armour

'''22 / 16:''' Current Under Armour

"Base" means the original (total) value (as carried forward from geoscape) - Also see Note 1 re: Base soldier stat values.

'''23 / 17:''' Base Firing accuracy. Current value = this * [013]/[026] (percent health)

'''24 / 18:''' Base Throwing accuracy. Current value = this * [013]/[026] (percent health)

Note: Tanks (turreted units?) always have 0 throwing accuracy. They use this for turret facing, relative to unit facing. 0 means it's facing forwards. Additional values are clockwise increments; see [010].

'''25 / 19:''' Base TUs

'''26 / 1A:''' Base Health

'''27 / 1B:''' Base Energy

'''28 / 1C:''' Base Reactions

'''29 / 1D:''' Base Front Armour

'''30 / 1E:''' Base Left Armour

'''31 / 1F:''' Base Right Armour

'''32 / 20:''' Base Rear Armour

'''33 / 21:''' Base Under Armour

''These Base Armour values are used to show the starting armor value in the Attributes screen (so you can readily see if it's been damaged''

'''34 / 22:''' Always 0?

'''35 / 23:''' Energy to recharge each turn. Equals '''recruit initial''' TUs/3 ([[SOLDIER.DAT]][43], '''not''' total base TUs). This is a signed byte. See [[Time Units]] and [[Energy#Usage|Energy Usage]]; also see [45] (energy usage when walking/turning). ''BombBloke: Is this affected by damage?''

'''36 / 24:''' Always 0?

'''37 / 25:''' Psi skill. Psi stats not displayed/usable until this is greater then 0.

'''38 / 26:''' Item to create when unit is unconcious/dead (index into obdata.dat).

NKF: If you set this value to that of a usable item, the item that is created in place of the unconscious or dead soldier can be used like the ordinary item. Elerium pods, for example, can be recovered for 50 elerium each after the battle. Weapons can be used as you normally use them, etc.

For unconscious 'units', the item will be treated as the unconscious body - it will retain the name of the unconscious unit when looked at via the inventory screen. Picking up and using the 'item' will work, but when the unit wakes up, the 'item' image in the soldier's hands is not cleared, even though the item no longer 'exists' in the soldier's hands. Using this 'item' will just crash the battlescape.

Actually, I do not even want to think about what would happen if you 'prime' a grenade/stunned body.

'''39 / 27:''' "Soldier value" a.k.a. victory points. You gain (or lose, as the case may be) score at the end of combat according to this value when the unit dies.
*For X-COM units: A soldier with 42 will be worth -42 points if killed. Note this doesn't seem to apply if the soldier is killed when unconscious. The soldier just vanishes.
*For aliens: A commander with 35 will give you +35 points if killed.
*This value is the same as [[SOLDIER.DAT]] bytes 15-16 (a Word) and equals:
20 + Missions + Rank Bonus

with [[Rank]] Bonus as follows: SGT +1, CPT +3, COL +6, CDR +10
Note that although this equation holds true, the value is not actually computed per se. Instead, 1 is added directly to it each mission, as is a rank-bonus delta if you advance (e.g. COL to CDR, delta +4). In other words, hacking the Missions or Rank fields does not affect this value.

'''40 / 28:''' Index into [[SOLDIER.DAT]], so game knows what to update. 255 = does not belong to anyone (i.e., it's not a soldier). ''NKF: This byte is critical for player controlled units. If this doesn't refer to anything, the unit ceases to exist at the end of the game. If it points to a valid soldier entry in soldier.dat, the soldier.dat entry will be updated.''

'''41 / 29:''' ''BombBloke:'' Something to do with large units. Changes during gameplay. Have seen values of 2, 3, 5, 6.

'''42 / 2A:''' Rank. Affects morale loss and interface icon (hull for tanks). Only X-COM troopers display rank icons.
X-COM
0: Rookie ''Civvies are 0 too''
1: Squaddie
2: Sergeant
3: Captain
4: Colonel
5: Commander
255: Dead/unused

Aliens
1: Commander
2: Leader
3: Engineer
4: Medic
5: Navigator
6: Soldier
7: Terrorist
255: Dead/unused

Hull shape for X-COM tanks:
0: Treaded
1: Hover
''I don't see 255 set for three dead mutons in a current game... [13] (Health=0) seems to be the only reliable death indicator for them. Compare [120]. -[[User:MikeTheRed|MikeTheRed]]''

'''43 / 2B:''' 0 or 1? In Hobbes' savegame, civvies and sectoids are 1. All others are 0 (soldiers, aliens, terrorists, tank).

''MTR: If the next byte is "aggression", and civvies and sectoids have a 1 here, could this be "cowardliness"? Likelihood to panic; to do something dumb/random? We've all seen civvies running around in a mad / random panic.''

'''44 / 2C:''' Alien aggression. The higher it is, the less likely an alien will take cover. Maximum of 2. ''MTR: This is true for aliens in Hobbes game, but soldiers have values from 4 to 254. Garbage? Delete this comment if so.''

'''45 / 2D:''' Used to calculate energy loss when walking or turning as: INT( TUs / 2[45] ). See [[Energy#Usage]]; compare [35] (energy recharge per turn). Set this byte to 4 to ensure no energy use whatsoever (maximum map [[Time Units#Time_Unit_Walking_Usage_Tables|tile TU cost]] is 12). ''In Hobbes game, many aliens are 0 and all soldiers are 1, but a dozen aliens have higher values ranging all the way up to 112! Garbage and/or the game doesn't care if they are garbage?''

'''46 / 2E:''' HWP turret image. Only used (and only appears) if unit type [00]=3 (X-COM tanks):
0: Cannon
1: Rocket
2: Laser
3: Plasma
4: Blaster
5,6: ? Blanks
'''Note:''' For non-tanks, this controls the inventory layout. ''Only'' 0 and 1 are valid. 0 is the standard layout seen on all soldiers. 1 is an alternate layout that may have been intended for custom tank equipment. Larger values only crash the game due to missing files. Also see [113] and [117].

'''47 / 2F:''' This is a direct copy of offset[48] from the [[MCD]] record of the tile the unit is standing on. A signed byte.

'''48 / 30:''' Values for this byte always equal [52] and are:
2 (3x3 square; legacy 5 pixels): Sectoid
3 (5x5 square, corners removed; legacy 7 pixels): Celatid, Chryssalid, Civvie, Ethereal, Floater, Muton, Snake, '''Soldier'''
4 (7x7 octagon; legacy 9 pixels): Cyberdisc, Hovertank, Reaper, Sectopod, Tank
5 (9x9 square, Ls with 3-pixel legs removed; legacy 11 pixels): Silacoid
Based on copious research by [[User:Bomb_Bloke|Bomb_Bloke]], [[User:Seb76|Seb76]], [[user:Zombie|Zombie]], and others, this has been found to be a LOF Template look-up for the shape of targets; Loftemps 2 to 5 define the "3D" shape of units relative to Line Of Fire as a cylinder, where 2 (Sectoid) is a thin cylinder and 5 (Silacoid) is very wide. The pixel width of each "silhoutte" that [[LOFTEMPS.DAT]] corresponds to has been added to the list above (see LOFTemps images 2-5). Tiles are 16 pixels wide in the X or Y direction (that's what this byte is about), and 24 pixels high (compare [49]).

This cylindrical shape is used in conjunction with height [49] to define the silhouette that targets present to a shooter. Combine the pixel-width cross-section from Loftemps with height to find the cross-sectional area presented to shooters (sorted on increasing cross-section):

LOF LOF Cross Percent
Lookup Width Height Section of 384 Float 4x?
Type ''UR[48] Pixels UR[49] Pxls X Ht (16x24) UR[51]''
---- ------ ------ ------ --------- ------- ------ ---
Sectoid 2 5 16 80 20.8% - -
Celatid 3 7 12 84 21.9% 6 -
Soldier (Kneeling) 3 7 14 98 25.5% - -
Hovertank 4 9 12 108 28.1% 6 Yes
Silacoid 5 11 10 110 28.6% - -
Snakeman 3 7 18 126 32.8% - -
Zombie 3 7 18 126 32.8% - -
Ethereal 3 7 20 140 36.5% - -
Cyberdisc 4 9 15 135 35.2% 2 Yes
Chryssalid 3 7 21 147 38.3% - -
Civilian 3 7 21 147 38.3% 2 -
Floater 3 7 21 147 38.3% 2 -
Muton 3 7 21 147 38.3% - -
Tank 4 9 16 144 37.5% - Yes
Soldier 3 7 22 154 40.1% - -
Reaper 4 9 23 207 53.9% - Yes
Sectopod 4 9 23 207 53.9% - Yes
Units take up an amount of the whole tile (as seen in cross-section by a shooter) as shown in the "Percent of 384" column. In reality, though, the [[Firing Accuracy|accuracy]] of shots makes this a more complex topic than the percents suggest. Also, dividing by 384 is an oversimplification, since it implies a directly rectangular shot (shooting right down the X or Y axis). While it's useful to see, keep in mind that this column only shows relative numbers.

: [[User:Zaimoni|Zaimoni]]: actual cross section depends on shot facing. The table is close to correct for pure diagonal shots, so leaving alone for now.

The unit Float number (Unitref[51], below) is shown simply for convenience. It does not enter into the cross-sectional computations. "4x" units actually consist of four units grouped in tight 2x2 formation (making their cross section effectively much larger then the percentage stated).

Note that causing an X-Com soldier to kneel causes their cross section to fall by 36.36~% of that of when they are standing.

'''49 / 31:''' [[height|Standing height]].

'''50 / 32:''' [[height|Kneeling height]].

'''51 / 33:''' Floating [[height]]. A unit 'floats' this high above the ground, thus allowing shots to fly underneath. The heighest point of a unit can be found by adding this to the units height stat. Does this have an effect on explosive damage?

'''52 / 34:''' Always the same as [48] in all known saved games. XCOMmies are trying to test its significance, as seen at [[Talk:UNITREF.DAT#Offsets_0x30_.26_0x34|Talk:UNITREF.DAT#Offsets_0x30_&_0x34]] ([48] and [52]).

'''53 / 35''' and '''54 / 36:''' Image index for item in left and right hand, respectively. 255 for none. Indexes into obdata.dat, not obpos.dat.

''NKF:'' If there is no item in the unit's hands, but these bytes are set, the 'image' that represents the item will still be displayed in the battlescape. If these phantom items are clicked on, the game crashes. If the image is not the right type for the real item in hand, the ammo count doesn't get displayed. Otherwise, it'll work as normal.

'''55 / 37:''' [[Damage#Susceptible_to...|Damage Modifier]] Category

This field is simply a look-up table, or more directly, a way to categorize the units into similar groups. The actual modifiers are listed in the executable. A value of 1 indicates the first DM category, a value of 4 indicates the 4th, etc. The values of 2 and 3 are not seen in the alien stats as they refer to X-COM soldier armor info. I'm not sure about 13 as the Zombie's stats haven't been found yet, but I think there is a category in the DM's for it.

'''Value''' '''Unit Type(s)'''
'''0''' Terrain and Items
'''1''' Civilian, Sectoid, Celatid, Floater
'''2''' Personal Armor
'''3''' Power Suit, Flying Suit
'''4''' Tanks, Hovertanks
'''5''' Snakemen
'''6''' Ethereal
'''7''' Muton
'''8''' Silacoid
'''9''' Chryssalid
'''10''' Reaper
'''11''' Sectopod
'''12''' Cyberdisc
'''13''' Zombie

'''56 / 38:''' [[Melee Accuracy]] ([[SOLDIER.DAT]] bytes 50 (initial) & 60 (increase) added together)

'''57 / 39:''' [[Psionic Strength]]

'''58 / 3A:''' Current [[Morale]]. Base morale is hardcoded to 100.

'''59 / 3B:''' [[Bravery]] = 110 - (10 * value)

'''60 / 3C:''' Panic mode. This takes effect at the start of the unit's next turn. Since it is cleared at that point, you'll never see it at anything other then 0 in the save files. You can manually change it to other values to force a specific panic attack on the next turn.
0: None
1: Freeze
2: Running
3: Berserk

'''61 / 3D:''' Unitref[062] will increment by this amount whenever the unit moves.
3: Sectiod ''- Hobbes''
4: Soldiers, civs, and all other aliens (but Hobbes had no Large aliens)
30: Tank/Laser

'''62 / 3E:''' Visibility via motion scanner. The bigger it is, the bigger the blip. Test this one out for values.

'''63 / 3F:''' Number of [[Fatal Wounds]] to head.

'''64 / 40:''' Number of fatal wounds to torso.

'''65 / 41:''' Number of fatal wounds to right arm.

'''66 / 42:''' Number of fatal wounds to left arm.

'''67 / 43:''' Number of fatal wounds to right leg.

'''68 / 44:''' Number of fatal wounds to left leg.

'''69 / 45''' and '''70 / 46:''' Indexes into [[ROUTES.DAT]]. To start with, aliens will be located at the same position as the node indicated by byte 69.
:For patrol AI (no X-COM units sighted in turn 1, either X-COM or alien):
::Byte 69 is the index of the node of the start of the planned move.
::Byte 70 is the index of the node of the end of the planned move.
:Note that the move may be multi-turn, and byte 69 is not guaranteed to update during a multi-turn move. I think it will if the alien ends its move on a node, however. -- Zaimoni

'''71 / 47:''' ''NKF:'' Always 16 for XCom units, 1 for cyberdisc, 0 for others? Perhaps involves mobile lighting - see the [[Talk:UNITREF.DAT#Offset_0x47|Talk]] page.

'''72 / 48:''' The amount of [[Morale]] that has been restored using the [[Medi-Kit (EU)|Medkit's]] painkillers. The amount that ''can'' be restored is equal to the maximum health of the unit (index 26) minus their current health (index 13) further minus this.

'''73 / 49:''' Intelligence. Rated from 2 - 8. Indicates for how many turns the alien will know the location of spotted soldiers. ''Hey - why do humans have zero intelligence? :(''

'''74 / 4A:''' ''NKF:'' Could be the unit spotted icon identifier? Could point to visible enemy units?

''MikeTheRed:'' XCOMs always have 0, but Mutons have values of 0-3 (usually 0 or 2, and often fluctuating) in a firing squad situation.

'''75 / 4B:''' Always 0?

'''76-77 / 4C-4D:''' Mission count. Signed integer (low byte, high byte) also found in [[SOLDIER.DAT]] ''MTR: Wonder why they bothered to put this in Unitref since this will never change '''during''' a mission; compare how soldier stats are actually read from SOLDIER (not UNITREF) on return to geoscape. Is Missions shown anywhere on the combatscape?

'''78-79 / 4E-4F:''' Kill count. Signed integer (low byte, high byte) also found in [[SOLDIER.DAT]]. Number of kills this unit has made for ALL missions, not just this one. This one '''can''' vary "unpredictably" and thus is the only byte known to directly carry forward into the geoscape / Soldier.Dat!

'''80 / 50:''' [[Reactions]] experience counter, for number of reaction shots. It doesn't matter if they hit the target; reactions still count. See Note 2 re: Experience counters. (Also note: Aliens do not use experience counters.)

''NKF:'' Where does death by fire (overexposure rather than incendiary shell impact) fit into the experience counters? It becomes a non-assigned kill, I guess, like death by wounds, or death by a grenade that hasn't got an owner?

'''81 / 51:''' [[Firing Accuracy]] experience counter, for number of hits on an enemy (lethal or not, grenades or bullets). Each Autoshot hit counts as 1, so you can get 3 hits from one Autoshot burst. Likewise, grenades and blaster bombs can hit multiple targets with one explosion. Also, if you miss the intended target but hit a different alien, it still counts. Finally, if your shot actually has zero [[Damage]], it does still count as a hit. (Not due to armor blockage; a pure roll of 0 coming out of the gun.)

'''82 / 52:''' [[Melee Accuracy]] experience counter, for number of times stun rod has been used (not stun bombs).

'''83 / 53:''' [[Throwing Accuracy]] experience counter, for number of times unit has thrown any object.

<div id="Psi_Skill_Experience_Counter"></div>'''84 / 54:''' [[Psionic Skill]] experience counter, for number of psi attacks performed. 1 is added if attempt was unsuccessful, 3 if it was successful. Note: if this value goes over 255, all psi experience is lost. That's 85 successful psis (255/3). So be careful of marathon psi'ing (a minimum of 43 turns at 2 psis/turn, 29 turns at 3/turn).

'''85 / 55:''' [[Bravery]] experience counter, for number of times unit has ''resisted'' panicking, despite Morale < 50. Being mind-controlled, panicking, or going berserk does ''not'' increase this stat -- although Panic Unit attacks will reduce Morale to the point where panic checks will be performed by the game.

'''86-111 / 56-6F:''' Unit's Name. Standard string ended by null byte. The rest can hold garbage.

'''112 / 70:''' 0; sometimes 1 for aliens.

'''113 / 71:''' If 1, then you can't use the inventory button and the unit will be immune to stun. Used for tanks. Mind controlled units don't use this but their button disables anyway.

''BombBloke:'' This is the only way to access tank inventories.
*Tank/Cannon has a normal inventory and uses man_1m0.spk.
*Tank/Rocket Launcher has a different layout and uses man_1m0.spk.
*Tank/Laser Cannon uses man_œ.spk, which doesn't exist normally. Providing this file still crashes.
*Hovertank/Plasma simply crashes.
*Hovertank/Launcher simply crashes.

UnitRef[1] actually determines the inventory screen used, might be worth playing with that. UnitRef[46] determines the layout.

'''114 / 72:''' If not 0, then unit is on fire, and will burn for this amount of turns.

'''115 / 73:''' Gender: 0 = male, 1 = female.

'''116 / 74:''' Hair/skin colour (for inventory; all other units = 0):
0: Blond caucasian
1: Brunette caucasian
2: Asian
3: Black

'''117 / 75:''' Turret weapon. Over-rides hand held weapon. Turret images are not centered; that would be impossible because they aren't all 'objects' (e.g. Celatid). ''(Mix of notes by BB and NKF)''
F.A. TUs F.A. TUs
0: HWP cannon (bigobs[40])....................Aimed 90% 80% Snap 60% 33%
1: HWP rocket (bigobs[42])....................Aimed 115% 75% Snap 55% 45%
2: HWP laser (bigobs[54]).....................Aimed 85% 75% Snap 50% 33%
3: HWP plasma cannon (bigobs[43]).............Aimed 100% 60% Snap 86% 30%
4: HWP blaster (bigobs[43]) (looks like ordinary cannon?)......Aimed 120% 80%
5: Celatid plasma cannon (bigobs[38]).........Aimed 110% 60% Snap 75% 30%
6: Cyberdisc plasma cannon (bigobs[34]).......Aimed 110% 60% Snap 75% 30%
7: Sectopod Laser* cannon (bigobs[34])as cyberdisk, above, plus Auto 50% 35%
22: Invalid - Incredibly powerful armour piercing shell. Overpowering.
255: Unused
Note: This item will take precendence over any item carried in the hand slots. It can be installed on non-tanks, but then the unit won't be able to use any carried weapons or items. This weapon is NOT affected by the kneeling modifier, but it is affected by the current unit's accuracy stat. Also note, this byte does NOT determine the turret image for HWPs in the battlescape.

[*]The damage type for the Sectopod is indeed set to (3)laser in the executable! Graphical/sound effects of a turret weapon is set there as well, via a reference to a weapon in OBDATA.DAT (HWP Cannon=4=Heavy Cannon, Sectopod=34=Heavy Plasma) ''When I changed HWP Cannon to 2, it looked/sounded like rifle fire - Crus8r''

Also see [46], [113], and [118].

'''118 / 76:''' Ammo for [117] turret weapon

'''119 / 77:''' Movement related? Large unit related? Possible bitfield.
''MTR:'' 00000000 0 Chryssalid(2), Civilian(9), Ethereal(2), Floater(2), Muton,
00000001 1 Muton, PA Soldier(2) Sectoid(2), Silacoid(2),
00000011 3 PA Soldier PA Soldier(2), Tank/Laser
00000101 5 Snakeman
00001010 10 Celatid ''- Hobbes game - could have some garbage''
00001101 13 Muton, PA Soldier '' (parens) is count, if more than 1 unit''
00010011 19 Snakeman
00100110 38 PA Soldier
00101010 42 Muton(3)
00110001 49 Muton
00110010 50 PA Soldier
00110101 53 Silacoid(2)
00111011 59 Celatid
00111111 63 Silacoid
01001110 78 PA Soldier
01100111 103 PA Soldier
01111111 127 Muton
10010000 144 Muton
11000000 192 Celatid
11111110 254 Muton

'''120 / 78:''' Unit bit flags, mainly re: mobility. They do NOT affect the soldier in inventory screen: ''(Mix of notes by BB and NKF)''
( 1) 1: 1 = Dead. ''This was only set for 2 of 3 dead aliens in my current game.''
''[13] (Health=0) is the most reliable indicator for me. -[[User:MikeTheRed|MikeTheRed]]''
( 2) 2: 1 = Unit can fly.
( 4) 3: 1 = Unit is flying. (Toggles leg sprites for power armour.)
( 8) 4: ??? Seems to flag if the unit has been selected this turn.
( 16) 5: 1 = Unit has been disabled for selection.
(Stops the unit tab button from selecting this soldier.)
( 32) 6: 0 = Unit has left hand object selected, 1 = right hand object selected.
( 64) 7: 1 = Unit is kneeling.
(128) 8: 1 = Unit is wearing power/flying suit. (Can't be stunned by smoke flag?
Seems to work for fire, too.)
If a unit is carrying something in either hand, it is impossible to get him to appear as if he is carrying nothing - in the game, at least. If he is carrying nothing, bit 6 can flag (as though the unit was using it's right hand item). But maybe it's just the order of dropped items affecting this?

Note: A unit is only considered as flying if it is not on the ground. For example, a hover tank is not always considered as flying.

What if a hovertank is half on the ground, half in the air? What about a treaded tank, or large alien unit? What about units in lifts?

'''121 / 79:''' Possible Values: 0 or 16. All units in unitref.dat get a value of 0 except for the second unit in the list which gets 16. Doesn't matter if the second unit is a soldier, a tank, or an alien. It's always 16. Editing it to 0 doesn't crash the game or have any dire consequences.

'''122 / 7A:''' Always 0?

'''123 / 7B:''' Always 0?

'''124 / 7C:''' - TFTD ONLY - Appears to be a count as to which frame of bubbles the soldier is on. Can be 0 to 16 (0x0F), most likely 125/7D is included with this.

== Notes ==
1) The original/base values for soldier stats (offsets 23-28, etc.) correspond to the initial+increase bytes from [[SOLDIER.DAT|Soldier.Dat]] (bytes 43-62). Changes to these Unitref bytes are lost when the mission ends; instead, XCOM re-reads them from Soldier at that time. This makes sense because base soldier stats don't change during a mission per se (although they might increase when the mission ends); in this way, the programmers didn't have to bother with separately storing and/or adding initial+increase during combat. (It's also why you don't see the initial+increase in the soldier stat display during combat, that you can see back at base.) On a practical note, if you are testing soldier stat increases versus experience counters, change the experience counters in Unitref, but change the soldier stats in Soldier. (IOW, it doesn't matter what the soldier stats are in the combat mission.)

The Kill count (offset 78-79) is the only Unitref value I know of that is directly carried forward into the geoscape and Soldier.dat. However, some others do indirectly carry forward, for example: experience (offsets 80-85) causes stat and rank increases, and decreased health (offset 26 - offset 13) means hospital time. And, of course, death is permanent. Heh.

2) Experience counters (offsets 80-85) determine the likelihood of soldier stat increases at the end of the combat mission, according to the formula for Primary Stats shown [[Experience#How_Experience_Points_Are_Applied|here]]. The Bravery counter (offset 85) affects Bravery as shown [[Bravery|here]].

Also, if at least one of the experience counters (except Throws) has a count, your secondary stats will increase, as discussed [[Experience#Secondary_Stats|here]]. All you need is at least a 1 in offsets 80-82 or 84-85; more than 1 and/or multiple counters has no additional effect.

3) BombBloke's additional "To be Done" notes - can we cross some of these off yet?

Need to research:
Stun recovery rate, does it exist?
Hand to hand attacks
<strike>Offset of weapon from unit image?</strike>
''Based on unit height and nothing else. There may be values to determine what arm sprites to use,''
''but I doubt it.''
Firing sprite offset?
''Probably just based on unit height and some hardcoded values in the executable.''
<strike>Inventory lockout?</strike> ''All mind controlled units are locked out.''
Kneel lockout?
''Probably the same as above, I seem to remember that using XcomUtil to "swap sides" would make it''
''possible to kneel small alien units.''
<strike>Aliens seen?</strike> ''Not used in unitref.dat, only in unitpos.dat. -[[User:Zombie|Zombie]] 23:48, 29 September 2006 (PDT)''
<strike>Whether a unit slides/floats/hovers/rolls/walks (movement noise)?</strike> ''Set according to unit type.''
What else? The more to look for, the easier it is...

Know 100 values.
Unknown values (24 in total):
[002] [003] [004] [005] [006] [007] [008] [009]
[034] [036] [041] [043] [052] [069] [070] [071]
[074] [075] [112] [119] [120] [121] [122] [123]

4) Hobbes posted a savegame with a TON of different aliens in it [http://www.xcomufo.com/forums/index.php?showtopic=8591 here] (message 6). Interesting for testing. But note it was made with XCOMUTIL and there may(?) be concerns over vailidity of unit info - see [[Talk:UNITREF.DAT]].

5) A [[HackerTools|Hex Workshop]] Structure Library for UNITREF.DAT created by Danial is [[UNITREF_DAT_HSL|here]].

== For More Information ==
*[[SOLDIER.DAT]]
*[[Soldiers|Soldier Stats]]
*[[Experience]]
*[[HackerTools|Hex editing]]

Return to [[Saved_Game_Files|Saved Game Files]]
[[Category:Game Files]]

Zaimoni's XCOM1 Editor

2010-12-31T01:00:58Z

Zaimoni:

[[Image:ZaiXcomSuite.0.1.zip|ZaiXcomSuite.0.1.zip]]

This set of DOS batch files and Python 2.5.x scripts is a command-line savegame editor and turn-swapping utility. You will also need the (http://www.python.org/) Python scripting language installed. Unzip into c:\mps\ufo (will need editing if the XCOM1 install is elsewhere)

The Python scripts may work with later versions of Python (tested with 2.5.0, 2.5.1, 2.5.2, 2.6.0, 2.6.4). They will not work with Python 2.4.x due to undocumented incompatible changes in the struct module, and presumably will not work with earlier versions either.

Usage:
* Soldier.py : Soldier and battlescape editor. Intended to run from the savegame directory being edited: <code>..\Soldier.py ....</code>
* Base.py : Base editor. Intended to run from the savegame directory being edited: <code>..\Base.py ....</code>
* Transfer.py : Transfer editor. Intended to run from the savegame directory being edited: <code>..\Transfer.py ....</code>
* PrepareSWP.py : Prepares a battlescape savegame for turnswapping. Run from the savegame directory to be enabled: <code>..\PrepareSWP.py</code>
* Alienturn.bat : Swaps a game from the human player to the alien player. Run from the main directory, e.g. <code>Alienturn.bat game_8</code>
* Humanturn.bat : Swaps a game from the alien player to the human player. Run from the main directory, e.g. <code>Humanturn.bat game_8</code>
* XCOM1.py : some numerical utilities for tactical analysis. Run from the main directory as <code>python -i XCOM1.py</code> (it's meant to be used in interactive mode).

AutoClose.py may also be useful for repairing savefiles with UFO doors stuck open. Run from the savegame directory to be fixed: <code>..\AutoClose.py</code>
<hr>
<tt>Base.py</tt>

<code>Supported subcommands for Base.py
unbuild_dirt:
sets days-to-completion for dirt to 255/-1 (never) at all bases. This bypasses
a bug.
fast_construction:
forces all in-construction facilities to complete at next midnight. Cheat.
instant_construction:
forces all in-construction facilities to complete instantly. Cheat. Not smart
enough to handle radars or hyperwave detectors.
overview Name:
lists all items in inventory at base Name.</code>

<tt>Soldier.py</tt>

<code>Supported subcommands for Soldier.py
list
lists soldier names in internal order.
sort:
sorts soldiers according to the function SOLDIERS_CMP.
Soldiers in transit will be left in place to prevent eliciting gross bugs.
rename OldName NewName:
renames soldier from oldname to newname. NewName will be truncated to fit, if
needed.
swap Name1 Name2:
swaps the soldiers named Name1 and Name2.
max_recruit Name:
sets recruit stats for Name to maximum. Cheat.
inactive Name:
reduces mission count and score for Name by 1. Cheat.
battlescape
military intelligence overview...vaguely like XCOMUtil DIS:2
facing [unitref index] [facing]
changes facing of target index
transpose [unitref index] [unitref index]
transposes two units on the battlescape. Unreliable in the presence of
large units.</code>
<hr>The shipped sort order is moderately useful if you want psi-weakings to soak reaction fire.

<tt>Transfer.py</tt>

<code>Supported subcommands for Transfer.py

fast_shipment:
forces all in-progress transfers to arrive at the next hour transition. Cheat.</code>

==See Also==
[[User_talk:Zaimoni]]

File:ZaiXcomSuite.0.1.zip

2010-12-31T00:53:39Z

Zaimoni: uploaded a new version of "File:ZaiXcomSuite.0.1.zip": * Fixed Base.py fast_construction option * new Base.py option instant_construction * XCOM1.py

Python-based XCOM1 savefile editor

User talk:Bomb Bloke:Firing Accuracy

2010-12-29T06:35:48Z

Zaimoni:

{{tocright}}Consider this [[User:Bomb Bloke|Bomb Bloke's]] draft/discussion about firing accuracy. This topic has been dragging on for quite some time now, so I figure it to about time I had a stab at it.

My view on the matter is this: When you fire a gun, UFO works out the horizontal and vertical angles between your unit and the target, then modifies these depending on your [[Accuracy_formula|overall accuracy stat]].

Say for example you have a perfect 100% (or better) "accuracy". The lines are nearly unmodified, and so near guaranteed to hit (assuming there are no obstructions, in which case you should get a "No LOF!" message when you attempt to fire. Note that the game doesn't ALWAYS give this message and will sometimes allow you to attempt "impossible" shots. In these cases, less-then-perfect aim might still allow the shot to land).

As your rated accuracy decreases, target size and distance become all important: As size decreases and distance increases, the range of angles that could land a hit fall. As accuracy decreases, the range of angles that a shot can take rises and so it becomes less likely that a given shot will fall within the "hitting" range of angles.

(As for why multiple angles can "hit", think of your target as a dartboard: Perfect aim would result in a bullseye, approximate aim would still hit the board, and bad aim would miss altogether. However, in X-Com, you get full "points" so long as the bullet hits the target at all).

That is to say, the ultimate firing accuracy formula would be (range of acceptable hitting angles)/(range of possible firing angles). Assuming, of course, that when firing you're just as likely to fire at your maximum "worst" angle as you are your "best", the range of angles that can hit is determined by target distance and size, and the range of angles that can be fired along is determined by your rated firing accuracy.

However, as it turns out, the angle your shots take isn't entirely random - they follow a bell curve. You're more likely to at least hit near the target then you are to get a massive "air ball" shot. So the formula in truth will end up looking a bit more complex then that.

== Firing Point Origin ==

To get the absolute range of angles a unit can fire along, you first need to know where a unit is firing from. To this end I created a copy of my game folder and modified a save game, some terrain files, and the LOF templates.

[[image:BBFiringPointTest2.png|right|thumb|200px|A basic map of a tile. As it turns out the Y axis really points the other way.]]Now, when we talk about UFO maps, we generally refer to their dimensions in terms of how many tiles there are. However, each tile is really made up of smaller "points": A 16x16x24 point space. This means that a 30x30x4 map has 3,600 tiles in it, and 22,118,400 points within those. When a unit fires, he doesn't aim from his tile at his target's tile, he aims from a point within his tile at a point within his target's tile.

This first test was aimed at discovering exactly where a shot originates from, by creating tiles on units to selectively block their LOF. By seeing which tiles did and which did not, it could be seen exactly (or, at least, as accurately as I think I'm going to get it) where the shots were coming from.

[[image:BBFiringPointTest3.png|right|thumb|200px|The Empire's got nothing on BB's clone army.]]The first row of units served as targets for the second, which stood on tiles similar to the large earth blocks you see in bases but with one layer removed from each. Each therefore entirely blocked LOF so long as the removed layer wasn't at the same height as the unit's firing origin point. The only unit able to fire through the gap was the one sitting on the tile with the third layer down removed.

However, when defining tiles with [[LOFTEMPS.DAT|LOFTemps]], you can only stack the layers 12 high. Presumably the game "double stacks" them to make the resulting 24 point high object. Because of this, the removed layers accounted for two possible Z co-ordinates, meaning the exact value there is still unknown. Might be able to work something out to get it more precise, I dunno.

The third row stood on walls facing to the east/west. Unlike the second row, in this example I moved a single thin wall through each tile, as opposed to moving a "gap". This meant that only one unit would not be able to fire, and that was the one sitting on the ninth tile (made up of my layers from LOFTemps[15]).

[[image:BBFiringPointTest1.png|right|thumb|200px|LOFtemps used, as opposed to the [[LOFTEMPS.DAT|usual set]].]]The forth row followed more or less the same concept, with the walls facing north/south. Only the first unit was unable to fire (LOFTemps[23]).

So! With this information, getting a (x,y,z) co-oridinate is easy enough: It's either (8,15,18) or (8,15,19) (the Z co-ord being imprecise due to the 12 LOFTemp layer limitation).

Note that this value only goes for units with a facing of north. When I get time I'll go through and work it out for the other directions. Furthermore, Sectoids are likely to have a lower firing point (as their guns are rendered lower on the screen).

----

[[Image:origins.png|frame]]

I found an interesting piece of code (offset 40D8E0 for the curious). The formula for the starting zpos when firing looks like this:
''unitpos.zpos*24+unitref.terrain_height-unitref.standing_height+27-unitref.floating_height''
and for kneeling units:
''unitpos.zpos*24+unitref.terrain_height-unitref.kneeling_height+27-unitref.floating_height''
(unitref.terrain_height is offset 0x27 in unitref.dat)
I did a live check with a debugger, for a standing unit on the lowest level it gives this:
''3*24+0-16+27-0=77''
Since the engine seems to use zpos=0 for the ceiling of the topmost level, then the floor must be at offset 4*24=96. floor_level-firing_level=96-77=19, in accord with your empirical results.

Now for xpos and ypos, the engine uses several tables, indexed by the facing orientation (offset 0xa in unitref.dat):
''.data:0046B5E4 dw 8,0Eh,0Fh,0Fh, 8, 1, 1, 1''
for xpos, and
''.data:0046B5C4 dw 1, 1, 8,0Fh,0Fh,0Fh, 8, 1''
for ypos. When facing north, the shot should come from 8x1x19. Note that it is in disaccord with your experience. Maybe you don't use the same point of origin as the engine? [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

You are correct. Moving my origin to match yours brings my data into line (I was limited to guessing it's correct location). Awesome to see the ceiling size confirmed at long last. :D - [[User:Bomb Bloke|Bomb Bloke]] 02:52, 8 May 2008 (PDT)

----

Big units use 2 other tables located at offsets 46B604 and 46B624. I did not try to change these values to see if it changes the position where the shots come from. [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

The xpos/ypos information agrees with my own in vivo research (it explains several LOS different than LOF paradoxes I have explicitly verified). -- [[User:Zaimoni|Zaimoni]] 11:49, 3 May 2008 (CDT)

== Rated Accuracy Vs Angle Range ==

[[image:BBFiringPointTest4.png|thumb|200px]][[image:BBFiringPointTest5.png|thumb|200px]]Just a few results before I go off camping for the weekend. First off, note that [http://www.strategycore.co.uk/forums/index.php?act=ST&f=22&t=5805 the logger] used on this occasion is one I wrote up a year ago. It's not entirely accurate, and needs to approximate values (this is because I can only get it to think in terms of angles between tiles, as opposed to angles between points - as a result you see "steps" in the line graphs provided here). I've thought up some improvements for it (like sticking a roof in the map used so I can get some decent vertical angle stats), but even if I implemented those it'd still never be "accurate".

That said, I got [http://pastebin.com/mcbc752a 2550 results for 0% firing accuracy] overnight and [http://pastebin.com/mdf60034 1876 for 50%] today. I've got the system in concern running trials for 25% until tomorrow.

The graphs displayed summarise these angles. Essentially they go from "those that went to the left" across to "those that went to the right". The longer the line stays at a given level, the more shots took that angle.

At 0% accuracy, the largest horizontal angle I got AWAY from the target was 27.5 degrees (that is to say, a shot could go anywhere within a range of 55 degrees), the average angle being 7.32 degrees. With the side graph you can get an idea of the distribution: Your shots are more likely to hit or at least get close then they are to be far away.

Bumping the rated accuracy to 50% lowered the maximum angle to 17.01 degrees (average of 2.75). Again, you're a lot more likely to get close to the target then you are to reach the possible extremes.

I've since done tests at 100% accuracy and found that the same curve exists, just squished right down. You still have a chance to miss, but only by slight amounts. A formula should be apparent in there somewhere.

At a glance I think it's an exponential equation divided by your rated accuracy? With a few more tests I suppose it'd be more apparent.

: My theory is this that the program first runs "was shot accurate?" check. If yes, then shot deviates 0 and hits the target. If shot misses, calculate path of bullet. Path of bullet follows formula that gives that bell curve.
: I rather suspect that at 25% accuracy, 25% of your shots will be on target, at 50%, 50% will be on target, so on and so forth.
: There might be some additional weird "random drift" that makes 100% and higher accuracy still miss. *Shrugs*. - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: I am absolutely convinced that there is no "was shot accurate?" check. If there was one, I reckon it'd be apparent on the graphs here. I could be wrong, but I believe I've seen no data that supports the theory. No, finding that a certain accuracy rating "seems right" when firing from a certain distance is not supporting data, in that this is the case regardless of whether an "accurate shot" check exists. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)
: Despite the fact it will make your life even harder, I have to remind you that there is also PARTIAL COVER to factor into the tests... what happens when the target is behind a window (modded to be indestructible?), behind a hedge, only his head is visible poking out through the floor (bug here lol)... sometimes a shot will go THROUGH a window, sometimes it will HIT the window... - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: Remember, the "accuracy formula" I'm looking to determine simply returns an angle, which, dependant on your overall accuracy score an the random number generator, will go off on some who knows what direction. Whether that angle leads to the target is dependent on the visible target area versus the angles you'll get based on your accuracy stat (this "target area" concept is the purpose of the next section down, mostly unwritten because it's pointless until THIS formula is figured out).

:: That is to say, there's no real formula that can tell you the REAL chance to hit a target without actually inputting all the tile data in addition to using the "angles formula" I'm after here. Luckily, once the angle formula is determined, it shouldn't be too hard to have my battlescape editor calculate the "true" chance of a shot hitting. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)

: I wonder if it's possible that the game's maximum firing angle (e.g. at zero accuracy) is one radian - about 57.3 degrees? This is near your observed limit of 55 degrees. The game engine would probably use trig functions based on radians as I believe they are the most efficient. Given the power of the computers they were programming for, this vector work was pushing the envelope so they would need to be efficient. - [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)
::I would say that yes, given the close proximity (and the inherent inaccuracy of my logger, due to the inability to pick up on the precise ''point'' a bullet hit), one radian is correct.

::The [[COS.DAT]] page will probably be relevant at some point, dunno if you've read that. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Also could you clarify the axes on these 2 graphs/histograms? I'm having a lot of trouble understanding them. Is it possible that the vertical axis should be frequency, and the angle should be on the horizontal axis? Or am I being dumb? If I'm understanding them correctly, we are not seeing a linear distribution of error angles - as you would get from say

ActualAngle=AngleToTarget+(rand(57)-(57/2))

:what we are getting is angles that cluster together near the correct aimpoint, and frequency falls off quickly as you move away from the correct aimpoint.

:: You are reading the charts correctly. The vertical axis shows how often a specific angle was picked to fire along by the game, and the horizontal axis shows the angles themselves. The reason the charts are symetrical is because shots can either go to the left or right of the target (an angle of 0 means it hit). Even with 0 FFA, you're a lot more likely to send a bullet near the target then you are to send one on the maximum diverging angle - hence my statement, "I think it's an exponential equation divided by your rated accuracy". - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Guess: The graphs look not unlike a tangent or inverse tangent function. That might suggest that the firing function injects a linear amount of perpendicular drift (horizontal and maybe vertical) onto the bullet's vector. Maybe try graphing the tan() or arctan() of the data from the "zero accuracy" tests, and see if you get a horizontal straight line.

: arctan (0.5), which might be relevant if maximum "perpendicular error" is 1 map square wide per map distance unit, is 26.565 degrees, near to your value of 27.5 degrees. Arctan (0.25), which corresponding to half that "perpendicular error", half a map square wide per map distance unit (and maybe corresponding to 50% FFA????), is 14.036 degrees, again near to your value of 17 degrees for 50% FFA. But only 'near', and higher. Hmm. Your data have a horizontal granularity of 1/16th of a map square distance unit, is that right? So there could be some data slightly outside the true upper limit for angles. It depends on the range to your target in your test setup I guess. [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)

:: This is where my brain starts to melt, mind you, it's 3:15am here so I'm probably not good for any number crunching right now. But I reckon you're onto something even if I can't wrap my brain around what!

:: I put the target about 25 squares back (middle of the map). Really can't remember. Ideally I'd've set him to be a pixel in size, but back then the "using LOFTemps for unit size" thing was just a theory I had, not a proven fact (I never got around to updating this page when it WAS proven, that's how long these notes have been here).

:: Yes, granularity is a 16th of a standard user-visible map tile. On the horizontal plane anyway. Can't remember if I set it to 24ths on the vertical, but I probably did. The problem is, of course, that it can only pick up data according to whether a bullet hit a tile or not (as opposed to data on where the tile was hit), so although the range of angles should be "close to accurate" there's still those nasty steps everywhere which have to be "guesstamated".

:: I never really bothered much with the vertical data as I was mostly "proving the concept", figured I'd get to that later. I know I logged it (I was even able to draw an ellipse to show where all the bullets would fall, your maximum vertical angles are of course no where near your maximum horizontal ones), but I can't find the charts in concern. They weren't that good anyway as the test map had no ceiling.

:: I distinctly remember logging and graphing the 100% FFA data but can't find that either. Probably deleted it from my system (in the misguided belief that I'd uploaded it all here). I cannot find any of my related logs at all, in fact, just a single zip file with the logger, test map and automated script file ready to go. Again, this may be because I've deleted them, or because I have nearly ten thousand files in my UFO directory. My main one, anyway. I have a few such directories. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

: OK. The curve you graph above for "zero accuracy" looks not unlike what happens if you graph tan(x) (in degrees), where x is from +0.5 to +0.5. But I think that's a coincidence, since your graph is not a standard histogram - you are showing "frequency" by the length of lines on the x axis, rather than by the height of bars along the y axis as in a standard histogram. In order to turn your graph into a standard histogram it would need to be more or less inverted I think.
: The link to the "zero accuracy" data set is broken now. From what you said above, the data is lost now, which is a shame as it would be nice to do a histogram of tan(a) for all the angles "a" in that data set. You might see a flat line, linear distribution. Or not. If the angles are "bunching up" in frequency toward the target centre, then that suggests a ''linear perpendicular'' distribution of angles. With a linear perpendicular distribution (eg varies by +/- 0 to N units, perpendicular to the path to target, per unit of distance), you would expect a "bunched" angular distribution, i.e. if you sorted all the angles in the data set, the separation between one angle and the next widest would steadily increase.
: The Z component is going to complicate things and prevent finding an exact solution. For example, say that the Z (vertical) error/cone and X (lateral) error/cone are not independent of each other. For example, they might be constrained to add up to some constant N that's related to FFA: Z + Y < N. Or in fact, it might be more like (vertical x 4 + horizontal x 1) < N (since we suspect the actual 'bullet group' is an oval, wider than it is high, rather than a circle). A circle is almost the simplest case, but again unless Z and X are totally independent, you're not going to find a close fit for the function without knowing both terms. Hopefully the oval is very 'flat' and so the horizontal-only function will be a good enough approximation of the data to get in the right ballpark. Or even better, maybe the Z component is a totally independent function. Hope so.
: Let me make a prediction or a series of predictions then for maximum angle off-target:
:* 0% FFA = 1.0 perpendicular error per unit distance = +/ 0.500, arctan(0.500) = +/- 26.6 degrees
:* 50% FFA = 0.5 perpendicular error per unit distance = +/ 0.250, arctan(0.250) = +/- 14.0 degrees
:* 75% FFA = .25 perpendicular error per unit distance = +/ 0.125, arctan(0.125) = +/- 7.1 degrees
:* in general, horizontal maximum angle off target = +/- arctan(((100-FFA)/100)/2)
: Well that's most likely wrong but it's good to have a starting point for testing! [[User:Spike|Spike]] 17:40, 15 March 2009 (EDT)

Hey, guess what? First thing on completing a fresh round of tests, I discover all my old logs.

Of course.

Originals (with no roof on the map so the vertical shot data is a bit iffy): [[User_talk:Bomb_Bloke:0acc1|0%]] - [[User_talk:Bomb_Bloke:25acc1|25%]] - [[User_talk:Bomb_Bloke:50acc1|50%]] - [[User_talk:Bomb_Bloke:75acc1|75%]] - [[User_talk:Bomb_Bloke:100acc1|100%]]

New data (with a roof, vertical shot data might actually be worth something): [[User_talk:Bomb_Bloke:0acc2|0%]] - [[User_talk:Bomb_Bloke:25acc2|25%]] - [[User_talk:Bomb_Bloke:50acc2|50%]] - [[User_talk:Bomb_Bloke:75acc2|75%]] - [[User_talk:Bomb_Bloke:100acc2|100%]]

Comma separated data, one shot per line. First three columns are the absolute tile x/y/z co-ords of where the shot ended up hitting (keeping in mind the shooter is at tile 24/49/2). Next three columns are the x/y/z of where the shot landed, relative to where the shooter is. Final two columns are the important ones, they cover the horizontal and vertical angles the shot took, respectively.

Yes, the wiki doesn't represent it very neatly. Use the edit button to get the line breaks back.

Hrm. Looks like the max angle at 75% comes out to 11.53 degrees... Not 7.1. :(

- [[User:Bomb Bloke|Bomb Bloke]] 09:37, 18 March 2009 (EDT)

----

[[image:BBFiringPointTest6.png|thumb|200px]]
Here is a graph that somewhat better displays the results of my initial 0FA results. The blue line represents the recorded numbers (2550 different values). The red line represents an equal number of results generated by the spreadsheet formula "SIN(RAND()*1.5)*28.64788975*IF(RAND()>0.5;-1;1)".

(Which is, effectively, "The sine of a random number between -1.5 and 1.5 multiplied by half a radian").

Unfortunately the two formulas don't line up (even if you mirror 'em on the diagonal), but they're fairly close. Much closer then the exponential equations I tried graphing, at any rate. I'm thinking I might be able to get something better still with TAN, but I don't seem to be having much luck with that...

- [[User:Bomb Bloke|Bomb Bloke]] 02:18, 15 April 2009 (EDT)

: tan eyeballs great if you assume the distribution going in is some flavor of "sum of linear distributions". tan-1(25°)=0.466307658155; halving this and taking the tangent again gets me ~13.1°, which is reached about 1/16th of the way across. I'm assuming some sort of discretization error for the asymmetry. (My initial gut reaction was "sum of two linear distributions", but that isn't correct; that would have landed about 1/8th of the way across. The quick-and-dirty way to fake a bell curve is to sum three linear distributions.) -- [[User:Zaimoni|Zaimoni]] 11:52, 15 April 2009
(CDT)

: Per geometric check; tan works if the incoming angle is from a sum of three linear distributions. That is: tan(K*rand()*rand()*rand()) should recover the graph up to discretization error, for some K. -- [[User:Zaimoni|Zaimoni]] 12:02, 15 April 2009 (CDT)

:: Is there any chance it's some function of (Kx rand(x), Ky rand(y), Kz rand(z)? [[User:Spike|Spike]] 17:53, 15 April 2009 (EDT)

::: It depends on what you mean...

::: I was presuming rand() was a zero-parameter function that needed "massaging" to get to any range other than its default. C rand() would be 0..RAND_MAX. XCOM almost certainly has a wrapper that returns values in a range 0..N. Given when XCOM was written, I don't think it has any sort of floating-point RNG. I wrote K to subsume all of the range-massaging that was needed.

::: That said, a general sum of three linear distributions would have been tan(K1*rand()+K2*rand()+K3*rand()-AVERAGE) [ignoring overflow issues], where AVERAGE is the statistical average expected from K1*rand()+K2*rand()+K3*rand(). The geometric check almost certainly wouldn't pass if the three constants were obviously distinct. The actual expression I'd try retrofitting is tan(K*(rand()+rand()+rand())-AVERAGE). -- [[User:Zaimoni|Zaimoni]] 14:07, 16 April 2009 (CDT)

:::: If rand() was to receive any parameter at all, it'd be a seed; but calling the function three times should result in three different numbers anyway (typically you seed the RNG first). I'd be surprised if even the original game didn't have a floating RNG. Even back on the Spectrums/Commodores/BBCs you could generate within most any range by typing something like RNG*N. I tried graphing TAN(RAND()*1.5) then TAN(1.5*(RAND()+RAND()+RAND())-2.25), though the first formula wasn't right and the second was worse. :( It's a bit too steep (a little like what you get from 1/x but flopped around). Maybe something a bit higher then 1.5 would sort that out, but I dunno how high you can legally go with TAN? - [[User:Bomb Bloke|Bomb Bloke]] 20:36, 16 April 2009 (EDT)

::::: tan goes unbounded at ±π/2 radians i.e. ±90° Given that the initial bounds appear to be ~±25°, I'd calibrate things so that we were looking at a total span of 50° i.e. ~0.872 radians. In radians, with rand() being a uniform distribution 0..1: TAN(0.872*(rand()+rand()+rand())-0.436) would be my guess.

::::: XCOM 1.2 had some source code comments indicating that the C source targeted Watcom C. That means the "easy rand" available is the C standard library rand(), which without processing returns an integer from 0..RAND_MAX, where RAND_MAX may be as low as 32,767. -- [[User:Zaimoni|Zaimoni]] 12:36, 17 April 2009 (CDT)

: 55 degrees horizontal deviation range corresponds to 440 1/8 degree units; quick-but-lousy-RNG C source for the eighths-of-degrees input to the tangent function at accuracy 0 should be <code>(rand()%147+rand()%147+rand()%147)-219</code> . This plausibly is from a "deviation output" function that returns 73 at accuracy 0, 45 at accuracy 50, and 31 at accuracy 75. Corresponding psuedocode:
<pre>const int tmp = acc_func(...);
const int rng_scale = 2*tmp+1;
const int rng_bias = 3*tmp;

....

(rand()%rng_scale+rand()%rng_scale+rand()%rng_scale)-rng_bias;</pre>

: -- [[User:Zaimoni|Zaimoni]] 13:58, 26 December 2010 (CST)

: That means the deviation output function should be something like <tt>73-INT(14*Accuracy/25)</tt>. -- [[User:Zaimoni|Zaimoni]] 14:31, 26 December 2010 (CST)

::[[image:acc50zaitest.png|thumb|200px]]That's pretty good, I reckon you've nailed the angle caps, probably perfectly - though the "average" values returned by the final formula are still somewhat out of sync with those observed. Here's a graph comparing the two at accuracy 50. On average, the game is getting more shots going along at a 0 (or near 0) degree angle (shown in the red, in case the jagged mess doesn't make it obvious ;) ), whereas the formula is getting the same spread (of course) but with far more "misses" overall. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:18, 28 December 2010 (EST)

::: I'll have to cross-check that graph of the theoretical curve. Thing is, since I play with the projectiles in slowest-speed possible by default I'm pretty sure that I'm not getting 50% perfect shots at 50% accuracy. That would be the snap impression from the current graph: 50% perfect shots, 50% deviated shots. -- [[User:Zaimoni|Zaimoni]] 18:15, 28 December 2010 (CST)

:::: I'm getting a flatter candidate theoretical distribution than your graph, but not as flat as the empirical graph. Much depends on the exact rounding/truncating behavior.

:::: I see that the graph has steps at the 1° points; the theoretical distribution being considered is in steps of 1/8°.

:::: The simplest classical approximation at range 40 for an on-axis shot at a north wall (due north of the firer; corresponding range for due south of the firer is range 41), would read any horizontal error angle with absolute value less than arctan(1/81) ~ 0.7073° as perfect. The corresponding candidate theoretical rate (for shots with error between -5/8° and 5/8° inclusive) is approximately 9.05%.

:::: A better classical approximation would use the actual origin of the shot in voxelspace, rather than the impossible midpoint. -- [[User:Zaimoni|Zaimoni]] 19:41, 28 December 2010

::::: Two problems with the above.

::::: First, the firing origin for due north has been measured: it's (8,1). That means the fast approximation would have been arctan(1/80) [which numerically doesn't change anything].

::::: To set up the classical approximation at range 40 due north, the actual arctangents needed are -arctan(8.5/(16*40)) and arctan(7.5/(16*40)) [these correspond to the west and east edges of the north wall section]. Numerically, this is ~ -0.7609° and ~ 0.6714° . That is, the actual corresponding theoretical error rate is for shots with error between -3/4° and 5/8°, which is approximately 9.87%. -- [[User:Zaimoni|Zaimoni]] 20:14, 28 December 2010

 
===Vertical Error vs Horizontal Error===

Hmmm.... I don't know about you guys, but I notice that in my games, when firing from Level 0 at enemies on level 0, my soldiers seem like their vertical deviation tends to be very small, even with high inaccuracy. Their horizontal deviation seems much much larger. Is this my imagination?

- [[User:Jasonred|Jasonred]]

----

You're quite right, they're two different things. There's enough error there to miss at point blank range against a short target, but still nothing like what you get in the horizontal scheme of things.

- [[User:Bomb Bloke|Bomb Bloke]] 08:46, 17 April 2009 (EDT)

== Target Size ==

Units are cylinders, made up of a [[LOFTEMPS.DAT]] layer determined by [[UNITREF.DAT|UnitRef[48]/[52]]], stacked according to their [[Height]].

The full purpose of UnitRef[52] is still in doubt, though it always seems to mirror the value held at [48]. My personal guess is that one is (or at least, was supposed to be) used when bullets come in on one angle, and the other value is used when bullets come in on a perpendicular-ish angle (hence allowing the cylinder to act more like a squished tube, which is closer to the shape of a real person - or it would do if 48/52 didn't always match).

So, yeah, set [48] to 0, all your units get set to an empty LOFTemps record, they cannot be seen/hit by the aliens. Hurrah.

== See Also ==

Pages relevant to this subject:
*[[Firing Accuracy]]
*[[Accuracy formula]]
*[[Firing Accuracy Testing]]
*[[Height]]
*[[LOFTEMPS.DAT]]

User talk:Bomb Bloke:Firing Accuracy

2010-12-29T02:17:40Z

Zaimoni:

{{tocright}}Consider this [[User:Bomb Bloke|Bomb Bloke's]] draft/discussion about firing accuracy. This topic has been dragging on for quite some time now, so I figure it to about time I had a stab at it.

My view on the matter is this: When you fire a gun, UFO works out the horizontal and vertical angles between your unit and the target, then modifies these depending on your [[Accuracy_formula|overall accuracy stat]].

Say for example you have a perfect 100% (or better) "accuracy". The lines are nearly unmodified, and so near guaranteed to hit (assuming there are no obstructions, in which case you should get a "No LOF!" message when you attempt to fire. Note that the game doesn't ALWAYS give this message and will sometimes allow you to attempt "impossible" shots. In these cases, less-then-perfect aim might still allow the shot to land).

As your rated accuracy decreases, target size and distance become all important: As size decreases and distance increases, the range of angles that could land a hit fall. As accuracy decreases, the range of angles that a shot can take rises and so it becomes less likely that a given shot will fall within the "hitting" range of angles.

(As for why multiple angles can "hit", think of your target as a dartboard: Perfect aim would result in a bullseye, approximate aim would still hit the board, and bad aim would miss altogether. However, in X-Com, you get full "points" so long as the bullet hits the target at all).

That is to say, the ultimate firing accuracy formula would be (range of acceptable hitting angles)/(range of possible firing angles). Assuming, of course, that when firing you're just as likely to fire at your maximum "worst" angle as you are your "best", the range of angles that can hit is determined by target distance and size, and the range of angles that can be fired along is determined by your rated firing accuracy.

However, as it turns out, the angle your shots take isn't entirely random - they follow a bell curve. You're more likely to at least hit near the target then you are to get a massive "air ball" shot. So the formula in truth will end up looking a bit more complex then that.

== Firing Point Origin ==

To get the absolute range of angles a unit can fire along, you first need to know where a unit is firing from. To this end I created a copy of my game folder and modified a save game, some terrain files, and the LOF templates.

[[image:BBFiringPointTest2.png|right|thumb|200px|A basic map of a tile. As it turns out the Y axis really points the other way.]]Now, when we talk about UFO maps, we generally refer to their dimensions in terms of how many tiles there are. However, each tile is really made up of smaller "points": A 16x16x24 point space. This means that a 30x30x4 map has 3,600 tiles in it, and 22,118,400 points within those. When a unit fires, he doesn't aim from his tile at his target's tile, he aims from a point within his tile at a point within his target's tile.

This first test was aimed at discovering exactly where a shot originates from, by creating tiles on units to selectively block their LOF. By seeing which tiles did and which did not, it could be seen exactly (or, at least, as accurately as I think I'm going to get it) where the shots were coming from.

[[image:BBFiringPointTest3.png|right|thumb|200px|The Empire's got nothing on BB's clone army.]]The first row of units served as targets for the second, which stood on tiles similar to the large earth blocks you see in bases but with one layer removed from each. Each therefore entirely blocked LOF so long as the removed layer wasn't at the same height as the unit's firing origin point. The only unit able to fire through the gap was the one sitting on the tile with the third layer down removed.

However, when defining tiles with [[LOFTEMPS.DAT|LOFTemps]], you can only stack the layers 12 high. Presumably the game "double stacks" them to make the resulting 24 point high object. Because of this, the removed layers accounted for two possible Z co-ordinates, meaning the exact value there is still unknown. Might be able to work something out to get it more precise, I dunno.

The third row stood on walls facing to the east/west. Unlike the second row, in this example I moved a single thin wall through each tile, as opposed to moving a "gap". This meant that only one unit would not be able to fire, and that was the one sitting on the ninth tile (made up of my layers from LOFTemps[15]).

[[image:BBFiringPointTest1.png|right|thumb|200px|LOFtemps used, as opposed to the [[LOFTEMPS.DAT|usual set]].]]The forth row followed more or less the same concept, with the walls facing north/south. Only the first unit was unable to fire (LOFTemps[23]).

So! With this information, getting a (x,y,z) co-oridinate is easy enough: It's either (8,15,18) or (8,15,19) (the Z co-ord being imprecise due to the 12 LOFTemp layer limitation).

Note that this value only goes for units with a facing of north. When I get time I'll go through and work it out for the other directions. Furthermore, Sectoids are likely to have a lower firing point (as their guns are rendered lower on the screen).

----

[[Image:origins.png|frame]]

I found an interesting piece of code (offset 40D8E0 for the curious). The formula for the starting zpos when firing looks like this:
''unitpos.zpos*24+unitref.terrain_height-unitref.standing_height+27-unitref.floating_height''
and for kneeling units:
''unitpos.zpos*24+unitref.terrain_height-unitref.kneeling_height+27-unitref.floating_height''
(unitref.terrain_height is offset 0x27 in unitref.dat)
I did a live check with a debugger, for a standing unit on the lowest level it gives this:
''3*24+0-16+27-0=77''
Since the engine seems to use zpos=0 for the ceiling of the topmost level, then the floor must be at offset 4*24=96. floor_level-firing_level=96-77=19, in accord with your empirical results.

Now for xpos and ypos, the engine uses several tables, indexed by the facing orientation (offset 0xa in unitref.dat):
''.data:0046B5E4 dw 8,0Eh,0Fh,0Fh, 8, 1, 1, 1''
for xpos, and
''.data:0046B5C4 dw 1, 1, 8,0Fh,0Fh,0Fh, 8, 1''
for ypos. When facing north, the shot should come from 8x1x19. Note that it is in disaccord with your experience. Maybe you don't use the same point of origin as the engine? [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

You are correct. Moving my origin to match yours brings my data into line (I was limited to guessing it's correct location). Awesome to see the ceiling size confirmed at long last. :D - [[User:Bomb Bloke|Bomb Bloke]] 02:52, 8 May 2008 (PDT)

----

Big units use 2 other tables located at offsets 46B604 and 46B624. I did not try to change these values to see if it changes the position where the shots come from. [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

The xpos/ypos information agrees with my own in vivo research (it explains several LOS different than LOF paradoxes I have explicitly verified). -- [[User:Zaimoni|Zaimoni]] 11:49, 3 May 2008 (CDT)

== Rated Accuracy Vs Angle Range ==

[[image:BBFiringPointTest4.png|thumb|200px]][[image:BBFiringPointTest5.png|thumb|200px]]Just a few results before I go off camping for the weekend. First off, note that [http://www.strategycore.co.uk/forums/index.php?act=ST&f=22&t=5805 the logger] used on this occasion is one I wrote up a year ago. It's not entirely accurate, and needs to approximate values (this is because I can only get it to think in terms of angles between tiles, as opposed to angles between points - as a result you see "steps" in the line graphs provided here). I've thought up some improvements for it (like sticking a roof in the map used so I can get some decent vertical angle stats), but even if I implemented those it'd still never be "accurate".

That said, I got [http://pastebin.com/mcbc752a 2550 results for 0% firing accuracy] overnight and [http://pastebin.com/mdf60034 1876 for 50%] today. I've got the system in concern running trials for 25% until tomorrow.

The graphs displayed summarise these angles. Essentially they go from "those that went to the left" across to "those that went to the right". The longer the line stays at a given level, the more shots took that angle.

At 0% accuracy, the largest horizontal angle I got AWAY from the target was 27.5 degrees (that is to say, a shot could go anywhere within a range of 55 degrees), the average angle being 7.32 degrees. With the side graph you can get an idea of the distribution: Your shots are more likely to hit or at least get close then they are to be far away.

Bumping the rated accuracy to 50% lowered the maximum angle to 17.01 degrees (average of 2.75). Again, you're a lot more likely to get close to the target then you are to reach the possible extremes.

I've since done tests at 100% accuracy and found that the same curve exists, just squished right down. You still have a chance to miss, but only by slight amounts. A formula should be apparent in there somewhere.

At a glance I think it's an exponential equation divided by your rated accuracy? With a few more tests I suppose it'd be more apparent.

: My theory is this that the program first runs "was shot accurate?" check. If yes, then shot deviates 0 and hits the target. If shot misses, calculate path of bullet. Path of bullet follows formula that gives that bell curve.
: I rather suspect that at 25% accuracy, 25% of your shots will be on target, at 50%, 50% will be on target, so on and so forth.
: There might be some additional weird "random drift" that makes 100% and higher accuracy still miss. *Shrugs*. - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: I am absolutely convinced that there is no "was shot accurate?" check. If there was one, I reckon it'd be apparent on the graphs here. I could be wrong, but I believe I've seen no data that supports the theory. No, finding that a certain accuracy rating "seems right" when firing from a certain distance is not supporting data, in that this is the case regardless of whether an "accurate shot" check exists. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)
: Despite the fact it will make your life even harder, I have to remind you that there is also PARTIAL COVER to factor into the tests... what happens when the target is behind a window (modded to be indestructible?), behind a hedge, only his head is visible poking out through the floor (bug here lol)... sometimes a shot will go THROUGH a window, sometimes it will HIT the window... - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: Remember, the "accuracy formula" I'm looking to determine simply returns an angle, which, dependant on your overall accuracy score an the random number generator, will go off on some who knows what direction. Whether that angle leads to the target is dependent on the visible target area versus the angles you'll get based on your accuracy stat (this "target area" concept is the purpose of the next section down, mostly unwritten because it's pointless until THIS formula is figured out).

:: That is to say, there's no real formula that can tell you the REAL chance to hit a target without actually inputting all the tile data in addition to using the "angles formula" I'm after here. Luckily, once the angle formula is determined, it shouldn't be too hard to have my battlescape editor calculate the "true" chance of a shot hitting. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)

: I wonder if it's possible that the game's maximum firing angle (e.g. at zero accuracy) is one radian - about 57.3 degrees? This is near your observed limit of 55 degrees. The game engine would probably use trig functions based on radians as I believe they are the most efficient. Given the power of the computers they were programming for, this vector work was pushing the envelope so they would need to be efficient. - [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)
::I would say that yes, given the close proximity (and the inherent inaccuracy of my logger, due to the inability to pick up on the precise ''point'' a bullet hit), one radian is correct.

::The [[COS.DAT]] page will probably be relevant at some point, dunno if you've read that. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Also could you clarify the axes on these 2 graphs/histograms? I'm having a lot of trouble understanding them. Is it possible that the vertical axis should be frequency, and the angle should be on the horizontal axis? Or am I being dumb? If I'm understanding them correctly, we are not seeing a linear distribution of error angles - as you would get from say

ActualAngle=AngleToTarget+(rand(57)-(57/2))

:what we are getting is angles that cluster together near the correct aimpoint, and frequency falls off quickly as you move away from the correct aimpoint.

:: You are reading the charts correctly. The vertical axis shows how often a specific angle was picked to fire along by the game, and the horizontal axis shows the angles themselves. The reason the charts are symetrical is because shots can either go to the left or right of the target (an angle of 0 means it hit). Even with 0 FFA, you're a lot more likely to send a bullet near the target then you are to send one on the maximum diverging angle - hence my statement, "I think it's an exponential equation divided by your rated accuracy". - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Guess: The graphs look not unlike a tangent or inverse tangent function. That might suggest that the firing function injects a linear amount of perpendicular drift (horizontal and maybe vertical) onto the bullet's vector. Maybe try graphing the tan() or arctan() of the data from the "zero accuracy" tests, and see if you get a horizontal straight line.

: arctan (0.5), which might be relevant if maximum "perpendicular error" is 1 map square wide per map distance unit, is 26.565 degrees, near to your value of 27.5 degrees. Arctan (0.25), which corresponding to half that "perpendicular error", half a map square wide per map distance unit (and maybe corresponding to 50% FFA????), is 14.036 degrees, again near to your value of 17 degrees for 50% FFA. But only 'near', and higher. Hmm. Your data have a horizontal granularity of 1/16th of a map square distance unit, is that right? So there could be some data slightly outside the true upper limit for angles. It depends on the range to your target in your test setup I guess. [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)

:: This is where my brain starts to melt, mind you, it's 3:15am here so I'm probably not good for any number crunching right now. But I reckon you're onto something even if I can't wrap my brain around what!

:: I put the target about 25 squares back (middle of the map). Really can't remember. Ideally I'd've set him to be a pixel in size, but back then the "using LOFTemps for unit size" thing was just a theory I had, not a proven fact (I never got around to updating this page when it WAS proven, that's how long these notes have been here).

:: Yes, granularity is a 16th of a standard user-visible map tile. On the horizontal plane anyway. Can't remember if I set it to 24ths on the vertical, but I probably did. The problem is, of course, that it can only pick up data according to whether a bullet hit a tile or not (as opposed to data on where the tile was hit), so although the range of angles should be "close to accurate" there's still those nasty steps everywhere which have to be "guesstamated".

:: I never really bothered much with the vertical data as I was mostly "proving the concept", figured I'd get to that later. I know I logged it (I was even able to draw an ellipse to show where all the bullets would fall, your maximum vertical angles are of course no where near your maximum horizontal ones), but I can't find the charts in concern. They weren't that good anyway as the test map had no ceiling.

:: I distinctly remember logging and graphing the 100% FFA data but can't find that either. Probably deleted it from my system (in the misguided belief that I'd uploaded it all here). I cannot find any of my related logs at all, in fact, just a single zip file with the logger, test map and automated script file ready to go. Again, this may be because I've deleted them, or because I have nearly ten thousand files in my UFO directory. My main one, anyway. I have a few such directories. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

: OK. The curve you graph above for "zero accuracy" looks not unlike what happens if you graph tan(x) (in degrees), where x is from +0.5 to +0.5. But I think that's a coincidence, since your graph is not a standard histogram - you are showing "frequency" by the length of lines on the x axis, rather than by the height of bars along the y axis as in a standard histogram. In order to turn your graph into a standard histogram it would need to be more or less inverted I think.
: The link to the "zero accuracy" data set is broken now. From what you said above, the data is lost now, which is a shame as it would be nice to do a histogram of tan(a) for all the angles "a" in that data set. You might see a flat line, linear distribution. Or not. If the angles are "bunching up" in frequency toward the target centre, then that suggests a ''linear perpendicular'' distribution of angles. With a linear perpendicular distribution (eg varies by +/- 0 to N units, perpendicular to the path to target, per unit of distance), you would expect a "bunched" angular distribution, i.e. if you sorted all the angles in the data set, the separation between one angle and the next widest would steadily increase.
: The Z component is going to complicate things and prevent finding an exact solution. For example, say that the Z (vertical) error/cone and X (lateral) error/cone are not independent of each other. For example, they might be constrained to add up to some constant N that's related to FFA: Z + Y < N. Or in fact, it might be more like (vertical x 4 + horizontal x 1) < N (since we suspect the actual 'bullet group' is an oval, wider than it is high, rather than a circle). A circle is almost the simplest case, but again unless Z and X are totally independent, you're not going to find a close fit for the function without knowing both terms. Hopefully the oval is very 'flat' and so the horizontal-only function will be a good enough approximation of the data to get in the right ballpark. Or even better, maybe the Z component is a totally independent function. Hope so.
: Let me make a prediction or a series of predictions then for maximum angle off-target:
:* 0% FFA = 1.0 perpendicular error per unit distance = +/ 0.500, arctan(0.500) = +/- 26.6 degrees
:* 50% FFA = 0.5 perpendicular error per unit distance = +/ 0.250, arctan(0.250) = +/- 14.0 degrees
:* 75% FFA = .25 perpendicular error per unit distance = +/ 0.125, arctan(0.125) = +/- 7.1 degrees
:* in general, horizontal maximum angle off target = +/- arctan(((100-FFA)/100)/2)
: Well that's most likely wrong but it's good to have a starting point for testing! [[User:Spike|Spike]] 17:40, 15 March 2009 (EDT)

Hey, guess what? First thing on completing a fresh round of tests, I discover all my old logs.

Of course.

Originals (with no roof on the map so the vertical shot data is a bit iffy): [[User_talk:Bomb_Bloke:0acc1|0%]] - [[User_talk:Bomb_Bloke:25acc1|25%]] - [[User_talk:Bomb_Bloke:50acc1|50%]] - [[User_talk:Bomb_Bloke:75acc1|75%]] - [[User_talk:Bomb_Bloke:100acc1|100%]]

New data (with a roof, vertical shot data might actually be worth something): [[User_talk:Bomb_Bloke:0acc2|0%]] - [[User_talk:Bomb_Bloke:25acc2|25%]] - [[User_talk:Bomb_Bloke:50acc2|50%]] - [[User_talk:Bomb_Bloke:75acc2|75%]] - [[User_talk:Bomb_Bloke:100acc2|100%]]

Comma separated data, one shot per line. First three columns are the absolute tile x/y/z co-ords of where the shot ended up hitting (keeping in mind the shooter is at tile 24/49/2). Next three columns are the x/y/z of where the shot landed, relative to where the shooter is. Final two columns are the important ones, they cover the horizontal and vertical angles the shot took, respectively.

Yes, the wiki doesn't represent it very neatly. Use the edit button to get the line breaks back.

Hrm. Looks like the max angle at 75% comes out to 11.53 degrees... Not 7.1. :(

- [[User:Bomb Bloke|Bomb Bloke]] 09:37, 18 March 2009 (EDT)

----

[[image:BBFiringPointTest6.png|thumb|200px]]
Here is a graph that somewhat better displays the results of my initial 0FA results. The blue line represents the recorded numbers (2550 different values). The red line represents an equal number of results generated by the spreadsheet formula "SIN(RAND()*1.5)*28.64788975*IF(RAND()>0.5;-1;1)".

(Which is, effectively, "The sine of a random number between -1.5 and 1.5 multiplied by half a radian").

Unfortunately the two formulas don't line up (even if you mirror 'em on the diagonal), but they're fairly close. Much closer then the exponential equations I tried graphing, at any rate. I'm thinking I might be able to get something better still with TAN, but I don't seem to be having much luck with that...

- [[User:Bomb Bloke|Bomb Bloke]] 02:18, 15 April 2009 (EDT)

: tan eyeballs great if you assume the distribution going in is some flavor of "sum of linear distributions". tan-1(25°)=0.466307658155; halving this and taking the tangent again gets me ~13.1°, which is reached about 1/16th of the way across. I'm assuming some sort of discretization error for the asymmetry. (My initial gut reaction was "sum of two linear distributions", but that isn't correct; that would have landed about 1/8th of the way across. The quick-and-dirty way to fake a bell curve is to sum three linear distributions.) -- [[User:Zaimoni|Zaimoni]] 11:52, 15 April 2009
(CDT)

: Per geometric check; tan works if the incoming angle is from a sum of three linear distributions. That is: tan(K*rand()*rand()*rand()) should recover the graph up to discretization error, for some K. -- [[User:Zaimoni|Zaimoni]] 12:02, 15 April 2009 (CDT)

:: Is there any chance it's some function of (Kx rand(x), Ky rand(y), Kz rand(z)? [[User:Spike|Spike]] 17:53, 15 April 2009 (EDT)

::: It depends on what you mean...

::: I was presuming rand() was a zero-parameter function that needed "massaging" to get to any range other than its default. C rand() would be 0..RAND_MAX. XCOM almost certainly has a wrapper that returns values in a range 0..N. Given when XCOM was written, I don't think it has any sort of floating-point RNG. I wrote K to subsume all of the range-massaging that was needed.

::: That said, a general sum of three linear distributions would have been tan(K1*rand()+K2*rand()+K3*rand()-AVERAGE) [ignoring overflow issues], where AVERAGE is the statistical average expected from K1*rand()+K2*rand()+K3*rand(). The geometric check almost certainly wouldn't pass if the three constants were obviously distinct. The actual expression I'd try retrofitting is tan(K*(rand()+rand()+rand())-AVERAGE). -- [[User:Zaimoni|Zaimoni]] 14:07, 16 April 2009 (CDT)

:::: If rand() was to receive any parameter at all, it'd be a seed; but calling the function three times should result in three different numbers anyway (typically you seed the RNG first). I'd be surprised if even the original game didn't have a floating RNG. Even back on the Spectrums/Commodores/BBCs you could generate within most any range by typing something like RNG*N. I tried graphing TAN(RAND()*1.5) then TAN(1.5*(RAND()+RAND()+RAND())-2.25), though the first formula wasn't right and the second was worse. :( It's a bit too steep (a little like what you get from 1/x but flopped around). Maybe something a bit higher then 1.5 would sort that out, but I dunno how high you can legally go with TAN? - [[User:Bomb Bloke|Bomb Bloke]] 20:36, 16 April 2009 (EDT)

::::: tan goes unbounded at ±π/2 radians i.e. ±90° Given that the initial bounds appear to be ~±25°, I'd calibrate things so that we were looking at a total span of 50° i.e. ~0.872 radians. In radians, with rand() being a uniform distribution 0..1: TAN(0.872*(rand()+rand()+rand())-0.436) would be my guess.

::::: XCOM 1.2 had some source code comments indicating that the C source targeted Watcom C. That means the "easy rand" available is the C standard library rand(), which without processing returns an integer from 0..RAND_MAX, where RAND_MAX may be as low as 32,767. -- [[User:Zaimoni|Zaimoni]] 12:36, 17 April 2009 (CDT)

: 55 degrees horizontal deviation range corresponds to 440 1/8 degree units; quick-but-lousy-RNG C source for the eighths-of-degrees input to the tangent function at accuracy 0 should be <code>(rand()%147+rand()%147+rand()%147)-219</code> . This plausibly is from a "deviation output" function that returns 73 at accuracy 0, 45 at accuracy 50, and 31 at accuracy 75. Corresponding psuedocode:
<pre>const int tmp = acc_func(...);
const int rng_scale = 2*tmp+1;
const int rng_bias = 3*tmp;

....

(rand()%rng_scale+rand()%rng_scale+rand()%rng_scale)-rng_bias;</pre>

: -- [[User:Zaimoni|Zaimoni]] 13:58, 26 December 2010 (CST)

: That means the deviation output function should be something like <tt>73-INT(14*Accuracy/25)</tt>. -- [[User:Zaimoni|Zaimoni]] 14:31, 26 December 2010 (CST)

::[[image:acc50zaitest.png|thumb|200px]]That's pretty good, I reckon you've nailed the angle caps, probably perfectly - though the "average" values returned by the final formula are still somewhat out of sync with those observed. Here's a graph comparing the two at accuracy 50. On average, the game is getting more shots going along at a 0 (or near 0) degree angle (shown in the red, in case the jagged mess doesn't make it obvious ;) ), whereas the formula is getting the same spread (of course) but with far more "misses" overall. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:18, 28 December 2010 (EST)

::: I'll have to cross-check that graph of the theoretical curve. Thing is, since I play with the projectiles in slowest-speed possible by default I'm pretty sure that I'm not getting 50% perfect shots at 50% accuracy. That would be the snap impression from the current graph: 50% perfect shots, 50% deviated shots. -- [[User:Zaimoni|Zaimoni]] 18:15, 28 December 2010 (CST)

:::: I'm getting a flatter candidate theoretical distribution than your graph, but not as flat as the empirical graph. Much depends on the exact rounding/truncating behavior.

:::: I see that the graph has steps at the 1° points; the theoretical distribution being considered is in steps of 1/8°.

:::: The simplest classical approximation at range 40 for an on-axis shot at a north wall (due north of the firer; corresponding range for due south of the firer is range 41), would read any horizontal error angle with absolute value less than arctan(1/81) ~ 0.7073° as perfect. The corresponding candidate theoretical rate (for shots with error between -5/8° and 5/8° inclusive) is approximately 9.05%.

:::: A better classical approximation would use the actual origin of the shot in voxelspace, rather than the impossible midpoint. -- [[User:Zaimoni|Zaimoni]] 19:41, 28 December 2010

::::: Two problems with the above.

::::: First, the firing origin for due north has been measured: it's (0,8). That means the fast approximation would have been arctan(1/80) [which numerically doesn't change anything].

::::: To set up the classical approximation at range 40 due north, the actual arctangents needed are -arctan(8.5/(16*40)) and arctan(7.5/(16*40)) [these correspond to the west and east edges of the north wall section]. Numerically, this is ~ -0.7609° and ~ 0.6714° . That is, the actual corresponding theoretical error rate is for shots with error between -3/4° and 5/8°, which is approximately 9.87%. -- [[User:Zaimoni|Zaimoni]] 20:14, 28 December 2010

 
===Vertical Error vs Horizontal Error===

Hmmm.... I don't know about you guys, but I notice that in my games, when firing from Level 0 at enemies on level 0, my soldiers seem like their vertical deviation tends to be very small, even with high inaccuracy. Their horizontal deviation seems much much larger. Is this my imagination?

- [[User:Jasonred|Jasonred]]

----

You're quite right, they're two different things. There's enough error there to miss at point blank range against a short target, but still nothing like what you get in the horizontal scheme of things.

- [[User:Bomb Bloke|Bomb Bloke]] 08:46, 17 April 2009 (EDT)

== Target Size ==

Units are cylinders, made up of a [[LOFTEMPS.DAT]] layer determined by [[UNITREF.DAT|UnitRef[48]/[52]]], stacked according to their [[Height]].

The full purpose of UnitRef[52] is still in doubt, though it always seems to mirror the value held at [48]. My personal guess is that one is (or at least, was supposed to be) used when bullets come in on one angle, and the other value is used when bullets come in on a perpendicular-ish angle (hence allowing the cylinder to act more like a squished tube, which is closer to the shape of a real person - or it would do if 48/52 didn't always match).

So, yeah, set [48] to 0, all your units get set to an empty LOFTemps record, they cannot be seen/hit by the aliens. Hurrah.

== See Also ==

Pages relevant to this subject:
*[[Firing Accuracy]]
*[[Accuracy formula]]
*[[Firing Accuracy Testing]]
*[[Height]]
*[[LOFTEMPS.DAT]]

User talk:Bomb Bloke:Firing Accuracy

2010-12-29T02:15:12Z

Zaimoni:

{{tocright}}Consider this [[User:Bomb Bloke|Bomb Bloke's]] draft/discussion about firing accuracy. This topic has been dragging on for quite some time now, so I figure it to about time I had a stab at it.

My view on the matter is this: When you fire a gun, UFO works out the horizontal and vertical angles between your unit and the target, then modifies these depending on your [[Accuracy_formula|overall accuracy stat]].

Say for example you have a perfect 100% (or better) "accuracy". The lines are nearly unmodified, and so near guaranteed to hit (assuming there are no obstructions, in which case you should get a "No LOF!" message when you attempt to fire. Note that the game doesn't ALWAYS give this message and will sometimes allow you to attempt "impossible" shots. In these cases, less-then-perfect aim might still allow the shot to land).

As your rated accuracy decreases, target size and distance become all important: As size decreases and distance increases, the range of angles that could land a hit fall. As accuracy decreases, the range of angles that a shot can take rises and so it becomes less likely that a given shot will fall within the "hitting" range of angles.

(As for why multiple angles can "hit", think of your target as a dartboard: Perfect aim would result in a bullseye, approximate aim would still hit the board, and bad aim would miss altogether. However, in X-Com, you get full "points" so long as the bullet hits the target at all).

That is to say, the ultimate firing accuracy formula would be (range of acceptable hitting angles)/(range of possible firing angles). Assuming, of course, that when firing you're just as likely to fire at your maximum "worst" angle as you are your "best", the range of angles that can hit is determined by target distance and size, and the range of angles that can be fired along is determined by your rated firing accuracy.

However, as it turns out, the angle your shots take isn't entirely random - they follow a bell curve. You're more likely to at least hit near the target then you are to get a massive "air ball" shot. So the formula in truth will end up looking a bit more complex then that.

== Firing Point Origin ==

To get the absolute range of angles a unit can fire along, you first need to know where a unit is firing from. To this end I created a copy of my game folder and modified a save game, some terrain files, and the LOF templates.

[[image:BBFiringPointTest2.png|right|thumb|200px|A basic map of a tile. As it turns out the Y axis really points the other way.]]Now, when we talk about UFO maps, we generally refer to their dimensions in terms of how many tiles there are. However, each tile is really made up of smaller "points": A 16x16x24 point space. This means that a 30x30x4 map has 3,600 tiles in it, and 22,118,400 points within those. When a unit fires, he doesn't aim from his tile at his target's tile, he aims from a point within his tile at a point within his target's tile.

This first test was aimed at discovering exactly where a shot originates from, by creating tiles on units to selectively block their LOF. By seeing which tiles did and which did not, it could be seen exactly (or, at least, as accurately as I think I'm going to get it) where the shots were coming from.

[[image:BBFiringPointTest3.png|right|thumb|200px|The Empire's got nothing on BB's clone army.]]The first row of units served as targets for the second, which stood on tiles similar to the large earth blocks you see in bases but with one layer removed from each. Each therefore entirely blocked LOF so long as the removed layer wasn't at the same height as the unit's firing origin point. The only unit able to fire through the gap was the one sitting on the tile with the third layer down removed.

However, when defining tiles with [[LOFTEMPS.DAT|LOFTemps]], you can only stack the layers 12 high. Presumably the game "double stacks" them to make the resulting 24 point high object. Because of this, the removed layers accounted for two possible Z co-ordinates, meaning the exact value there is still unknown. Might be able to work something out to get it more precise, I dunno.

The third row stood on walls facing to the east/west. Unlike the second row, in this example I moved a single thin wall through each tile, as opposed to moving a "gap". This meant that only one unit would not be able to fire, and that was the one sitting on the ninth tile (made up of my layers from LOFTemps[15]).

[[image:BBFiringPointTest1.png|right|thumb|200px|LOFtemps used, as opposed to the [[LOFTEMPS.DAT|usual set]].]]The forth row followed more or less the same concept, with the walls facing north/south. Only the first unit was unable to fire (LOFTemps[23]).

So! With this information, getting a (x,y,z) co-oridinate is easy enough: It's either (8,15,18) or (8,15,19) (the Z co-ord being imprecise due to the 12 LOFTemp layer limitation).

Note that this value only goes for units with a facing of north. When I get time I'll go through and work it out for the other directions. Furthermore, Sectoids are likely to have a lower firing point (as their guns are rendered lower on the screen).

----

[[Image:origins.png|frame]]

I found an interesting piece of code (offset 40D8E0 for the curious). The formula for the starting zpos when firing looks like this:
''unitpos.zpos*24+unitref.terrain_height-unitref.standing_height+27-unitref.floating_height''
and for kneeling units:
''unitpos.zpos*24+unitref.terrain_height-unitref.kneeling_height+27-unitref.floating_height''
(unitref.terrain_height is offset 0x27 in unitref.dat)
I did a live check with a debugger, for a standing unit on the lowest level it gives this:
''3*24+0-16+27-0=77''
Since the engine seems to use zpos=0 for the ceiling of the topmost level, then the floor must be at offset 4*24=96. floor_level-firing_level=96-77=19, in accord with your empirical results.

Now for xpos and ypos, the engine uses several tables, indexed by the facing orientation (offset 0xa in unitref.dat):
''.data:0046B5E4 dw 8,0Eh,0Fh,0Fh, 8, 1, 1, 1''
for xpos, and
''.data:0046B5C4 dw 1, 1, 8,0Fh,0Fh,0Fh, 8, 1''
for ypos. When facing north, the shot should come from 8x1x19. Note that it is in disaccord with your experience. Maybe you don't use the same point of origin as the engine? [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

You are correct. Moving my origin to match yours brings my data into line (I was limited to guessing it's correct location). Awesome to see the ceiling size confirmed at long last. :D - [[User:Bomb Bloke|Bomb Bloke]] 02:52, 8 May 2008 (PDT)

----

Big units use 2 other tables located at offsets 46B604 and 46B624. I did not try to change these values to see if it changes the position where the shots come from. [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

The xpos/ypos information agrees with my own in vivo research (it explains several LOS different than LOF paradoxes I have explicitly verified). -- [[User:Zaimoni|Zaimoni]] 11:49, 3 May 2008 (CDT)

== Rated Accuracy Vs Angle Range ==

[[image:BBFiringPointTest4.png|thumb|200px]][[image:BBFiringPointTest5.png|thumb|200px]]Just a few results before I go off camping for the weekend. First off, note that [http://www.strategycore.co.uk/forums/index.php?act=ST&f=22&t=5805 the logger] used on this occasion is one I wrote up a year ago. It's not entirely accurate, and needs to approximate values (this is because I can only get it to think in terms of angles between tiles, as opposed to angles between points - as a result you see "steps" in the line graphs provided here). I've thought up some improvements for it (like sticking a roof in the map used so I can get some decent vertical angle stats), but even if I implemented those it'd still never be "accurate".

That said, I got [http://pastebin.com/mcbc752a 2550 results for 0% firing accuracy] overnight and [http://pastebin.com/mdf60034 1876 for 50%] today. I've got the system in concern running trials for 25% until tomorrow.

The graphs displayed summarise these angles. Essentially they go from "those that went to the left" across to "those that went to the right". The longer the line stays at a given level, the more shots took that angle.

At 0% accuracy, the largest horizontal angle I got AWAY from the target was 27.5 degrees (that is to say, a shot could go anywhere within a range of 55 degrees), the average angle being 7.32 degrees. With the side graph you can get an idea of the distribution: Your shots are more likely to hit or at least get close then they are to be far away.

Bumping the rated accuracy to 50% lowered the maximum angle to 17.01 degrees (average of 2.75). Again, you're a lot more likely to get close to the target then you are to reach the possible extremes.

I've since done tests at 100% accuracy and found that the same curve exists, just squished right down. You still have a chance to miss, but only by slight amounts. A formula should be apparent in there somewhere.

At a glance I think it's an exponential equation divided by your rated accuracy? With a few more tests I suppose it'd be more apparent.

: My theory is this that the program first runs "was shot accurate?" check. If yes, then shot deviates 0 and hits the target. If shot misses, calculate path of bullet. Path of bullet follows formula that gives that bell curve.
: I rather suspect that at 25% accuracy, 25% of your shots will be on target, at 50%, 50% will be on target, so on and so forth.
: There might be some additional weird "random drift" that makes 100% and higher accuracy still miss. *Shrugs*. - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: I am absolutely convinced that there is no "was shot accurate?" check. If there was one, I reckon it'd be apparent on the graphs here. I could be wrong, but I believe I've seen no data that supports the theory. No, finding that a certain accuracy rating "seems right" when firing from a certain distance is not supporting data, in that this is the case regardless of whether an "accurate shot" check exists. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)
: Despite the fact it will make your life even harder, I have to remind you that there is also PARTIAL COVER to factor into the tests... what happens when the target is behind a window (modded to be indestructible?), behind a hedge, only his head is visible poking out through the floor (bug here lol)... sometimes a shot will go THROUGH a window, sometimes it will HIT the window... - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: Remember, the "accuracy formula" I'm looking to determine simply returns an angle, which, dependant on your overall accuracy score an the random number generator, will go off on some who knows what direction. Whether that angle leads to the target is dependent on the visible target area versus the angles you'll get based on your accuracy stat (this "target area" concept is the purpose of the next section down, mostly unwritten because it's pointless until THIS formula is figured out).

:: That is to say, there's no real formula that can tell you the REAL chance to hit a target without actually inputting all the tile data in addition to using the "angles formula" I'm after here. Luckily, once the angle formula is determined, it shouldn't be too hard to have my battlescape editor calculate the "true" chance of a shot hitting. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)

: I wonder if it's possible that the game's maximum firing angle (e.g. at zero accuracy) is one radian - about 57.3 degrees? This is near your observed limit of 55 degrees. The game engine would probably use trig functions based on radians as I believe they are the most efficient. Given the power of the computers they were programming for, this vector work was pushing the envelope so they would need to be efficient. - [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)
::I would say that yes, given the close proximity (and the inherent inaccuracy of my logger, due to the inability to pick up on the precise ''point'' a bullet hit), one radian is correct.

::The [[COS.DAT]] page will probably be relevant at some point, dunno if you've read that. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Also could you clarify the axes on these 2 graphs/histograms? I'm having a lot of trouble understanding them. Is it possible that the vertical axis should be frequency, and the angle should be on the horizontal axis? Or am I being dumb? If I'm understanding them correctly, we are not seeing a linear distribution of error angles - as you would get from say

ActualAngle=AngleToTarget+(rand(57)-(57/2))

:what we are getting is angles that cluster together near the correct aimpoint, and frequency falls off quickly as you move away from the correct aimpoint.

:: You are reading the charts correctly. The vertical axis shows how often a specific angle was picked to fire along by the game, and the horizontal axis shows the angles themselves. The reason the charts are symetrical is because shots can either go to the left or right of the target (an angle of 0 means it hit). Even with 0 FFA, you're a lot more likely to send a bullet near the target then you are to send one on the maximum diverging angle - hence my statement, "I think it's an exponential equation divided by your rated accuracy". - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Guess: The graphs look not unlike a tangent or inverse tangent function. That might suggest that the firing function injects a linear amount of perpendicular drift (horizontal and maybe vertical) onto the bullet's vector. Maybe try graphing the tan() or arctan() of the data from the "zero accuracy" tests, and see if you get a horizontal straight line.

: arctan (0.5), which might be relevant if maximum "perpendicular error" is 1 map square wide per map distance unit, is 26.565 degrees, near to your value of 27.5 degrees. Arctan (0.25), which corresponding to half that "perpendicular error", half a map square wide per map distance unit (and maybe corresponding to 50% FFA????), is 14.036 degrees, again near to your value of 17 degrees for 50% FFA. But only 'near', and higher. Hmm. Your data have a horizontal granularity of 1/16th of a map square distance unit, is that right? So there could be some data slightly outside the true upper limit for angles. It depends on the range to your target in your test setup I guess. [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)

:: This is where my brain starts to melt, mind you, it's 3:15am here so I'm probably not good for any number crunching right now. But I reckon you're onto something even if I can't wrap my brain around what!

:: I put the target about 25 squares back (middle of the map). Really can't remember. Ideally I'd've set him to be a pixel in size, but back then the "using LOFTemps for unit size" thing was just a theory I had, not a proven fact (I never got around to updating this page when it WAS proven, that's how long these notes have been here).

:: Yes, granularity is a 16th of a standard user-visible map tile. On the horizontal plane anyway. Can't remember if I set it to 24ths on the vertical, but I probably did. The problem is, of course, that it can only pick up data according to whether a bullet hit a tile or not (as opposed to data on where the tile was hit), so although the range of angles should be "close to accurate" there's still those nasty steps everywhere which have to be "guesstamated".

:: I never really bothered much with the vertical data as I was mostly "proving the concept", figured I'd get to that later. I know I logged it (I was even able to draw an ellipse to show where all the bullets would fall, your maximum vertical angles are of course no where near your maximum horizontal ones), but I can't find the charts in concern. They weren't that good anyway as the test map had no ceiling.

:: I distinctly remember logging and graphing the 100% FFA data but can't find that either. Probably deleted it from my system (in the misguided belief that I'd uploaded it all here). I cannot find any of my related logs at all, in fact, just a single zip file with the logger, test map and automated script file ready to go. Again, this may be because I've deleted them, or because I have nearly ten thousand files in my UFO directory. My main one, anyway. I have a few such directories. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

: OK. The curve you graph above for "zero accuracy" looks not unlike what happens if you graph tan(x) (in degrees), where x is from +0.5 to +0.5. But I think that's a coincidence, since your graph is not a standard histogram - you are showing "frequency" by the length of lines on the x axis, rather than by the height of bars along the y axis as in a standard histogram. In order to turn your graph into a standard histogram it would need to be more or less inverted I think.
: The link to the "zero accuracy" data set is broken now. From what you said above, the data is lost now, which is a shame as it would be nice to do a histogram of tan(a) for all the angles "a" in that data set. You might see a flat line, linear distribution. Or not. If the angles are "bunching up" in frequency toward the target centre, then that suggests a ''linear perpendicular'' distribution of angles. With a linear perpendicular distribution (eg varies by +/- 0 to N units, perpendicular to the path to target, per unit of distance), you would expect a "bunched" angular distribution, i.e. if you sorted all the angles in the data set, the separation between one angle and the next widest would steadily increase.
: The Z component is going to complicate things and prevent finding an exact solution. For example, say that the Z (vertical) error/cone and X (lateral) error/cone are not independent of each other. For example, they might be constrained to add up to some constant N that's related to FFA: Z + Y < N. Or in fact, it might be more like (vertical x 4 + horizontal x 1) < N (since we suspect the actual 'bullet group' is an oval, wider than it is high, rather than a circle). A circle is almost the simplest case, but again unless Z and X are totally independent, you're not going to find a close fit for the function without knowing both terms. Hopefully the oval is very 'flat' and so the horizontal-only function will be a good enough approximation of the data to get in the right ballpark. Or even better, maybe the Z component is a totally independent function. Hope so.
: Let me make a prediction or a series of predictions then for maximum angle off-target:
:* 0% FFA = 1.0 perpendicular error per unit distance = +/ 0.500, arctan(0.500) = +/- 26.6 degrees
:* 50% FFA = 0.5 perpendicular error per unit distance = +/ 0.250, arctan(0.250) = +/- 14.0 degrees
:* 75% FFA = .25 perpendicular error per unit distance = +/ 0.125, arctan(0.125) = +/- 7.1 degrees
:* in general, horizontal maximum angle off target = +/- arctan(((100-FFA)/100)/2)
: Well that's most likely wrong but it's good to have a starting point for testing! [[User:Spike|Spike]] 17:40, 15 March 2009 (EDT)

Hey, guess what? First thing on completing a fresh round of tests, I discover all my old logs.

Of course.

Originals (with no roof on the map so the vertical shot data is a bit iffy): [[User_talk:Bomb_Bloke:0acc1|0%]] - [[User_talk:Bomb_Bloke:25acc1|25%]] - [[User_talk:Bomb_Bloke:50acc1|50%]] - [[User_talk:Bomb_Bloke:75acc1|75%]] - [[User_talk:Bomb_Bloke:100acc1|100%]]

New data (with a roof, vertical shot data might actually be worth something): [[User_talk:Bomb_Bloke:0acc2|0%]] - [[User_talk:Bomb_Bloke:25acc2|25%]] - [[User_talk:Bomb_Bloke:50acc2|50%]] - [[User_talk:Bomb_Bloke:75acc2|75%]] - [[User_talk:Bomb_Bloke:100acc2|100%]]

Comma separated data, one shot per line. First three columns are the absolute tile x/y/z co-ords of where the shot ended up hitting (keeping in mind the shooter is at tile 24/49/2). Next three columns are the x/y/z of where the shot landed, relative to where the shooter is. Final two columns are the important ones, they cover the horizontal and vertical angles the shot took, respectively.

Yes, the wiki doesn't represent it very neatly. Use the edit button to get the line breaks back.

Hrm. Looks like the max angle at 75% comes out to 11.53 degrees... Not 7.1. :(

- [[User:Bomb Bloke|Bomb Bloke]] 09:37, 18 March 2009 (EDT)

----

[[image:BBFiringPointTest6.png|thumb|200px]]
Here is a graph that somewhat better displays the results of my initial 0FA results. The blue line represents the recorded numbers (2550 different values). The red line represents an equal number of results generated by the spreadsheet formula "SIN(RAND()*1.5)*28.64788975*IF(RAND()>0.5;-1;1)".

(Which is, effectively, "The sine of a random number between -1.5 and 1.5 multiplied by half a radian").

Unfortunately the two formulas don't line up (even if you mirror 'em on the diagonal), but they're fairly close. Much closer then the exponential equations I tried graphing, at any rate. I'm thinking I might be able to get something better still with TAN, but I don't seem to be having much luck with that...

- [[User:Bomb Bloke|Bomb Bloke]] 02:18, 15 April 2009 (EDT)

: tan eyeballs great if you assume the distribution going in is some flavor of "sum of linear distributions". tan-1(25°)=0.466307658155; halving this and taking the tangent again gets me ~13.1°, which is reached about 1/16th of the way across. I'm assuming some sort of discretization error for the asymmetry. (My initial gut reaction was "sum of two linear distributions", but that isn't correct; that would have landed about 1/8th of the way across. The quick-and-dirty way to fake a bell curve is to sum three linear distributions.) -- [[User:Zaimoni|Zaimoni]] 11:52, 15 April 2009
(CDT)

: Per geometric check; tan works if the incoming angle is from a sum of three linear distributions. That is: tan(K*rand()*rand()*rand()) should recover the graph up to discretization error, for some K. -- [[User:Zaimoni|Zaimoni]] 12:02, 15 April 2009 (CDT)

:: Is there any chance it's some function of (Kx rand(x), Ky rand(y), Kz rand(z)? [[User:Spike|Spike]] 17:53, 15 April 2009 (EDT)

::: It depends on what you mean...

::: I was presuming rand() was a zero-parameter function that needed "massaging" to get to any range other than its default. C rand() would be 0..RAND_MAX. XCOM almost certainly has a wrapper that returns values in a range 0..N. Given when XCOM was written, I don't think it has any sort of floating-point RNG. I wrote K to subsume all of the range-massaging that was needed.

::: That said, a general sum of three linear distributions would have been tan(K1*rand()+K2*rand()+K3*rand()-AVERAGE) [ignoring overflow issues], where AVERAGE is the statistical average expected from K1*rand()+K2*rand()+K3*rand(). The geometric check almost certainly wouldn't pass if the three constants were obviously distinct. The actual expression I'd try retrofitting is tan(K*(rand()+rand()+rand())-AVERAGE). -- [[User:Zaimoni|Zaimoni]] 14:07, 16 April 2009 (CDT)

:::: If rand() was to receive any parameter at all, it'd be a seed; but calling the function three times should result in three different numbers anyway (typically you seed the RNG first). I'd be surprised if even the original game didn't have a floating RNG. Even back on the Spectrums/Commodores/BBCs you could generate within most any range by typing something like RNG*N. I tried graphing TAN(RAND()*1.5) then TAN(1.5*(RAND()+RAND()+RAND())-2.25), though the first formula wasn't right and the second was worse. :( It's a bit too steep (a little like what you get from 1/x but flopped around). Maybe something a bit higher then 1.5 would sort that out, but I dunno how high you can legally go with TAN? - [[User:Bomb Bloke|Bomb Bloke]] 20:36, 16 April 2009 (EDT)

::::: tan goes unbounded at ±π/2 radians i.e. ±90° Given that the initial bounds appear to be ~±25°, I'd calibrate things so that we were looking at a total span of 50° i.e. ~0.872 radians. In radians, with rand() being a uniform distribution 0..1: TAN(0.872*(rand()+rand()+rand())-0.436) would be my guess.

::::: XCOM 1.2 had some source code comments indicating that the C source targeted Watcom C. That means the "easy rand" available is the C standard library rand(), which without processing returns an integer from 0..RAND_MAX, where RAND_MAX may be as low as 32,767. -- [[User:Zaimoni|Zaimoni]] 12:36, 17 April 2009 (CDT)

: 55 degrees horizontal deviation range corresponds to 440 1/8 degree units; quick-but-lousy-RNG C source for the eighths-of-degrees input to the tangent function at accuracy 0 should be <code>(rand()%147+rand()%147+rand()%147)-219</code> . This plausibly is from a "deviation output" function that returns 73 at accuracy 0, 45 at accuracy 50, and 31 at accuracy 75. Corresponding psuedocode:
<pre>const int tmp = acc_func(...);
const int rng_scale = 2*tmp+1;
const int rng_bias = 3*tmp;

....

(rand()%rng_scale+rand()%rng_scale+rand()%rng_scale)-rng_bias;</pre>

: -- [[User:Zaimoni|Zaimoni]] 13:58, 26 December 2010 (CST)

: That means the deviation output function should be something like <tt>73-INT(14*Accuracy/25)</tt>. -- [[User:Zaimoni|Zaimoni]] 14:31, 26 December 2010 (CST)

::[[image:acc50zaitest.png|thumb|200px]]That's pretty good, I reckon you've nailed the angle caps, probably perfectly - though the "average" values returned by the final formula are still somewhat out of sync with those observed. Here's a graph comparing the two at accuracy 50. On average, the game is getting more shots going along at a 0 (or near 0) degree angle (shown in the red, in case the jagged mess doesn't make it obvious ;) ), whereas the formula is getting the same spread (of course) but with far more "misses" overall. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:18, 28 December 2010 (EST)

::: I'll have to cross-check that graph of the theoretical curve. Thing is, since I play with the projectiles in slowest-speed possible by default I'm pretty sure that I'm not getting 50% perfect shots at 50% accuracy. That would be the snap impression from the current graph: 50% perfect shots, 50% deviated shots. -- [[User:Zaimoni|Zaimoni]] 18:15, 28 December 2010 (CST)

:::: I'm getting a flatter candidate theoretical distribution than your graph, but not as flat as the empirical graph. Much depends on the exact rounding/truncating behavior.

:::: I see that the graph has steps at the 1° points; the theoretical distribution being considered is in steps of 1/8°.

:::: The simplest classical approximation at range 40 for an on-axis shot at a north wall (due north of the firer; corresponding range for due south of the firer is range 41), would read any horizontal error angle with absolute value less than arctan(1/81) ~ 0.7073° as perfect. The corresponding candidate theoretical rate (for shots with error between -5/8° and 5/8° inclusive) is approximately 9.05%.

:::: A better classical approximation would use the actual origin of the shot in voxelspace, rather than the impossible midpoint. -- [[User:Zaimoni|Zaimoni]] 19:41, 28 December 2010

::::: Two problems with the above.

::::: First, the firing origin for due north has been measured: it's (8,0). That means the fast approximation would have been arctan(1/80) [which numerically doesn't change anything].

::::: To set up the classical approximation at range 40 due north, the actual arctangents needed are -arctan(8.5/(16*40)) and arctan(7.5/(16*40)) [these correspond to the west and east edges of the north wall section]. Numerically, this is ~ -0.7609° and ~ 0.6714° . That is, the actual corresponding theoretical error rate is for shots with error between -3/4° and 5/8°, which is approximately 9.87%. -- [[User:Zaimoni|Zaimoni]] 20:14, 28 December 2010

 
===Vertical Error vs Horizontal Error===

Hmmm.... I don't know about you guys, but I notice that in my games, when firing from Level 0 at enemies on level 0, my soldiers seem like their vertical deviation tends to be very small, even with high inaccuracy. Their horizontal deviation seems much much larger. Is this my imagination?

- [[User:Jasonred|Jasonred]]

----

You're quite right, they're two different things. There's enough error there to miss at point blank range against a short target, but still nothing like what you get in the horizontal scheme of things.

- [[User:Bomb Bloke|Bomb Bloke]] 08:46, 17 April 2009 (EDT)

== Target Size ==

Units are cylinders, made up of a [[LOFTEMPS.DAT]] layer determined by [[UNITREF.DAT|UnitRef[48]/[52]]], stacked according to their [[Height]].

The full purpose of UnitRef[52] is still in doubt, though it always seems to mirror the value held at [48]. My personal guess is that one is (or at least, was supposed to be) used when bullets come in on one angle, and the other value is used when bullets come in on a perpendicular-ish angle (hence allowing the cylinder to act more like a squished tube, which is closer to the shape of a real person - or it would do if 48/52 didn't always match).

So, yeah, set [48] to 0, all your units get set to an empty LOFTemps record, they cannot be seen/hit by the aliens. Hurrah.

== See Also ==

Pages relevant to this subject:
*[[Firing Accuracy]]
*[[Accuracy formula]]
*[[Firing Accuracy Testing]]
*[[Height]]
*[[LOFTEMPS.DAT]]

User talk:Bomb Bloke:Firing Accuracy

2010-12-29T01:47:56Z

Zaimoni:

{{tocright}}Consider this [[User:Bomb Bloke|Bomb Bloke's]] draft/discussion about firing accuracy. This topic has been dragging on for quite some time now, so I figure it to about time I had a stab at it.

My view on the matter is this: When you fire a gun, UFO works out the horizontal and vertical angles between your unit and the target, then modifies these depending on your [[Accuracy_formula|overall accuracy stat]].

Say for example you have a perfect 100% (or better) "accuracy". The lines are nearly unmodified, and so near guaranteed to hit (assuming there are no obstructions, in which case you should get a "No LOF!" message when you attempt to fire. Note that the game doesn't ALWAYS give this message and will sometimes allow you to attempt "impossible" shots. In these cases, less-then-perfect aim might still allow the shot to land).

As your rated accuracy decreases, target size and distance become all important: As size decreases and distance increases, the range of angles that could land a hit fall. As accuracy decreases, the range of angles that a shot can take rises and so it becomes less likely that a given shot will fall within the "hitting" range of angles.

(As for why multiple angles can "hit", think of your target as a dartboard: Perfect aim would result in a bullseye, approximate aim would still hit the board, and bad aim would miss altogether. However, in X-Com, you get full "points" so long as the bullet hits the target at all).

That is to say, the ultimate firing accuracy formula would be (range of acceptable hitting angles)/(range of possible firing angles). Assuming, of course, that when firing you're just as likely to fire at your maximum "worst" angle as you are your "best", the range of angles that can hit is determined by target distance and size, and the range of angles that can be fired along is determined by your rated firing accuracy.

However, as it turns out, the angle your shots take isn't entirely random - they follow a bell curve. You're more likely to at least hit near the target then you are to get a massive "air ball" shot. So the formula in truth will end up looking a bit more complex then that.

== Firing Point Origin ==

To get the absolute range of angles a unit can fire along, you first need to know where a unit is firing from. To this end I created a copy of my game folder and modified a save game, some terrain files, and the LOF templates.

[[image:BBFiringPointTest2.png|right|thumb|200px|A basic map of a tile. As it turns out the Y axis really points the other way.]]Now, when we talk about UFO maps, we generally refer to their dimensions in terms of how many tiles there are. However, each tile is really made up of smaller "points": A 16x16x24 point space. This means that a 30x30x4 map has 3,600 tiles in it, and 22,118,400 points within those. When a unit fires, he doesn't aim from his tile at his target's tile, he aims from a point within his tile at a point within his target's tile.

This first test was aimed at discovering exactly where a shot originates from, by creating tiles on units to selectively block their LOF. By seeing which tiles did and which did not, it could be seen exactly (or, at least, as accurately as I think I'm going to get it) where the shots were coming from.

[[image:BBFiringPointTest3.png|right|thumb|200px|The Empire's got nothing on BB's clone army.]]The first row of units served as targets for the second, which stood on tiles similar to the large earth blocks you see in bases but with one layer removed from each. Each therefore entirely blocked LOF so long as the removed layer wasn't at the same height as the unit's firing origin point. The only unit able to fire through the gap was the one sitting on the tile with the third layer down removed.

However, when defining tiles with [[LOFTEMPS.DAT|LOFTemps]], you can only stack the layers 12 high. Presumably the game "double stacks" them to make the resulting 24 point high object. Because of this, the removed layers accounted for two possible Z co-ordinates, meaning the exact value there is still unknown. Might be able to work something out to get it more precise, I dunno.

The third row stood on walls facing to the east/west. Unlike the second row, in this example I moved a single thin wall through each tile, as opposed to moving a "gap". This meant that only one unit would not be able to fire, and that was the one sitting on the ninth tile (made up of my layers from LOFTemps[15]).

[[image:BBFiringPointTest1.png|right|thumb|200px|LOFtemps used, as opposed to the [[LOFTEMPS.DAT|usual set]].]]The forth row followed more or less the same concept, with the walls facing north/south. Only the first unit was unable to fire (LOFTemps[23]).

So! With this information, getting a (x,y,z) co-oridinate is easy enough: It's either (8,15,18) or (8,15,19) (the Z co-ord being imprecise due to the 12 LOFTemp layer limitation).

Note that this value only goes for units with a facing of north. When I get time I'll go through and work it out for the other directions. Furthermore, Sectoids are likely to have a lower firing point (as their guns are rendered lower on the screen).

----

[[Image:origins.png|frame]]

I found an interesting piece of code (offset 40D8E0 for the curious). The formula for the starting zpos when firing looks like this:
''unitpos.zpos*24+unitref.terrain_height-unitref.standing_height+27-unitref.floating_height''
and for kneeling units:
''unitpos.zpos*24+unitref.terrain_height-unitref.kneeling_height+27-unitref.floating_height''
(unitref.terrain_height is offset 0x27 in unitref.dat)
I did a live check with a debugger, for a standing unit on the lowest level it gives this:
''3*24+0-16+27-0=77''
Since the engine seems to use zpos=0 for the ceiling of the topmost level, then the floor must be at offset 4*24=96. floor_level-firing_level=96-77=19, in accord with your empirical results.

Now for xpos and ypos, the engine uses several tables, indexed by the facing orientation (offset 0xa in unitref.dat):
''.data:0046B5E4 dw 8,0Eh,0Fh,0Fh, 8, 1, 1, 1''
for xpos, and
''.data:0046B5C4 dw 1, 1, 8,0Fh,0Fh,0Fh, 8, 1''
for ypos. When facing north, the shot should come from 8x1x19. Note that it is in disaccord with your experience. Maybe you don't use the same point of origin as the engine? [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

You are correct. Moving my origin to match yours brings my data into line (I was limited to guessing it's correct location). Awesome to see the ceiling size confirmed at long last. :D - [[User:Bomb Bloke|Bomb Bloke]] 02:52, 8 May 2008 (PDT)

----

Big units use 2 other tables located at offsets 46B604 and 46B624. I did not try to change these values to see if it changes the position where the shots come from. [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

The xpos/ypos information agrees with my own in vivo research (it explains several LOS different than LOF paradoxes I have explicitly verified). -- [[User:Zaimoni|Zaimoni]] 11:49, 3 May 2008 (CDT)

== Rated Accuracy Vs Angle Range ==

[[image:BBFiringPointTest4.png|thumb|200px]][[image:BBFiringPointTest5.png|thumb|200px]]Just a few results before I go off camping for the weekend. First off, note that [http://www.strategycore.co.uk/forums/index.php?act=ST&f=22&t=5805 the logger] used on this occasion is one I wrote up a year ago. It's not entirely accurate, and needs to approximate values (this is because I can only get it to think in terms of angles between tiles, as opposed to angles between points - as a result you see "steps" in the line graphs provided here). I've thought up some improvements for it (like sticking a roof in the map used so I can get some decent vertical angle stats), but even if I implemented those it'd still never be "accurate".

That said, I got [http://pastebin.com/mcbc752a 2550 results for 0% firing accuracy] overnight and [http://pastebin.com/mdf60034 1876 for 50%] today. I've got the system in concern running trials for 25% until tomorrow.

The graphs displayed summarise these angles. Essentially they go from "those that went to the left" across to "those that went to the right". The longer the line stays at a given level, the more shots took that angle.

At 0% accuracy, the largest horizontal angle I got AWAY from the target was 27.5 degrees (that is to say, a shot could go anywhere within a range of 55 degrees), the average angle being 7.32 degrees. With the side graph you can get an idea of the distribution: Your shots are more likely to hit or at least get close then they are to be far away.

Bumping the rated accuracy to 50% lowered the maximum angle to 17.01 degrees (average of 2.75). Again, you're a lot more likely to get close to the target then you are to reach the possible extremes.

I've since done tests at 100% accuracy and found that the same curve exists, just squished right down. You still have a chance to miss, but only by slight amounts. A formula should be apparent in there somewhere.

At a glance I think it's an exponential equation divided by your rated accuracy? With a few more tests I suppose it'd be more apparent.

: My theory is this that the program first runs "was shot accurate?" check. If yes, then shot deviates 0 and hits the target. If shot misses, calculate path of bullet. Path of bullet follows formula that gives that bell curve.
: I rather suspect that at 25% accuracy, 25% of your shots will be on target, at 50%, 50% will be on target, so on and so forth.
: There might be some additional weird "random drift" that makes 100% and higher accuracy still miss. *Shrugs*. - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: I am absolutely convinced that there is no "was shot accurate?" check. If there was one, I reckon it'd be apparent on the graphs here. I could be wrong, but I believe I've seen no data that supports the theory. No, finding that a certain accuracy rating "seems right" when firing from a certain distance is not supporting data, in that this is the case regardless of whether an "accurate shot" check exists. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)
: Despite the fact it will make your life even harder, I have to remind you that there is also PARTIAL COVER to factor into the tests... what happens when the target is behind a window (modded to be indestructible?), behind a hedge, only his head is visible poking out through the floor (bug here lol)... sometimes a shot will go THROUGH a window, sometimes it will HIT the window... - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: Remember, the "accuracy formula" I'm looking to determine simply returns an angle, which, dependant on your overall accuracy score an the random number generator, will go off on some who knows what direction. Whether that angle leads to the target is dependent on the visible target area versus the angles you'll get based on your accuracy stat (this "target area" concept is the purpose of the next section down, mostly unwritten because it's pointless until THIS formula is figured out).

:: That is to say, there's no real formula that can tell you the REAL chance to hit a target without actually inputting all the tile data in addition to using the "angles formula" I'm after here. Luckily, once the angle formula is determined, it shouldn't be too hard to have my battlescape editor calculate the "true" chance of a shot hitting. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)

: I wonder if it's possible that the game's maximum firing angle (e.g. at zero accuracy) is one radian - about 57.3 degrees? This is near your observed limit of 55 degrees. The game engine would probably use trig functions based on radians as I believe they are the most efficient. Given the power of the computers they were programming for, this vector work was pushing the envelope so they would need to be efficient. - [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)
::I would say that yes, given the close proximity (and the inherent inaccuracy of my logger, due to the inability to pick up on the precise ''point'' a bullet hit), one radian is correct.

::The [[COS.DAT]] page will probably be relevant at some point, dunno if you've read that. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Also could you clarify the axes on these 2 graphs/histograms? I'm having a lot of trouble understanding them. Is it possible that the vertical axis should be frequency, and the angle should be on the horizontal axis? Or am I being dumb? If I'm understanding them correctly, we are not seeing a linear distribution of error angles - as you would get from say

ActualAngle=AngleToTarget+(rand(57)-(57/2))

:what we are getting is angles that cluster together near the correct aimpoint, and frequency falls off quickly as you move away from the correct aimpoint.

:: You are reading the charts correctly. The vertical axis shows how often a specific angle was picked to fire along by the game, and the horizontal axis shows the angles themselves. The reason the charts are symetrical is because shots can either go to the left or right of the target (an angle of 0 means it hit). Even with 0 FFA, you're a lot more likely to send a bullet near the target then you are to send one on the maximum diverging angle - hence my statement, "I think it's an exponential equation divided by your rated accuracy". - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Guess: The graphs look not unlike a tangent or inverse tangent function. That might suggest that the firing function injects a linear amount of perpendicular drift (horizontal and maybe vertical) onto the bullet's vector. Maybe try graphing the tan() or arctan() of the data from the "zero accuracy" tests, and see if you get a horizontal straight line.

: arctan (0.5), which might be relevant if maximum "perpendicular error" is 1 map square wide per map distance unit, is 26.565 degrees, near to your value of 27.5 degrees. Arctan (0.25), which corresponding to half that "perpendicular error", half a map square wide per map distance unit (and maybe corresponding to 50% FFA????), is 14.036 degrees, again near to your value of 17 degrees for 50% FFA. But only 'near', and higher. Hmm. Your data have a horizontal granularity of 1/16th of a map square distance unit, is that right? So there could be some data slightly outside the true upper limit for angles. It depends on the range to your target in your test setup I guess. [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)

:: This is where my brain starts to melt, mind you, it's 3:15am here so I'm probably not good for any number crunching right now. But I reckon you're onto something even if I can't wrap my brain around what!

:: I put the target about 25 squares back (middle of the map). Really can't remember. Ideally I'd've set him to be a pixel in size, but back then the "using LOFTemps for unit size" thing was just a theory I had, not a proven fact (I never got around to updating this page when it WAS proven, that's how long these notes have been here).

:: Yes, granularity is a 16th of a standard user-visible map tile. On the horizontal plane anyway. Can't remember if I set it to 24ths on the vertical, but I probably did. The problem is, of course, that it can only pick up data according to whether a bullet hit a tile or not (as opposed to data on where the tile was hit), so although the range of angles should be "close to accurate" there's still those nasty steps everywhere which have to be "guesstamated".

:: I never really bothered much with the vertical data as I was mostly "proving the concept", figured I'd get to that later. I know I logged it (I was even able to draw an ellipse to show where all the bullets would fall, your maximum vertical angles are of course no where near your maximum horizontal ones), but I can't find the charts in concern. They weren't that good anyway as the test map had no ceiling.

:: I distinctly remember logging and graphing the 100% FFA data but can't find that either. Probably deleted it from my system (in the misguided belief that I'd uploaded it all here). I cannot find any of my related logs at all, in fact, just a single zip file with the logger, test map and automated script file ready to go. Again, this may be because I've deleted them, or because I have nearly ten thousand files in my UFO directory. My main one, anyway. I have a few such directories. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

: OK. The curve you graph above for "zero accuracy" looks not unlike what happens if you graph tan(x) (in degrees), where x is from +0.5 to +0.5. But I think that's a coincidence, since your graph is not a standard histogram - you are showing "frequency" by the length of lines on the x axis, rather than by the height of bars along the y axis as in a standard histogram. In order to turn your graph into a standard histogram it would need to be more or less inverted I think.
: The link to the "zero accuracy" data set is broken now. From what you said above, the data is lost now, which is a shame as it would be nice to do a histogram of tan(a) for all the angles "a" in that data set. You might see a flat line, linear distribution. Or not. If the angles are "bunching up" in frequency toward the target centre, then that suggests a ''linear perpendicular'' distribution of angles. With a linear perpendicular distribution (eg varies by +/- 0 to N units, perpendicular to the path to target, per unit of distance), you would expect a "bunched" angular distribution, i.e. if you sorted all the angles in the data set, the separation between one angle and the next widest would steadily increase.
: The Z component is going to complicate things and prevent finding an exact solution. For example, say that the Z (vertical) error/cone and X (lateral) error/cone are not independent of each other. For example, they might be constrained to add up to some constant N that's related to FFA: Z + Y < N. Or in fact, it might be more like (vertical x 4 + horizontal x 1) < N (since we suspect the actual 'bullet group' is an oval, wider than it is high, rather than a circle). A circle is almost the simplest case, but again unless Z and X are totally independent, you're not going to find a close fit for the function without knowing both terms. Hopefully the oval is very 'flat' and so the horizontal-only function will be a good enough approximation of the data to get in the right ballpark. Or even better, maybe the Z component is a totally independent function. Hope so.
: Let me make a prediction or a series of predictions then for maximum angle off-target:
:* 0% FFA = 1.0 perpendicular error per unit distance = +/ 0.500, arctan(0.500) = +/- 26.6 degrees
:* 50% FFA = 0.5 perpendicular error per unit distance = +/ 0.250, arctan(0.250) = +/- 14.0 degrees
:* 75% FFA = .25 perpendicular error per unit distance = +/ 0.125, arctan(0.125) = +/- 7.1 degrees
:* in general, horizontal maximum angle off target = +/- arctan(((100-FFA)/100)/2)
: Well that's most likely wrong but it's good to have a starting point for testing! [[User:Spike|Spike]] 17:40, 15 March 2009 (EDT)

Hey, guess what? First thing on completing a fresh round of tests, I discover all my old logs.

Of course.

Originals (with no roof on the map so the vertical shot data is a bit iffy): [[User_talk:Bomb_Bloke:0acc1|0%]] - [[User_talk:Bomb_Bloke:25acc1|25%]] - [[User_talk:Bomb_Bloke:50acc1|50%]] - [[User_talk:Bomb_Bloke:75acc1|75%]] - [[User_talk:Bomb_Bloke:100acc1|100%]]

New data (with a roof, vertical shot data might actually be worth something): [[User_talk:Bomb_Bloke:0acc2|0%]] - [[User_talk:Bomb_Bloke:25acc2|25%]] - [[User_talk:Bomb_Bloke:50acc2|50%]] - [[User_talk:Bomb_Bloke:75acc2|75%]] - [[User_talk:Bomb_Bloke:100acc2|100%]]

Comma separated data, one shot per line. First three columns are the absolute tile x/y/z co-ords of where the shot ended up hitting (keeping in mind the shooter is at tile 24/49/2). Next three columns are the x/y/z of where the shot landed, relative to where the shooter is. Final two columns are the important ones, they cover the horizontal and vertical angles the shot took, respectively.

Yes, the wiki doesn't represent it very neatly. Use the edit button to get the line breaks back.

Hrm. Looks like the max angle at 75% comes out to 11.53 degrees... Not 7.1. :(

- [[User:Bomb Bloke|Bomb Bloke]] 09:37, 18 March 2009 (EDT)

----

[[image:BBFiringPointTest6.png|thumb|200px]]
Here is a graph that somewhat better displays the results of my initial 0FA results. The blue line represents the recorded numbers (2550 different values). The red line represents an equal number of results generated by the spreadsheet formula "SIN(RAND()*1.5)*28.64788975*IF(RAND()>0.5;-1;1)".

(Which is, effectively, "The sine of a random number between -1.5 and 1.5 multiplied by half a radian").

Unfortunately the two formulas don't line up (even if you mirror 'em on the diagonal), but they're fairly close. Much closer then the exponential equations I tried graphing, at any rate. I'm thinking I might be able to get something better still with TAN, but I don't seem to be having much luck with that...

- [[User:Bomb Bloke|Bomb Bloke]] 02:18, 15 April 2009 (EDT)

: tan eyeballs great if you assume the distribution going in is some flavor of "sum of linear distributions". tan-1(25°)=0.466307658155; halving this and taking the tangent again gets me ~13.1°, which is reached about 1/16th of the way across. I'm assuming some sort of discretization error for the asymmetry. (My initial gut reaction was "sum of two linear distributions", but that isn't correct; that would have landed about 1/8th of the way across. The quick-and-dirty way to fake a bell curve is to sum three linear distributions.) -- [[User:Zaimoni|Zaimoni]] 11:52, 15 April 2009
(CDT)

: Per geometric check; tan works if the incoming angle is from a sum of three linear distributions. That is: tan(K*rand()*rand()*rand()) should recover the graph up to discretization error, for some K. -- [[User:Zaimoni|Zaimoni]] 12:02, 15 April 2009 (CDT)

:: Is there any chance it's some function of (Kx rand(x), Ky rand(y), Kz rand(z)? [[User:Spike|Spike]] 17:53, 15 April 2009 (EDT)

::: It depends on what you mean...

::: I was presuming rand() was a zero-parameter function that needed "massaging" to get to any range other than its default. C rand() would be 0..RAND_MAX. XCOM almost certainly has a wrapper that returns values in a range 0..N. Given when XCOM was written, I don't think it has any sort of floating-point RNG. I wrote K to subsume all of the range-massaging that was needed.

::: That said, a general sum of three linear distributions would have been tan(K1*rand()+K2*rand()+K3*rand()-AVERAGE) [ignoring overflow issues], where AVERAGE is the statistical average expected from K1*rand()+K2*rand()+K3*rand(). The geometric check almost certainly wouldn't pass if the three constants were obviously distinct. The actual expression I'd try retrofitting is tan(K*(rand()+rand()+rand())-AVERAGE). -- [[User:Zaimoni|Zaimoni]] 14:07, 16 April 2009 (CDT)

:::: If rand() was to receive any parameter at all, it'd be a seed; but calling the function three times should result in three different numbers anyway (typically you seed the RNG first). I'd be surprised if even the original game didn't have a floating RNG. Even back on the Spectrums/Commodores/BBCs you could generate within most any range by typing something like RNG*N. I tried graphing TAN(RAND()*1.5) then TAN(1.5*(RAND()+RAND()+RAND())-2.25), though the first formula wasn't right and the second was worse. :( It's a bit too steep (a little like what you get from 1/x but flopped around). Maybe something a bit higher then 1.5 would sort that out, but I dunno how high you can legally go with TAN? - [[User:Bomb Bloke|Bomb Bloke]] 20:36, 16 April 2009 (EDT)

::::: tan goes unbounded at ±π/2 radians i.e. ±90° Given that the initial bounds appear to be ~±25°, I'd calibrate things so that we were looking at a total span of 50° i.e. ~0.872 radians. In radians, with rand() being a uniform distribution 0..1: TAN(0.872*(rand()+rand()+rand())-0.436) would be my guess.

::::: XCOM 1.2 had some source code comments indicating that the C source targeted Watcom C. That means the "easy rand" available is the C standard library rand(), which without processing returns an integer from 0..RAND_MAX, where RAND_MAX may be as low as 32,767. -- [[User:Zaimoni|Zaimoni]] 12:36, 17 April 2009 (CDT)

: 55 degrees horizontal deviation range corresponds to 440 1/8 degree units; quick-but-lousy-RNG C source for the eighths-of-degrees input to the tangent function at accuracy 0 should be <code>(rand()%147+rand()%147+rand()%147)-219</code> . This plausibly is from a "deviation output" function that returns 73 at accuracy 0, 45 at accuracy 50, and 31 at accuracy 75. Corresponding psuedocode:
<pre>const int tmp = acc_func(...);
const int rng_scale = 2*tmp+1;
const int rng_bias = 3*tmp;

....

(rand()%rng_scale+rand()%rng_scale+rand()%rng_scale)-rng_bias;</pre>

: -- [[User:Zaimoni|Zaimoni]] 13:58, 26 December 2010 (CST)

: That means the deviation output function should be something like <tt>73-INT(14*Accuracy/25)</tt>. -- [[User:Zaimoni|Zaimoni]] 14:31, 26 December 2010 (CST)

::[[image:acc50zaitest.png|thumb|200px]]That's pretty good, I reckon you've nailed the angle caps, probably perfectly - though the "average" values returned by the final formula are still somewhat out of sync with those observed. Here's a graph comparing the two at accuracy 50. On average, the game is getting more shots going along at a 0 (or near 0) degree angle (shown in the red, in case the jagged mess doesn't make it obvious ;) ), whereas the formula is getting the same spread (of course) but with far more "misses" overall. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:18, 28 December 2010 (EST)

::: I'll have to cross-check that graph of the theoretical curve. Thing is, since I play with the projectiles in slowest-speed possible by default I'm pretty sure that I'm not getting 50% perfect shots at 50% accuracy. That would be the snap impression from the current graph: 50% perfect shots, 50% deviated shots. -- [[User:Zaimoni|Zaimoni]] 18:15, 28 December 2010 (CST)

:::: I'm getting a flatter candidate theoretical distribution than your graph, but not as flat as the empirical graph. Much depends on the exact rounding/truncating behavior.

:::: I see that the graph has steps at the 1° points; the theoretical distribution being considered is in steps of 1/8°.

:::: The simplest classical approximation at range 40 for an on-axis shot at a north wall (due north of the firer; corresponding range for due south of the firer is range 41), would read any horizontal error angle with absolute value less than arctan(1/81) ~ 0.7073° as perfect. The corresponding candidate theoretical rate (for shots with error between -5/8° and 5/8° inclusive) is approximately 9.05%.

:::: A better classical approximation would use the actual origin of the shot in voxelspace, rather than the impossible midpoint. -- [[User:Zaimoni|Zaimoni]] 19:41, 28 December 2010

 
===Vertical Error vs Horizontal Error===

Hmmm.... I don't know about you guys, but I notice that in my games, when firing from Level 0 at enemies on level 0, my soldiers seem like their vertical deviation tends to be very small, even with high inaccuracy. Their horizontal deviation seems much much larger. Is this my imagination?

- [[User:Jasonred|Jasonred]]

----

You're quite right, they're two different things. There's enough error there to miss at point blank range against a short target, but still nothing like what you get in the horizontal scheme of things.

- [[User:Bomb Bloke|Bomb Bloke]] 08:46, 17 April 2009 (EDT)

== Target Size ==

Units are cylinders, made up of a [[LOFTEMPS.DAT]] layer determined by [[UNITREF.DAT|UnitRef[48]/[52]]], stacked according to their [[Height]].

The full purpose of UnitRef[52] is still in doubt, though it always seems to mirror the value held at [48]. My personal guess is that one is (or at least, was supposed to be) used when bullets come in on one angle, and the other value is used when bullets come in on a perpendicular-ish angle (hence allowing the cylinder to act more like a squished tube, which is closer to the shape of a real person - or it would do if 48/52 didn't always match).

So, yeah, set [48] to 0, all your units get set to an empty LOFTemps record, they cannot be seen/hit by the aliens. Hurrah.

== See Also ==

Pages relevant to this subject:
*[[Firing Accuracy]]
*[[Accuracy formula]]
*[[Firing Accuracy Testing]]
*[[Height]]
*[[LOFTEMPS.DAT]]

User talk:Bomb Bloke:Firing Accuracy

2010-12-29T01:43:34Z

Zaimoni:

{{tocright}}Consider this [[User:Bomb Bloke|Bomb Bloke's]] draft/discussion about firing accuracy. This topic has been dragging on for quite some time now, so I figure it to about time I had a stab at it.

My view on the matter is this: When you fire a gun, UFO works out the horizontal and vertical angles between your unit and the target, then modifies these depending on your [[Accuracy_formula|overall accuracy stat]].

Say for example you have a perfect 100% (or better) "accuracy". The lines are nearly unmodified, and so near guaranteed to hit (assuming there are no obstructions, in which case you should get a "No LOF!" message when you attempt to fire. Note that the game doesn't ALWAYS give this message and will sometimes allow you to attempt "impossible" shots. In these cases, less-then-perfect aim might still allow the shot to land).

As your rated accuracy decreases, target size and distance become all important: As size decreases and distance increases, the range of angles that could land a hit fall. As accuracy decreases, the range of angles that a shot can take rises and so it becomes less likely that a given shot will fall within the "hitting" range of angles.

(As for why multiple angles can "hit", think of your target as a dartboard: Perfect aim would result in a bullseye, approximate aim would still hit the board, and bad aim would miss altogether. However, in X-Com, you get full "points" so long as the bullet hits the target at all).

That is to say, the ultimate firing accuracy formula would be (range of acceptable hitting angles)/(range of possible firing angles). Assuming, of course, that when firing you're just as likely to fire at your maximum "worst" angle as you are your "best", the range of angles that can hit is determined by target distance and size, and the range of angles that can be fired along is determined by your rated firing accuracy.

However, as it turns out, the angle your shots take isn't entirely random - they follow a bell curve. You're more likely to at least hit near the target then you are to get a massive "air ball" shot. So the formula in truth will end up looking a bit more complex then that.

== Firing Point Origin ==

To get the absolute range of angles a unit can fire along, you first need to know where a unit is firing from. To this end I created a copy of my game folder and modified a save game, some terrain files, and the LOF templates.

[[image:BBFiringPointTest2.png|right|thumb|200px|A basic map of a tile. As it turns out the Y axis really points the other way.]]Now, when we talk about UFO maps, we generally refer to their dimensions in terms of how many tiles there are. However, each tile is really made up of smaller "points": A 16x16x24 point space. This means that a 30x30x4 map has 3,600 tiles in it, and 22,118,400 points within those. When a unit fires, he doesn't aim from his tile at his target's tile, he aims from a point within his tile at a point within his target's tile.

This first test was aimed at discovering exactly where a shot originates from, by creating tiles on units to selectively block their LOF. By seeing which tiles did and which did not, it could be seen exactly (or, at least, as accurately as I think I'm going to get it) where the shots were coming from.

[[image:BBFiringPointTest3.png|right|thumb|200px|The Empire's got nothing on BB's clone army.]]The first row of units served as targets for the second, which stood on tiles similar to the large earth blocks you see in bases but with one layer removed from each. Each therefore entirely blocked LOF so long as the removed layer wasn't at the same height as the unit's firing origin point. The only unit able to fire through the gap was the one sitting on the tile with the third layer down removed.

However, when defining tiles with [[LOFTEMPS.DAT|LOFTemps]], you can only stack the layers 12 high. Presumably the game "double stacks" them to make the resulting 24 point high object. Because of this, the removed layers accounted for two possible Z co-ordinates, meaning the exact value there is still unknown. Might be able to work something out to get it more precise, I dunno.

The third row stood on walls facing to the east/west. Unlike the second row, in this example I moved a single thin wall through each tile, as opposed to moving a "gap". This meant that only one unit would not be able to fire, and that was the one sitting on the ninth tile (made up of my layers from LOFTemps[15]).

[[image:BBFiringPointTest1.png|right|thumb|200px|LOFtemps used, as opposed to the [[LOFTEMPS.DAT|usual set]].]]The forth row followed more or less the same concept, with the walls facing north/south. Only the first unit was unable to fire (LOFTemps[23]).

So! With this information, getting a (x,y,z) co-oridinate is easy enough: It's either (8,15,18) or (8,15,19) (the Z co-ord being imprecise due to the 12 LOFTemp layer limitation).

Note that this value only goes for units with a facing of north. When I get time I'll go through and work it out for the other directions. Furthermore, Sectoids are likely to have a lower firing point (as their guns are rendered lower on the screen).

----

[[Image:origins.png|frame]]

I found an interesting piece of code (offset 40D8E0 for the curious). The formula for the starting zpos when firing looks like this:
''unitpos.zpos*24+unitref.terrain_height-unitref.standing_height+27-unitref.floating_height''
and for kneeling units:
''unitpos.zpos*24+unitref.terrain_height-unitref.kneeling_height+27-unitref.floating_height''
(unitref.terrain_height is offset 0x27 in unitref.dat)
I did a live check with a debugger, for a standing unit on the lowest level it gives this:
''3*24+0-16+27-0=77''
Since the engine seems to use zpos=0 for the ceiling of the topmost level, then the floor must be at offset 4*24=96. floor_level-firing_level=96-77=19, in accord with your empirical results.

Now for xpos and ypos, the engine uses several tables, indexed by the facing orientation (offset 0xa in unitref.dat):
''.data:0046B5E4 dw 8,0Eh,0Fh,0Fh, 8, 1, 1, 1''
for xpos, and
''.data:0046B5C4 dw 1, 1, 8,0Fh,0Fh,0Fh, 8, 1''
for ypos. When facing north, the shot should come from 8x1x19. Note that it is in disaccord with your experience. Maybe you don't use the same point of origin as the engine? [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

You are correct. Moving my origin to match yours brings my data into line (I was limited to guessing it's correct location). Awesome to see the ceiling size confirmed at long last. :D - [[User:Bomb Bloke|Bomb Bloke]] 02:52, 8 May 2008 (PDT)

----

Big units use 2 other tables located at offsets 46B604 and 46B624. I did not try to change these values to see if it changes the position where the shots come from. [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

The xpos/ypos information agrees with my own in vivo research (it explains several LOS different than LOF paradoxes I have explicitly verified). -- [[User:Zaimoni|Zaimoni]] 11:49, 3 May 2008 (CDT)

== Rated Accuracy Vs Angle Range ==

[[image:BBFiringPointTest4.png|thumb|200px]][[image:BBFiringPointTest5.png|thumb|200px]]Just a few results before I go off camping for the weekend. First off, note that [http://www.strategycore.co.uk/forums/index.php?act=ST&f=22&t=5805 the logger] used on this occasion is one I wrote up a year ago. It's not entirely accurate, and needs to approximate values (this is because I can only get it to think in terms of angles between tiles, as opposed to angles between points - as a result you see "steps" in the line graphs provided here). I've thought up some improvements for it (like sticking a roof in the map used so I can get some decent vertical angle stats), but even if I implemented those it'd still never be "accurate".

That said, I got [http://pastebin.com/mcbc752a 2550 results for 0% firing accuracy] overnight and [http://pastebin.com/mdf60034 1876 for 50%] today. I've got the system in concern running trials for 25% until tomorrow.

The graphs displayed summarise these angles. Essentially they go from "those that went to the left" across to "those that went to the right". The longer the line stays at a given level, the more shots took that angle.

At 0% accuracy, the largest horizontal angle I got AWAY from the target was 27.5 degrees (that is to say, a shot could go anywhere within a range of 55 degrees), the average angle being 7.32 degrees. With the side graph you can get an idea of the distribution: Your shots are more likely to hit or at least get close then they are to be far away.

Bumping the rated accuracy to 50% lowered the maximum angle to 17.01 degrees (average of 2.75). Again, you're a lot more likely to get close to the target then you are to reach the possible extremes.

I've since done tests at 100% accuracy and found that the same curve exists, just squished right down. You still have a chance to miss, but only by slight amounts. A formula should be apparent in there somewhere.

At a glance I think it's an exponential equation divided by your rated accuracy? With a few more tests I suppose it'd be more apparent.

: My theory is this that the program first runs "was shot accurate?" check. If yes, then shot deviates 0 and hits the target. If shot misses, calculate path of bullet. Path of bullet follows formula that gives that bell curve.
: I rather suspect that at 25% accuracy, 25% of your shots will be on target, at 50%, 50% will be on target, so on and so forth.
: There might be some additional weird "random drift" that makes 100% and higher accuracy still miss. *Shrugs*. - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: I am absolutely convinced that there is no "was shot accurate?" check. If there was one, I reckon it'd be apparent on the graphs here. I could be wrong, but I believe I've seen no data that supports the theory. No, finding that a certain accuracy rating "seems right" when firing from a certain distance is not supporting data, in that this is the case regardless of whether an "accurate shot" check exists. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)
: Despite the fact it will make your life even harder, I have to remind you that there is also PARTIAL COVER to factor into the tests... what happens when the target is behind a window (modded to be indestructible?), behind a hedge, only his head is visible poking out through the floor (bug here lol)... sometimes a shot will go THROUGH a window, sometimes it will HIT the window... - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: Remember, the "accuracy formula" I'm looking to determine simply returns an angle, which, dependant on your overall accuracy score an the random number generator, will go off on some who knows what direction. Whether that angle leads to the target is dependent on the visible target area versus the angles you'll get based on your accuracy stat (this "target area" concept is the purpose of the next section down, mostly unwritten because it's pointless until THIS formula is figured out).

:: That is to say, there's no real formula that can tell you the REAL chance to hit a target without actually inputting all the tile data in addition to using the "angles formula" I'm after here. Luckily, once the angle formula is determined, it shouldn't be too hard to have my battlescape editor calculate the "true" chance of a shot hitting. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)

: I wonder if it's possible that the game's maximum firing angle (e.g. at zero accuracy) is one radian - about 57.3 degrees? This is near your observed limit of 55 degrees. The game engine would probably use trig functions based on radians as I believe they are the most efficient. Given the power of the computers they were programming for, this vector work was pushing the envelope so they would need to be efficient. - [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)
::I would say that yes, given the close proximity (and the inherent inaccuracy of my logger, due to the inability to pick up on the precise ''point'' a bullet hit), one radian is correct.

::The [[COS.DAT]] page will probably be relevant at some point, dunno if you've read that. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Also could you clarify the axes on these 2 graphs/histograms? I'm having a lot of trouble understanding them. Is it possible that the vertical axis should be frequency, and the angle should be on the horizontal axis? Or am I being dumb? If I'm understanding them correctly, we are not seeing a linear distribution of error angles - as you would get from say

ActualAngle=AngleToTarget+(rand(57)-(57/2))

:what we are getting is angles that cluster together near the correct aimpoint, and frequency falls off quickly as you move away from the correct aimpoint.

:: You are reading the charts correctly. The vertical axis shows how often a specific angle was picked to fire along by the game, and the horizontal axis shows the angles themselves. The reason the charts are symetrical is because shots can either go to the left or right of the target (an angle of 0 means it hit). Even with 0 FFA, you're a lot more likely to send a bullet near the target then you are to send one on the maximum diverging angle - hence my statement, "I think it's an exponential equation divided by your rated accuracy". - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Guess: The graphs look not unlike a tangent or inverse tangent function. That might suggest that the firing function injects a linear amount of perpendicular drift (horizontal and maybe vertical) onto the bullet's vector. Maybe try graphing the tan() or arctan() of the data from the "zero accuracy" tests, and see if you get a horizontal straight line.

: arctan (0.5), which might be relevant if maximum "perpendicular error" is 1 map square wide per map distance unit, is 26.565 degrees, near to your value of 27.5 degrees. Arctan (0.25), which corresponding to half that "perpendicular error", half a map square wide per map distance unit (and maybe corresponding to 50% FFA????), is 14.036 degrees, again near to your value of 17 degrees for 50% FFA. But only 'near', and higher. Hmm. Your data have a horizontal granularity of 1/16th of a map square distance unit, is that right? So there could be some data slightly outside the true upper limit for angles. It depends on the range to your target in your test setup I guess. [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)

:: This is where my brain starts to melt, mind you, it's 3:15am here so I'm probably not good for any number crunching right now. But I reckon you're onto something even if I can't wrap my brain around what!

:: I put the target about 25 squares back (middle of the map). Really can't remember. Ideally I'd've set him to be a pixel in size, but back then the "using LOFTemps for unit size" thing was just a theory I had, not a proven fact (I never got around to updating this page when it WAS proven, that's how long these notes have been here).

:: Yes, granularity is a 16th of a standard user-visible map tile. On the horizontal plane anyway. Can't remember if I set it to 24ths on the vertical, but I probably did. The problem is, of course, that it can only pick up data according to whether a bullet hit a tile or not (as opposed to data on where the tile was hit), so although the range of angles should be "close to accurate" there's still those nasty steps everywhere which have to be "guesstamated".

:: I never really bothered much with the vertical data as I was mostly "proving the concept", figured I'd get to that later. I know I logged it (I was even able to draw an ellipse to show where all the bullets would fall, your maximum vertical angles are of course no where near your maximum horizontal ones), but I can't find the charts in concern. They weren't that good anyway as the test map had no ceiling.

:: I distinctly remember logging and graphing the 100% FFA data but can't find that either. Probably deleted it from my system (in the misguided belief that I'd uploaded it all here). I cannot find any of my related logs at all, in fact, just a single zip file with the logger, test map and automated script file ready to go. Again, this may be because I've deleted them, or because I have nearly ten thousand files in my UFO directory. My main one, anyway. I have a few such directories. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

: OK. The curve you graph above for "zero accuracy" looks not unlike what happens if you graph tan(x) (in degrees), where x is from +0.5 to +0.5. But I think that's a coincidence, since your graph is not a standard histogram - you are showing "frequency" by the length of lines on the x axis, rather than by the height of bars along the y axis as in a standard histogram. In order to turn your graph into a standard histogram it would need to be more or less inverted I think.
: The link to the "zero accuracy" data set is broken now. From what you said above, the data is lost now, which is a shame as it would be nice to do a histogram of tan(a) for all the angles "a" in that data set. You might see a flat line, linear distribution. Or not. If the angles are "bunching up" in frequency toward the target centre, then that suggests a ''linear perpendicular'' distribution of angles. With a linear perpendicular distribution (eg varies by +/- 0 to N units, perpendicular to the path to target, per unit of distance), you would expect a "bunched" angular distribution, i.e. if you sorted all the angles in the data set, the separation between one angle and the next widest would steadily increase.
: The Z component is going to complicate things and prevent finding an exact solution. For example, say that the Z (vertical) error/cone and X (lateral) error/cone are not independent of each other. For example, they might be constrained to add up to some constant N that's related to FFA: Z + Y < N. Or in fact, it might be more like (vertical x 4 + horizontal x 1) < N (since we suspect the actual 'bullet group' is an oval, wider than it is high, rather than a circle). A circle is almost the simplest case, but again unless Z and X are totally independent, you're not going to find a close fit for the function without knowing both terms. Hopefully the oval is very 'flat' and so the horizontal-only function will be a good enough approximation of the data to get in the right ballpark. Or even better, maybe the Z component is a totally independent function. Hope so.
: Let me make a prediction or a series of predictions then for maximum angle off-target:
:* 0% FFA = 1.0 perpendicular error per unit distance = +/ 0.500, arctan(0.500) = +/- 26.6 degrees
:* 50% FFA = 0.5 perpendicular error per unit distance = +/ 0.250, arctan(0.250) = +/- 14.0 degrees
:* 75% FFA = .25 perpendicular error per unit distance = +/ 0.125, arctan(0.125) = +/- 7.1 degrees
:* in general, horizontal maximum angle off target = +/- arctan(((100-FFA)/100)/2)
: Well that's most likely wrong but it's good to have a starting point for testing! [[User:Spike|Spike]] 17:40, 15 March 2009 (EDT)

Hey, guess what? First thing on completing a fresh round of tests, I discover all my old logs.

Of course.

Originals (with no roof on the map so the vertical shot data is a bit iffy): [[User_talk:Bomb_Bloke:0acc1|0%]] - [[User_talk:Bomb_Bloke:25acc1|25%]] - [[User_talk:Bomb_Bloke:50acc1|50%]] - [[User_talk:Bomb_Bloke:75acc1|75%]] - [[User_talk:Bomb_Bloke:100acc1|100%]]

New data (with a roof, vertical shot data might actually be worth something): [[User_talk:Bomb_Bloke:0acc2|0%]] - [[User_talk:Bomb_Bloke:25acc2|25%]] - [[User_talk:Bomb_Bloke:50acc2|50%]] - [[User_talk:Bomb_Bloke:75acc2|75%]] - [[User_talk:Bomb_Bloke:100acc2|100%]]

Comma separated data, one shot per line. First three columns are the absolute tile x/y/z co-ords of where the shot ended up hitting (keeping in mind the shooter is at tile 24/49/2). Next three columns are the x/y/z of where the shot landed, relative to where the shooter is. Final two columns are the important ones, they cover the horizontal and vertical angles the shot took, respectively.

Yes, the wiki doesn't represent it very neatly. Use the edit button to get the line breaks back.

Hrm. Looks like the max angle at 75% comes out to 11.53 degrees... Not 7.1. :(

- [[User:Bomb Bloke|Bomb Bloke]] 09:37, 18 March 2009 (EDT)

----

[[image:BBFiringPointTest6.png|thumb|200px]]
Here is a graph that somewhat better displays the results of my initial 0FA results. The blue line represents the recorded numbers (2550 different values). The red line represents an equal number of results generated by the spreadsheet formula "SIN(RAND()*1.5)*28.64788975*IF(RAND()>0.5;-1;1)".

(Which is, effectively, "The sine of a random number between -1.5 and 1.5 multiplied by half a radian").

Unfortunately the two formulas don't line up (even if you mirror 'em on the diagonal), but they're fairly close. Much closer then the exponential equations I tried graphing, at any rate. I'm thinking I might be able to get something better still with TAN, but I don't seem to be having much luck with that...

- [[User:Bomb Bloke|Bomb Bloke]] 02:18, 15 April 2009 (EDT)

: tan eyeballs great if you assume the distribution going in is some flavor of "sum of linear distributions". tan-1(25°)=0.466307658155; halving this and taking the tangent again gets me ~13.1°, which is reached about 1/16th of the way across. I'm assuming some sort of discretization error for the asymmetry. (My initial gut reaction was "sum of two linear distributions", but that isn't correct; that would have landed about 1/8th of the way across. The quick-and-dirty way to fake a bell curve is to sum three linear distributions.) -- [[User:Zaimoni|Zaimoni]] 11:52, 15 April 2009
(CDT)

: Per geometric check; tan works if the incoming angle is from a sum of three linear distributions. That is: tan(K*rand()*rand()*rand()) should recover the graph up to discretization error, for some K. -- [[User:Zaimoni|Zaimoni]] 12:02, 15 April 2009 (CDT)

:: Is there any chance it's some function of (Kx rand(x), Ky rand(y), Kz rand(z)? [[User:Spike|Spike]] 17:53, 15 April 2009 (EDT)

::: It depends on what you mean...

::: I was presuming rand() was a zero-parameter function that needed "massaging" to get to any range other than its default. C rand() would be 0..RAND_MAX. XCOM almost certainly has a wrapper that returns values in a range 0..N. Given when XCOM was written, I don't think it has any sort of floating-point RNG. I wrote K to subsume all of the range-massaging that was needed.

::: That said, a general sum of three linear distributions would have been tan(K1*rand()+K2*rand()+K3*rand()-AVERAGE) [ignoring overflow issues], where AVERAGE is the statistical average expected from K1*rand()+K2*rand()+K3*rand(). The geometric check almost certainly wouldn't pass if the three constants were obviously distinct. The actual expression I'd try retrofitting is tan(K*(rand()+rand()+rand())-AVERAGE). -- [[User:Zaimoni|Zaimoni]] 14:07, 16 April 2009 (CDT)

:::: If rand() was to receive any parameter at all, it'd be a seed; but calling the function three times should result in three different numbers anyway (typically you seed the RNG first). I'd be surprised if even the original game didn't have a floating RNG. Even back on the Spectrums/Commodores/BBCs you could generate within most any range by typing something like RNG*N. I tried graphing TAN(RAND()*1.5) then TAN(1.5*(RAND()+RAND()+RAND())-2.25), though the first formula wasn't right and the second was worse. :( It's a bit too steep (a little like what you get from 1/x but flopped around). Maybe something a bit higher then 1.5 would sort that out, but I dunno how high you can legally go with TAN? - [[User:Bomb Bloke|Bomb Bloke]] 20:36, 16 April 2009 (EDT)

::::: tan goes unbounded at ±π/2 radians i.e. ±90° Given that the initial bounds appear to be ~±25°, I'd calibrate things so that we were looking at a total span of 50° i.e. ~0.872 radians. In radians, with rand() being a uniform distribution 0..1: TAN(0.872*(rand()+rand()+rand())-0.436) would be my guess.

::::: XCOM 1.2 had some source code comments indicating that the C source targeted Watcom C. That means the "easy rand" available is the C standard library rand(), which without processing returns an integer from 0..RAND_MAX, where RAND_MAX may be as low as 32,767. -- [[User:Zaimoni|Zaimoni]] 12:36, 17 April 2009 (CDT)

: 55 degrees horizontal deviation range corresponds to 440 1/8 degree units; quick-but-lousy-RNG C source for the eighths-of-degrees input to the tangent function at accuracy 0 should be <code>(rand()%147+rand()%147+rand()%147)-219</code> . This plausibly is from a "deviation output" function that returns 73 at accuracy 0, 45 at accuracy 50, and 31 at accuracy 75. Corresponding psuedocode:
<pre>const int tmp = acc_func(...);
const int rng_scale = 2*tmp+1;
const int rng_bias = 3*tmp;

....

(rand()%rng_scale+rand()%rng_scale+rand()%rng_scale)-rng_bias;</pre>

: -- [[User:Zaimoni|Zaimoni]] 13:58, 26 December 2010 (CST)

: That means the deviation output function should be something like <tt>73-INT(14*Accuracy/25)</tt>. -- [[User:Zaimoni|Zaimoni]] 14:31, 26 December 2010 (CST)

::[[image:acc50zaitest.png|thumb|200px]]That's pretty good, I reckon you've nailed the angle caps, probably perfectly - though the "average" values returned by the final formula are still somewhat out of sync with those observed. Here's a graph comparing the two at accuracy 50. On average, the game is getting more shots going along at a 0 (or near 0) degree angle (shown in the red, in case the jagged mess doesn't make it obvious ;) ), whereas the formula is getting the same spread (of course) but with far more "misses" overall. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:18, 28 December 2010 (EST)

::: I'll have to cross-check that graph of the theoretical curve. Thing is, since I play with the projectiles in slowest-speed possible by default I'm pretty sure that I'm not getting 50% perfect shots at 50% accuracy. That would be the snap impression from the current graph: 50% perfect shots, 50% deviated shots. -- [[User:Zaimoni|Zaimoni]] 18:15, 28 December 2010 (CST)

:::: I'm getting a flatter candidate theoretical distribution than your graph, but not as flat as the empirical graph. Much depends on the exact rounding/truncating behavior.

:::: I see that the graph has steps at the 1° points; the theoretical distribution being considered is in steps of 1/8°.

:::: The simplest classical approximation at range 40 for an on-axis shot at a north wall, would read any horizontal error angle with absolute value less than arctan(1/81) ~ 0.7073° as perfect. The corresponding candidate theoretical rate (for shots with error between -5/8° and 5/8° inclusive) is approximately 9.05%.

:::: A better classical approximation would use the actual origin of the shot in voxelspace, rather than the impossible midpoint. -- [[User:Zaimoni|Zaimoni]] 19:41, 28 December 2010

 
===Vertical Error vs Horizontal Error===

Hmmm.... I don't know about you guys, but I notice that in my games, when firing from Level 0 at enemies on level 0, my soldiers seem like their vertical deviation tends to be very small, even with high inaccuracy. Their horizontal deviation seems much much larger. Is this my imagination?

- [[User:Jasonred|Jasonred]]

----

You're quite right, they're two different things. There's enough error there to miss at point blank range against a short target, but still nothing like what you get in the horizontal scheme of things.

- [[User:Bomb Bloke|Bomb Bloke]] 08:46, 17 April 2009 (EDT)

== Target Size ==

Units are cylinders, made up of a [[LOFTEMPS.DAT]] layer determined by [[UNITREF.DAT|UnitRef[48]/[52]]], stacked according to their [[Height]].

The full purpose of UnitRef[52] is still in doubt, though it always seems to mirror the value held at [48]. My personal guess is that one is (or at least, was supposed to be) used when bullets come in on one angle, and the other value is used when bullets come in on a perpendicular-ish angle (hence allowing the cylinder to act more like a squished tube, which is closer to the shape of a real person - or it would do if 48/52 didn't always match).

So, yeah, set [48] to 0, all your units get set to an empty LOFTemps record, they cannot be seen/hit by the aliens. Hurrah.

== See Also ==

Pages relevant to this subject:
*[[Firing Accuracy]]
*[[Accuracy formula]]
*[[Firing Accuracy Testing]]
*[[Height]]
*[[LOFTEMPS.DAT]]

User talk:Bomb Bloke:Firing Accuracy

2010-12-29T00:16:52Z

Zaimoni:

{{tocright}}Consider this [[User:Bomb Bloke|Bomb Bloke's]] draft/discussion about firing accuracy. This topic has been dragging on for quite some time now, so I figure it to about time I had a stab at it.

My view on the matter is this: When you fire a gun, UFO works out the horizontal and vertical angles between your unit and the target, then modifies these depending on your [[Accuracy_formula|overall accuracy stat]].

Say for example you have a perfect 100% (or better) "accuracy". The lines are nearly unmodified, and so near guaranteed to hit (assuming there are no obstructions, in which case you should get a "No LOF!" message when you attempt to fire. Note that the game doesn't ALWAYS give this message and will sometimes allow you to attempt "impossible" shots. In these cases, less-then-perfect aim might still allow the shot to land).

As your rated accuracy decreases, target size and distance become all important: As size decreases and distance increases, the range of angles that could land a hit fall. As accuracy decreases, the range of angles that a shot can take rises and so it becomes less likely that a given shot will fall within the "hitting" range of angles.

(As for why multiple angles can "hit", think of your target as a dartboard: Perfect aim would result in a bullseye, approximate aim would still hit the board, and bad aim would miss altogether. However, in X-Com, you get full "points" so long as the bullet hits the target at all).

That is to say, the ultimate firing accuracy formula would be (range of acceptable hitting angles)/(range of possible firing angles). Assuming, of course, that when firing you're just as likely to fire at your maximum "worst" angle as you are your "best", the range of angles that can hit is determined by target distance and size, and the range of angles that can be fired along is determined by your rated firing accuracy.

However, as it turns out, the angle your shots take isn't entirely random - they follow a bell curve. You're more likely to at least hit near the target then you are to get a massive "air ball" shot. So the formula in truth will end up looking a bit more complex then that.

== Firing Point Origin ==

To get the absolute range of angles a unit can fire along, you first need to know where a unit is firing from. To this end I created a copy of my game folder and modified a save game, some terrain files, and the LOF templates.

[[image:BBFiringPointTest2.png|right|thumb|200px|A basic map of a tile. As it turns out the Y axis really points the other way.]]Now, when we talk about UFO maps, we generally refer to their dimensions in terms of how many tiles there are. However, each tile is really made up of smaller "points": A 16x16x24 point space. This means that a 30x30x4 map has 3,600 tiles in it, and 22,118,400 points within those. When a unit fires, he doesn't aim from his tile at his target's tile, he aims from a point within his tile at a point within his target's tile.

This first test was aimed at discovering exactly where a shot originates from, by creating tiles on units to selectively block their LOF. By seeing which tiles did and which did not, it could be seen exactly (or, at least, as accurately as I think I'm going to get it) where the shots were coming from.

[[image:BBFiringPointTest3.png|right|thumb|200px|The Empire's got nothing on BB's clone army.]]The first row of units served as targets for the second, which stood on tiles similar to the large earth blocks you see in bases but with one layer removed from each. Each therefore entirely blocked LOF so long as the removed layer wasn't at the same height as the unit's firing origin point. The only unit able to fire through the gap was the one sitting on the tile with the third layer down removed.

However, when defining tiles with [[LOFTEMPS.DAT|LOFTemps]], you can only stack the layers 12 high. Presumably the game "double stacks" them to make the resulting 24 point high object. Because of this, the removed layers accounted for two possible Z co-ordinates, meaning the exact value there is still unknown. Might be able to work something out to get it more precise, I dunno.

The third row stood on walls facing to the east/west. Unlike the second row, in this example I moved a single thin wall through each tile, as opposed to moving a "gap". This meant that only one unit would not be able to fire, and that was the one sitting on the ninth tile (made up of my layers from LOFTemps[15]).

[[image:BBFiringPointTest1.png|right|thumb|200px|LOFtemps used, as opposed to the [[LOFTEMPS.DAT|usual set]].]]The forth row followed more or less the same concept, with the walls facing north/south. Only the first unit was unable to fire (LOFTemps[23]).

So! With this information, getting a (x,y,z) co-oridinate is easy enough: It's either (8,15,18) or (8,15,19) (the Z co-ord being imprecise due to the 12 LOFTemp layer limitation).

Note that this value only goes for units with a facing of north. When I get time I'll go through and work it out for the other directions. Furthermore, Sectoids are likely to have a lower firing point (as their guns are rendered lower on the screen).

----

[[Image:origins.png|frame]]

I found an interesting piece of code (offset 40D8E0 for the curious). The formula for the starting zpos when firing looks like this:
''unitpos.zpos*24+unitref.terrain_height-unitref.standing_height+27-unitref.floating_height''
and for kneeling units:
''unitpos.zpos*24+unitref.terrain_height-unitref.kneeling_height+27-unitref.floating_height''
(unitref.terrain_height is offset 0x27 in unitref.dat)
I did a live check with a debugger, for a standing unit on the lowest level it gives this:
''3*24+0-16+27-0=77''
Since the engine seems to use zpos=0 for the ceiling of the topmost level, then the floor must be at offset 4*24=96. floor_level-firing_level=96-77=19, in accord with your empirical results.

Now for xpos and ypos, the engine uses several tables, indexed by the facing orientation (offset 0xa in unitref.dat):
''.data:0046B5E4 dw 8,0Eh,0Fh,0Fh, 8, 1, 1, 1''
for xpos, and
''.data:0046B5C4 dw 1, 1, 8,0Fh,0Fh,0Fh, 8, 1''
for ypos. When facing north, the shot should come from 8x1x19. Note that it is in disaccord with your experience. Maybe you don't use the same point of origin as the engine? [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

You are correct. Moving my origin to match yours brings my data into line (I was limited to guessing it's correct location). Awesome to see the ceiling size confirmed at long last. :D - [[User:Bomb Bloke|Bomb Bloke]] 02:52, 8 May 2008 (PDT)

----

Big units use 2 other tables located at offsets 46B604 and 46B624. I did not try to change these values to see if it changes the position where the shots come from. [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

The xpos/ypos information agrees with my own in vivo research (it explains several LOS different than LOF paradoxes I have explicitly verified). -- [[User:Zaimoni|Zaimoni]] 11:49, 3 May 2008 (CDT)

== Rated Accuracy Vs Angle Range ==

[[image:BBFiringPointTest4.png|thumb|200px]][[image:BBFiringPointTest5.png|thumb|200px]]Just a few results before I go off camping for the weekend. First off, note that [http://www.strategycore.co.uk/forums/index.php?act=ST&f=22&t=5805 the logger] used on this occasion is one I wrote up a year ago. It's not entirely accurate, and needs to approximate values (this is because I can only get it to think in terms of angles between tiles, as opposed to angles between points - as a result you see "steps" in the line graphs provided here). I've thought up some improvements for it (like sticking a roof in the map used so I can get some decent vertical angle stats), but even if I implemented those it'd still never be "accurate".

That said, I got [http://pastebin.com/mcbc752a 2550 results for 0% firing accuracy] overnight and [http://pastebin.com/mdf60034 1876 for 50%] today. I've got the system in concern running trials for 25% until tomorrow.

The graphs displayed summarise these angles. Essentially they go from "those that went to the left" across to "those that went to the right". The longer the line stays at a given level, the more shots took that angle.

At 0% accuracy, the largest horizontal angle I got AWAY from the target was 27.5 degrees (that is to say, a shot could go anywhere within a range of 55 degrees), the average angle being 7.32 degrees. With the side graph you can get an idea of the distribution: Your shots are more likely to hit or at least get close then they are to be far away.

Bumping the rated accuracy to 50% lowered the maximum angle to 17.01 degrees (average of 2.75). Again, you're a lot more likely to get close to the target then you are to reach the possible extremes.

I've since done tests at 100% accuracy and found that the same curve exists, just squished right down. You still have a chance to miss, but only by slight amounts. A formula should be apparent in there somewhere.

At a glance I think it's an exponential equation divided by your rated accuracy? With a few more tests I suppose it'd be more apparent.

: My theory is this that the program first runs "was shot accurate?" check. If yes, then shot deviates 0 and hits the target. If shot misses, calculate path of bullet. Path of bullet follows formula that gives that bell curve.
: I rather suspect that at 25% accuracy, 25% of your shots will be on target, at 50%, 50% will be on target, so on and so forth.
: There might be some additional weird "random drift" that makes 100% and higher accuracy still miss. *Shrugs*. - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: I am absolutely convinced that there is no "was shot accurate?" check. If there was one, I reckon it'd be apparent on the graphs here. I could be wrong, but I believe I've seen no data that supports the theory. No, finding that a certain accuracy rating "seems right" when firing from a certain distance is not supporting data, in that this is the case regardless of whether an "accurate shot" check exists. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)
: Despite the fact it will make your life even harder, I have to remind you that there is also PARTIAL COVER to factor into the tests... what happens when the target is behind a window (modded to be indestructible?), behind a hedge, only his head is visible poking out through the floor (bug here lol)... sometimes a shot will go THROUGH a window, sometimes it will HIT the window... - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: Remember, the "accuracy formula" I'm looking to determine simply returns an angle, which, dependant on your overall accuracy score an the random number generator, will go off on some who knows what direction. Whether that angle leads to the target is dependent on the visible target area versus the angles you'll get based on your accuracy stat (this "target area" concept is the purpose of the next section down, mostly unwritten because it's pointless until THIS formula is figured out).

:: That is to say, there's no real formula that can tell you the REAL chance to hit a target without actually inputting all the tile data in addition to using the "angles formula" I'm after here. Luckily, once the angle formula is determined, it shouldn't be too hard to have my battlescape editor calculate the "true" chance of a shot hitting. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)

: I wonder if it's possible that the game's maximum firing angle (e.g. at zero accuracy) is one radian - about 57.3 degrees? This is near your observed limit of 55 degrees. The game engine would probably use trig functions based on radians as I believe they are the most efficient. Given the power of the computers they were programming for, this vector work was pushing the envelope so they would need to be efficient. - [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)
::I would say that yes, given the close proximity (and the inherent inaccuracy of my logger, due to the inability to pick up on the precise ''point'' a bullet hit), one radian is correct.

::The [[COS.DAT]] page will probably be relevant at some point, dunno if you've read that. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Also could you clarify the axes on these 2 graphs/histograms? I'm having a lot of trouble understanding them. Is it possible that the vertical axis should be frequency, and the angle should be on the horizontal axis? Or am I being dumb? If I'm understanding them correctly, we are not seeing a linear distribution of error angles - as you would get from say

ActualAngle=AngleToTarget+(rand(57)-(57/2))

:what we are getting is angles that cluster together near the correct aimpoint, and frequency falls off quickly as you move away from the correct aimpoint.

:: You are reading the charts correctly. The vertical axis shows how often a specific angle was picked to fire along by the game, and the horizontal axis shows the angles themselves. The reason the charts are symetrical is because shots can either go to the left or right of the target (an angle of 0 means it hit). Even with 0 FFA, you're a lot more likely to send a bullet near the target then you are to send one on the maximum diverging angle - hence my statement, "I think it's an exponential equation divided by your rated accuracy". - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Guess: The graphs look not unlike a tangent or inverse tangent function. That might suggest that the firing function injects a linear amount of perpendicular drift (horizontal and maybe vertical) onto the bullet's vector. Maybe try graphing the tan() or arctan() of the data from the "zero accuracy" tests, and see if you get a horizontal straight line.

: arctan (0.5), which might be relevant if maximum "perpendicular error" is 1 map square wide per map distance unit, is 26.565 degrees, near to your value of 27.5 degrees. Arctan (0.25), which corresponding to half that "perpendicular error", half a map square wide per map distance unit (and maybe corresponding to 50% FFA????), is 14.036 degrees, again near to your value of 17 degrees for 50% FFA. But only 'near', and higher. Hmm. Your data have a horizontal granularity of 1/16th of a map square distance unit, is that right? So there could be some data slightly outside the true upper limit for angles. It depends on the range to your target in your test setup I guess. [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)

:: This is where my brain starts to melt, mind you, it's 3:15am here so I'm probably not good for any number crunching right now. But I reckon you're onto something even if I can't wrap my brain around what!

:: I put the target about 25 squares back (middle of the map). Really can't remember. Ideally I'd've set him to be a pixel in size, but back then the "using LOFTemps for unit size" thing was just a theory I had, not a proven fact (I never got around to updating this page when it WAS proven, that's how long these notes have been here).

:: Yes, granularity is a 16th of a standard user-visible map tile. On the horizontal plane anyway. Can't remember if I set it to 24ths on the vertical, but I probably did. The problem is, of course, that it can only pick up data according to whether a bullet hit a tile or not (as opposed to data on where the tile was hit), so although the range of angles should be "close to accurate" there's still those nasty steps everywhere which have to be "guesstamated".

:: I never really bothered much with the vertical data as I was mostly "proving the concept", figured I'd get to that later. I know I logged it (I was even able to draw an ellipse to show where all the bullets would fall, your maximum vertical angles are of course no where near your maximum horizontal ones), but I can't find the charts in concern. They weren't that good anyway as the test map had no ceiling.

:: I distinctly remember logging and graphing the 100% FFA data but can't find that either. Probably deleted it from my system (in the misguided belief that I'd uploaded it all here). I cannot find any of my related logs at all, in fact, just a single zip file with the logger, test map and automated script file ready to go. Again, this may be because I've deleted them, or because I have nearly ten thousand files in my UFO directory. My main one, anyway. I have a few such directories. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

: OK. The curve you graph above for "zero accuracy" looks not unlike what happens if you graph tan(x) (in degrees), where x is from +0.5 to +0.5. But I think that's a coincidence, since your graph is not a standard histogram - you are showing "frequency" by the length of lines on the x axis, rather than by the height of bars along the y axis as in a standard histogram. In order to turn your graph into a standard histogram it would need to be more or less inverted I think.
: The link to the "zero accuracy" data set is broken now. From what you said above, the data is lost now, which is a shame as it would be nice to do a histogram of tan(a) for all the angles "a" in that data set. You might see a flat line, linear distribution. Or not. If the angles are "bunching up" in frequency toward the target centre, then that suggests a ''linear perpendicular'' distribution of angles. With a linear perpendicular distribution (eg varies by +/- 0 to N units, perpendicular to the path to target, per unit of distance), you would expect a "bunched" angular distribution, i.e. if you sorted all the angles in the data set, the separation between one angle and the next widest would steadily increase.
: The Z component is going to complicate things and prevent finding an exact solution. For example, say that the Z (vertical) error/cone and X (lateral) error/cone are not independent of each other. For example, they might be constrained to add up to some constant N that's related to FFA: Z + Y < N. Or in fact, it might be more like (vertical x 4 + horizontal x 1) < N (since we suspect the actual 'bullet group' is an oval, wider than it is high, rather than a circle). A circle is almost the simplest case, but again unless Z and X are totally independent, you're not going to find a close fit for the function without knowing both terms. Hopefully the oval is very 'flat' and so the horizontal-only function will be a good enough approximation of the data to get in the right ballpark. Or even better, maybe the Z component is a totally independent function. Hope so.
: Let me make a prediction or a series of predictions then for maximum angle off-target:
:* 0% FFA = 1.0 perpendicular error per unit distance = +/ 0.500, arctan(0.500) = +/- 26.6 degrees
:* 50% FFA = 0.5 perpendicular error per unit distance = +/ 0.250, arctan(0.250) = +/- 14.0 degrees
:* 75% FFA = .25 perpendicular error per unit distance = +/ 0.125, arctan(0.125) = +/- 7.1 degrees
:* in general, horizontal maximum angle off target = +/- arctan(((100-FFA)/100)/2)
: Well that's most likely wrong but it's good to have a starting point for testing! [[User:Spike|Spike]] 17:40, 15 March 2009 (EDT)

Hey, guess what? First thing on completing a fresh round of tests, I discover all my old logs.

Of course.

Originals (with no roof on the map so the vertical shot data is a bit iffy): [[User_talk:Bomb_Bloke:0acc1|0%]] - [[User_talk:Bomb_Bloke:25acc1|25%]] - [[User_talk:Bomb_Bloke:50acc1|50%]] - [[User_talk:Bomb_Bloke:75acc1|75%]] - [[User_talk:Bomb_Bloke:100acc1|100%]]

New data (with a roof, vertical shot data might actually be worth something): [[User_talk:Bomb_Bloke:0acc2|0%]] - [[User_talk:Bomb_Bloke:25acc2|25%]] - [[User_talk:Bomb_Bloke:50acc2|50%]] - [[User_talk:Bomb_Bloke:75acc2|75%]] - [[User_talk:Bomb_Bloke:100acc2|100%]]

Comma separated data, one shot per line. First three columns are the absolute tile x/y/z co-ords of where the shot ended up hitting (keeping in mind the shooter is at tile 24/49/2). Next three columns are the x/y/z of where the shot landed, relative to where the shooter is. Final two columns are the important ones, they cover the horizontal and vertical angles the shot took, respectively.

Yes, the wiki doesn't represent it very neatly. Use the edit button to get the line breaks back.

Hrm. Looks like the max angle at 75% comes out to 11.53 degrees... Not 7.1. :(

- [[User:Bomb Bloke|Bomb Bloke]] 09:37, 18 March 2009 (EDT)

----

[[image:BBFiringPointTest6.png|thumb|200px]]
Here is a graph that somewhat better displays the results of my initial 0FA results. The blue line represents the recorded numbers (2550 different values). The red line represents an equal number of results generated by the spreadsheet formula "SIN(RAND()*1.5)*28.64788975*IF(RAND()>0.5;-1;1)".

(Which is, effectively, "The sine of a random number between -1.5 and 1.5 multiplied by half a radian").

Unfortunately the two formulas don't line up (even if you mirror 'em on the diagonal), but they're fairly close. Much closer then the exponential equations I tried graphing, at any rate. I'm thinking I might be able to get something better still with TAN, but I don't seem to be having much luck with that...

- [[User:Bomb Bloke|Bomb Bloke]] 02:18, 15 April 2009 (EDT)

: tan eyeballs great if you assume the distribution going in is some flavor of "sum of linear distributions". tan-1(25°)=0.466307658155; halving this and taking the tangent again gets me ~13.1°, which is reached about 1/16th of the way across. I'm assuming some sort of discretization error for the asymmetry. (My initial gut reaction was "sum of two linear distributions", but that isn't correct; that would have landed about 1/8th of the way across. The quick-and-dirty way to fake a bell curve is to sum three linear distributions.) -- [[User:Zaimoni|Zaimoni]] 11:52, 15 April 2009
(CDT)

: Per geometric check; tan works if the incoming angle is from a sum of three linear distributions. That is: tan(K*rand()*rand()*rand()) should recover the graph up to discretization error, for some K. -- [[User:Zaimoni|Zaimoni]] 12:02, 15 April 2009 (CDT)

:: Is there any chance it's some function of (Kx rand(x), Ky rand(y), Kz rand(z)? [[User:Spike|Spike]] 17:53, 15 April 2009 (EDT)

::: It depends on what you mean...

::: I was presuming rand() was a zero-parameter function that needed "massaging" to get to any range other than its default. C rand() would be 0..RAND_MAX. XCOM almost certainly has a wrapper that returns values in a range 0..N. Given when XCOM was written, I don't think it has any sort of floating-point RNG. I wrote K to subsume all of the range-massaging that was needed.

::: That said, a general sum of three linear distributions would have been tan(K1*rand()+K2*rand()+K3*rand()-AVERAGE) [ignoring overflow issues], where AVERAGE is the statistical average expected from K1*rand()+K2*rand()+K3*rand(). The geometric check almost certainly wouldn't pass if the three constants were obviously distinct. The actual expression I'd try retrofitting is tan(K*(rand()+rand()+rand())-AVERAGE). -- [[User:Zaimoni|Zaimoni]] 14:07, 16 April 2009 (CDT)

:::: If rand() was to receive any parameter at all, it'd be a seed; but calling the function three times should result in three different numbers anyway (typically you seed the RNG first). I'd be surprised if even the original game didn't have a floating RNG. Even back on the Spectrums/Commodores/BBCs you could generate within most any range by typing something like RNG*N. I tried graphing TAN(RAND()*1.5) then TAN(1.5*(RAND()+RAND()+RAND())-2.25), though the first formula wasn't right and the second was worse. :( It's a bit too steep (a little like what you get from 1/x but flopped around). Maybe something a bit higher then 1.5 would sort that out, but I dunno how high you can legally go with TAN? - [[User:Bomb Bloke|Bomb Bloke]] 20:36, 16 April 2009 (EDT)

::::: tan goes unbounded at ±π/2 radians i.e. ±90° Given that the initial bounds appear to be ~±25°, I'd calibrate things so that we were looking at a total span of 50° i.e. ~0.872 radians. In radians, with rand() being a uniform distribution 0..1: TAN(0.872*(rand()+rand()+rand())-0.436) would be my guess.

::::: XCOM 1.2 had some source code comments indicating that the C source targeted Watcom C. That means the "easy rand" available is the C standard library rand(), which without processing returns an integer from 0..RAND_MAX, where RAND_MAX may be as low as 32,767. -- [[User:Zaimoni|Zaimoni]] 12:36, 17 April 2009 (CDT)

: 55 degrees horizontal deviation range corresponds to 440 1/8 degree units; quick-but-lousy-RNG C source for the eighths-of-degrees input to the tangent function at accuracy 0 should be <code>(rand()%147+rand()%147+rand()%147)-219</code> . This plausibly is from a "deviation output" function that returns 73 at accuracy 0, 45 at accuracy 50, and 31 at accuracy 75. Corresponding psuedocode:
<pre>const int tmp = acc_func(...);
const int rng_scale = 2*tmp+1;
const int rng_bias = 3*tmp;

....

(rand()%rng_scale+rand()%rng_scale+rand()%rng_scale)-rng_bias;</pre>

: -- [[User:Zaimoni|Zaimoni]] 13:58, 26 December 2010 (CST)

: That means the deviation output function should be something like <tt>73-INT(14*Accuracy/25)</tt>. -- [[User:Zaimoni|Zaimoni]] 14:31, 26 December 2010 (CST)

::[[image:acc50zaitest.png|thumb|200px]]That's pretty good, I reckon you've nailed the angle caps, probably perfectly - though the "average" values returned by the final formula are still somewhat out of sync with those observed. Here's a graph comparing the two at accuracy 50. On average, the game is getting more shots going along at a 0 (or near 0) degree angle (shown in the red, in case the jagged mess doesn't make it obvious ;) ), whereas the formula is getting the same spread (of course) but with far more "misses" overall. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:18, 28 December 2010 (EST)

::: I'll have to cross-check that graph of the theoretical curve. Thing is, since I play with the projectiles in slowest-speed possible by default I'm pretty sure that I'm not getting 50% perfect shots at 50% accuracy. That would be the snap impression from the current graph: 50% perfect shots, 50% deviated shots. -- [[User:Zaimoni|Zaimoni]] 18:15, 28 December 2010 (CST)

 
===Vertical Error vs Horizontal Error===

Hmmm.... I don't know about you guys, but I notice that in my games, when firing from Level 0 at enemies on level 0, my soldiers seem like their vertical deviation tends to be very small, even with high inaccuracy. Their horizontal deviation seems much much larger. Is this my imagination?

- [[User:Jasonred|Jasonred]]

----

You're quite right, they're two different things. There's enough error there to miss at point blank range against a short target, but still nothing like what you get in the horizontal scheme of things.

- [[User:Bomb Bloke|Bomb Bloke]] 08:46, 17 April 2009 (EDT)

== Target Size ==

Units are cylinders, made up of a [[LOFTEMPS.DAT]] layer determined by [[UNITREF.DAT|UnitRef[48]/[52]]], stacked according to their [[Height]].

The full purpose of UnitRef[52] is still in doubt, though it always seems to mirror the value held at [48]. My personal guess is that one is (or at least, was supposed to be) used when bullets come in on one angle, and the other value is used when bullets come in on a perpendicular-ish angle (hence allowing the cylinder to act more like a squished tube, which is closer to the shape of a real person - or it would do if 48/52 didn't always match).

So, yeah, set [48] to 0, all your units get set to an empty LOFTemps record, they cannot be seen/hit by the aliens. Hurrah.

== See Also ==

Pages relevant to this subject:
*[[Firing Accuracy]]
*[[Accuracy formula]]
*[[Firing Accuracy Testing]]
*[[Height]]
*[[LOFTEMPS.DAT]]

User talk:Bomb Bloke:Firing Accuracy

2010-12-26T20:33:24Z

Zaimoni: finish retrofit of horizontal firing angle deviation to data

{{tocright}}Consider this [[User:Bomb Bloke|Bomb Bloke's]] draft/discussion about firing accuracy. This topic has been dragging on for quite some time now, so I figure it to about time I had a stab at it.

My view on the matter is this: When you fire a gun, UFO works out the horizontal and vertical angles between your unit and the target, then modifies these depending on your [[Accuracy_formula|overall accuracy stat]].

Say for example you have a perfect 100% (or better) "accuracy". The lines are nearly unmodified, and so near guaranteed to hit (assuming there are no obstructions, in which case you should get a "No LOF!" message when you attempt to fire. Note that the game doesn't ALWAYS give this message and will sometimes allow you to attempt "impossible" shots. In these cases, less-then-perfect aim might still allow the shot to land).

As your rated accuracy decreases, target size and distance become all important: As size decreases and distance increases, the range of angles that could land a hit fall. As accuracy decreases, the range of angles that a shot can take rises and so it becomes less likely that a given shot will fall within the "hitting" range of angles.

(As for why multiple angles can "hit", think of your target as a dartboard: Perfect aim would result in a bullseye, approximate aim would still hit the board, and bad aim would miss altogether. However, in X-Com, you get full "points" so long as the bullet hits the target at all).

That is to say, the ultimate firing accuracy formula would be (range of acceptable hitting angles)/(range of possible firing angles). Assuming, of course, that when firing you're just as likely to fire at your maximum "worst" angle as you are your "best", the range of angles that can hit is determined by target distance and size, and the range of angles that can be fired along is determined by your rated firing accuracy.

However, as it turns out, the angle your shots take isn't entirely random - they follow a bell curve. You're more likely to at least hit near the target then you are to get a massive "air ball" shot. So the formula in truth will end up looking a bit more complex then that.

== Firing Point Origin ==

To get the absolute range of angles a unit can fire along, you first need to know where a unit is firing from. To this end I created a copy of my game folder and modified a save game, some terrain files, and the LOF templates.

[[image:BBFiringPointTest2.png|right|thumb|200px|A basic map of a tile. As it turns out the Y axis really points the other way.]]Now, when we talk about UFO maps, we generally refer to their dimensions in terms of how many tiles there are. However, each tile is really made up of smaller "points": A 16x16x24 point space. This means that a 30x30x4 map has 3,600 tiles in it, and 22,118,400 points within those. When a unit fires, he doesn't aim from his tile at his target's tile, he aims from a point within his tile at a point within his target's tile.

This first test was aimed at discovering exactly where a shot originates from, by creating tiles on units to selectively block their LOF. By seeing which tiles did and which did not, it could be seen exactly (or, at least, as accurately as I think I'm going to get it) where the shots were coming from.

[[image:BBFiringPointTest3.png|right|thumb|200px|The Empire's got nothing on BB's clone army.]]The first row of units served as targets for the second, which stood on tiles similar to the large earth blocks you see in bases but with one layer removed from each. Each therefore entirely blocked LOF so long as the removed layer wasn't at the same height as the unit's firing origin point. The only unit able to fire through the gap was the one sitting on the tile with the third layer down removed.

However, when defining tiles with [[LOFTEMPS.DAT|LOFTemps]], you can only stack the layers 12 high. Presumably the game "double stacks" them to make the resulting 24 point high object. Because of this, the removed layers accounted for two possible Z co-ordinates, meaning the exact value there is still unknown. Might be able to work something out to get it more precise, I dunno.

The third row stood on walls facing to the east/west. Unlike the second row, in this example I moved a single thin wall through each tile, as opposed to moving a "gap". This meant that only one unit would not be able to fire, and that was the one sitting on the ninth tile (made up of my layers from LOFTemps[15]).

[[image:BBFiringPointTest1.png|right|thumb|200px|LOFtemps used, as opposed to the [[LOFTEMPS.DAT|usual set]].]]The forth row followed more or less the same concept, with the walls facing north/south. Only the first unit was unable to fire (LOFTemps[23]).

So! With this information, getting a (x,y,z) co-oridinate is easy enough: It's either (8,15,18) or (8,15,19) (the Z co-ord being imprecise due to the 12 LOFTemp layer limitation).

Note that this value only goes for units with a facing of north. When I get time I'll go through and work it out for the other directions. Furthermore, Sectoids are likely to have a lower firing point (as their guns are rendered lower on the screen).

----

[[Image:origins.png|frame]]

I found an interesting piece of code (offset 40D8E0 for the curious). The formula for the starting zpos when firing looks like this:
''unitpos.zpos*24+unitref.terrain_height-unitref.standing_height+27-unitref.floating_height''
and for kneeling units:
''unitpos.zpos*24+unitref.terrain_height-unitref.kneeling_height+27-unitref.floating_height''
(unitref.terrain_height is offset 0x27 in unitref.dat)
I did a live check with a debugger, for a standing unit on the lowest level it gives this:
''3*24+0-16+27-0=77''
Since the engine seems to use zpos=0 for the ceiling of the topmost level, then the floor must be at offset 4*24=96. floor_level-firing_level=96-77=19, in accord with your empirical results.

Now for xpos and ypos, the engine uses several tables, indexed by the facing orientation (offset 0xa in unitref.dat):
''.data:0046B5E4 dw 8,0Eh,0Fh,0Fh, 8, 1, 1, 1''
for xpos, and
''.data:0046B5C4 dw 1, 1, 8,0Fh,0Fh,0Fh, 8, 1''
for ypos. When facing north, the shot should come from 8x1x19. Note that it is in disaccord with your experience. Maybe you don't use the same point of origin as the engine? [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

You are correct. Moving my origin to match yours brings my data into line (I was limited to guessing it's correct location). Awesome to see the ceiling size confirmed at long last. :D - [[User:Bomb Bloke|Bomb Bloke]] 02:52, 8 May 2008 (PDT)

----

Big units use 2 other tables located at offsets 46B604 and 46B624. I did not try to change these values to see if it changes the position where the shots come from. [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

The xpos/ypos information agrees with my own in vivo research (it explains several LOS different than LOF paradoxes I have explicitly verified). -- [[User:Zaimoni|Zaimoni]] 11:49, 3 May 2008 (CDT)

== Rated Accuracy Vs Angle Range ==

[[image:BBFiringPointTest4.png|thumb|200px]][[image:BBFiringPointTest5.png|thumb|200px]]Just a few results before I go off camping for the weekend. First off, note that [http://www.strategycore.co.uk/forums/index.php?act=ST&f=22&t=5805 the logger] used on this occasion is one I wrote up a year ago. It's not entirely accurate, and needs to approximate values (this is because I can only get it to think in terms of angles between tiles, as opposed to angles between points - as a result you see "steps" in the line graphs provided here). I've thought up some improvements for it (like sticking a roof in the map used so I can get some decent vertical angle stats), but even if I implemented those it'd still never be "accurate".

That said, I got [http://pastebin.com/mcbc752a 2550 results for 0% firing accuracy] overnight and [http://pastebin.com/mdf60034 1876 for 50%] today. I've got the system in concern running trials for 25% until tomorrow.

The graphs displayed summarise these angles. Essentially they go from "those that went to the left" across to "those that went to the right". The longer the line stays at a given level, the more shots took that angle.

At 0% accuracy, the largest horizontal angle I got AWAY from the target was 27.5 degrees (that is to say, a shot could go anywhere within a range of 55 degrees), the average angle being 7.32 degrees. With the side graph you can get an idea of the distribution: Your shots are more likely to hit or at least get close then they are to be far away.

Bumping the rated accuracy to 50% lowered the maximum angle to 17.01 degrees (average of 2.75). Again, you're a lot more likely to get close to the target then you are to reach the possible extremes.

I've since done tests at 100% accuracy and found that the same curve exists, just squished right down. You still have a chance to miss, but only by slight amounts. A formula should be apparent in there somewhere.

At a glance I think it's an exponential equation divided by your rated accuracy? With a few more tests I suppose it'd be more apparent.

: My theory is this that the program first runs "was shot accurate?" check. If yes, then shot deviates 0 and hits the target. If shot misses, calculate path of bullet. Path of bullet follows formula that gives that bell curve.
: I rather suspect that at 25% accuracy, 25% of your shots will be on target, at 50%, 50% will be on target, so on and so forth.
: There might be some additional weird "random drift" that makes 100% and higher accuracy still miss. *Shrugs*. - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: I am absolutely convinced that there is no "was shot accurate?" check. If there was one, I reckon it'd be apparent on the graphs here. I could be wrong, but I believe I've seen no data that supports the theory. No, finding that a certain accuracy rating "seems right" when firing from a certain distance is not supporting data, in that this is the case regardless of whether an "accurate shot" check exists. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)
: Despite the fact it will make your life even harder, I have to remind you that there is also PARTIAL COVER to factor into the tests... what happens when the target is behind a window (modded to be indestructible?), behind a hedge, only his head is visible poking out through the floor (bug here lol)... sometimes a shot will go THROUGH a window, sometimes it will HIT the window... - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: Remember, the "accuracy formula" I'm looking to determine simply returns an angle, which, dependant on your overall accuracy score an the random number generator, will go off on some who knows what direction. Whether that angle leads to the target is dependent on the visible target area versus the angles you'll get based on your accuracy stat (this "target area" concept is the purpose of the next section down, mostly unwritten because it's pointless until THIS formula is figured out).

:: That is to say, there's no real formula that can tell you the REAL chance to hit a target without actually inputting all the tile data in addition to using the "angles formula" I'm after here. Luckily, once the angle formula is determined, it shouldn't be too hard to have my battlescape editor calculate the "true" chance of a shot hitting. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)

: I wonder if it's possible that the game's maximum firing angle (e.g. at zero accuracy) is one radian - about 57.3 degrees? This is near your observed limit of 55 degrees. The game engine would probably use trig functions based on radians as I believe they are the most efficient. Given the power of the computers they were programming for, this vector work was pushing the envelope so they would need to be efficient. - [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)
::I would say that yes, given the close proximity (and the inherent inaccuracy of my logger, due to the inability to pick up on the precise ''point'' a bullet hit), one radian is correct.

::The [[COS.DAT]] page will probably be relevant at some point, dunno if you've read that. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Also could you clarify the axes on these 2 graphs/histograms? I'm having a lot of trouble understanding them. Is it possible that the vertical axis should be frequency, and the angle should be on the horizontal axis? Or am I being dumb? If I'm understanding them correctly, we are not seeing a linear distribution of error angles - as you would get from say

ActualAngle=AngleToTarget+(rand(57)-(57/2))

:what we are getting is angles that cluster together near the correct aimpoint, and frequency falls off quickly as you move away from the correct aimpoint.

:: You are reading the charts correctly. The vertical axis shows how often a specific angle was picked to fire along by the game, and the horizontal axis shows the angles themselves. The reason the charts are symetrical is because shots can either go to the left or right of the target (an angle of 0 means it hit). Even with 0 FFA, you're a lot more likely to send a bullet near the target then you are to send one on the maximum diverging angle - hence my statement, "I think it's an exponential equation divided by your rated accuracy". - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Guess: The graphs look not unlike a tangent or inverse tangent function. That might suggest that the firing function injects a linear amount of perpendicular drift (horizontal and maybe vertical) onto the bullet's vector. Maybe try graphing the tan() or arctan() of the data from the "zero accuracy" tests, and see if you get a horizontal straight line.

: arctan (0.5), which might be relevant if maximum "perpendicular error" is 1 map square wide per map distance unit, is 26.565 degrees, near to your value of 27.5 degrees. Arctan (0.25), which corresponding to half that "perpendicular error", half a map square wide per map distance unit (and maybe corresponding to 50% FFA????), is 14.036 degrees, again near to your value of 17 degrees for 50% FFA. But only 'near', and higher. Hmm. Your data have a horizontal granularity of 1/16th of a map square distance unit, is that right? So there could be some data slightly outside the true upper limit for angles. It depends on the range to your target in your test setup I guess. [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)

:: This is where my brain starts to melt, mind you, it's 3:15am here so I'm probably not good for any number crunching right now. But I reckon you're onto something even if I can't wrap my brain around what!

:: I put the target about 25 squares back (middle of the map). Really can't remember. Ideally I'd've set him to be a pixel in size, but back then the "using LOFTemps for unit size" thing was just a theory I had, not a proven fact (I never got around to updating this page when it WAS proven, that's how long these notes have been here).

:: Yes, granularity is a 16th of a standard user-visible map tile. On the horizontal plane anyway. Can't remember if I set it to 24ths on the vertical, but I probably did. The problem is, of course, that it can only pick up data according to whether a bullet hit a tile or not (as opposed to data on where the tile was hit), so although the range of angles should be "close to accurate" there's still those nasty steps everywhere which have to be "guesstamated".

:: I never really bothered much with the vertical data as I was mostly "proving the concept", figured I'd get to that later. I know I logged it (I was even able to draw an ellipse to show where all the bullets would fall, your maximum vertical angles are of course no where near your maximum horizontal ones), but I can't find the charts in concern. They weren't that good anyway as the test map had no ceiling.

:: I distinctly remember logging and graphing the 100% FFA data but can't find that either. Probably deleted it from my system (in the misguided belief that I'd uploaded it all here). I cannot find any of my related logs at all, in fact, just a single zip file with the logger, test map and automated script file ready to go. Again, this may be because I've deleted them, or because I have nearly ten thousand files in my UFO directory. My main one, anyway. I have a few such directories. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

: OK. The curve you graph above for "zero accuracy" looks not unlike what happens if you graph tan(x) (in degrees), where x is from +0.5 to +0.5. But I think that's a coincidence, since your graph is not a standard histogram - you are showing "frequency" by the length of lines on the x axis, rather than by the height of bars along the y axis as in a standard histogram. In order to turn your graph into a standard histogram it would need to be more or less inverted I think.
: The link to the "zero accuracy" data set is broken now. From what you said above, the data is lost now, which is a shame as it would be nice to do a histogram of tan(a) for all the angles "a" in that data set. You might see a flat line, linear distribution. Or not. If the angles are "bunching up" in frequency toward the target centre, then that suggests a ''linear perpendicular'' distribution of angles. With a linear perpendicular distribution (eg varies by +/- 0 to N units, perpendicular to the path to target, per unit of distance), you would expect a "bunched" angular distribution, i.e. if you sorted all the angles in the data set, the separation between one angle and the next widest would steadily increase.
: The Z component is going to complicate things and prevent finding an exact solution. For example, say that the Z (vertical) error/cone and X (lateral) error/cone are not independent of each other. For example, they might be constrained to add up to some constant N that's related to FFA: Z + Y < N. Or in fact, it might be more like (vertical x 4 + horizontal x 1) < N (since we suspect the actual 'bullet group' is an oval, wider than it is high, rather than a circle). A circle is almost the simplest case, but again unless Z and X are totally independent, you're not going to find a close fit for the function without knowing both terms. Hopefully the oval is very 'flat' and so the horizontal-only function will be a good enough approximation of the data to get in the right ballpark. Or even better, maybe the Z component is a totally independent function. Hope so.
: Let me make a prediction or a series of predictions then for maximum angle off-target:
:* 0% FFA = 1.0 perpendicular error per unit distance = +/ 0.500, arctan(0.500) = +/- 26.6 degrees
:* 50% FFA = 0.5 perpendicular error per unit distance = +/ 0.250, arctan(0.250) = +/- 14.0 degrees
:* 75% FFA = .25 perpendicular error per unit distance = +/ 0.125, arctan(0.125) = +/- 7.1 degrees
:* in general, horizontal maximum angle off target = +/- arctan(((100-FFA)/100)/2)
: Well that's most likely wrong but it's good to have a starting point for testing! [[User:Spike|Spike]] 17:40, 15 March 2009 (EDT)

Hey, guess what? First thing on completing a fresh round of tests, I discover all my old logs.

Of course.

Originals (with no roof on the map so the vertical shot data is a bit iffy): [[User_talk:Bomb_Bloke:0acc1|0%]] - [[User_talk:Bomb_Bloke:25acc1|25%]] - [[User_talk:Bomb_Bloke:50acc1|50%]] - [[User_talk:Bomb_Bloke:75acc1|75%]] - [[User_talk:Bomb_Bloke:100acc1|100%]]

New data (with a roof, vertical shot data might actually be worth something): [[User_talk:Bomb_Bloke:0acc2|0%]] - [[User_talk:Bomb_Bloke:25acc2|25%]] - [[User_talk:Bomb_Bloke:50acc2|50%]] - [[User_talk:Bomb_Bloke:75acc2|75%]] - [[User_talk:Bomb_Bloke:100acc2|100%]]

Comma separated data, one shot per line. First three columns are the absolute tile x/y/z co-ords of where the shot ended up hitting (keeping in mind the shooter is at tile 24/49/2). Next three columns are the x/y/z of where the shot landed, relative to where the shooter is. Final two columns are the important ones, they cover the horizontal and vertical angles the shot took, respectively.

Yes, the wiki doesn't represent it very neatly. Use the edit button to get the line breaks back.

Hrm. Looks like the max angle at 75% comes out to 11.53 degrees... Not 7.1. :(

- [[User:Bomb Bloke|Bomb Bloke]] 09:37, 18 March 2009 (EDT)

----

[[image:BBFiringPointTest6.png|thumb|200px]]
Here is a graph that somewhat better displays the results of my initial 0FA results. The blue line represents the recorded numbers (2550 different values). The red line represents an equal number of results generated by the spreadsheet formula "SIN(RAND()*1.5)*28.64788975*IF(RAND()>0.5;-1;1)".

(Which is, effectively, "The sine of a random number between -1.5 and 1.5 multiplied by half a radian").

Unfortunately the two formulas don't line up (even if you mirror 'em on the diagonal), but they're fairly close. Much closer then the exponential equations I tried graphing, at any rate. I'm thinking I might be able to get something better still with TAN, but I don't seem to be having much luck with that...

- [[User:Bomb Bloke|Bomb Bloke]] 02:18, 15 April 2009 (EDT)

: tan eyeballs great if you assume the distribution going in is some flavor of "sum of linear distributions". tan-1(25°)=0.466307658155; halving this and taking the tangent again gets me ~13.1°, which is reached about 1/16th of the way across. I'm assuming some sort of discretization error for the asymmetry. (My initial gut reaction was "sum of two linear distributions", but that isn't correct; that would have landed about 1/8th of the way across. The quick-and-dirty way to fake a bell curve is to sum three linear distributions.) -- [[User:Zaimoni|Zaimoni]] 11:52, 15 April 2009
(CDT)

: Per geometric check; tan works if the incoming angle is from a sum of three linear distributions. That is: tan(K*rand()*rand()*rand()) should recover the graph up to discretization error, for some K. -- [[User:Zaimoni|Zaimoni]] 12:02, 15 April 2009 (CDT)

:: Is there any chance it's some function of (Kx rand(x), Ky rand(y), Kz rand(z)? [[User:Spike|Spike]] 17:53, 15 April 2009 (EDT)

::: It depends on what you mean...

::: I was presuming rand() was a zero-parameter function that needed "massaging" to get to any range other than its default. C rand() would be 0..RAND_MAX. XCOM almost certainly has a wrapper that returns values in a range 0..N. Given when XCOM was written, I don't think it has any sort of floating-point RNG. I wrote K to subsume all of the range-massaging that was needed.

::: That said, a general sum of three linear distributions would have been tan(K1*rand()+K2*rand()+K3*rand()-AVERAGE) [ignoring overflow issues], where AVERAGE is the statistical average expected from K1*rand()+K2*rand()+K3*rand(). The geometric check almost certainly wouldn't pass if the three constants were obviously distinct. The actual expression I'd try retrofitting is tan(K*(rand()+rand()+rand())-AVERAGE). -- [[User:Zaimoni|Zaimoni]] 14:07, 16 April 2009 (CDT)

:::: If rand() was to receive any parameter at all, it'd be a seed; but calling the function three times should result in three different numbers anyway (typically you seed the RNG first). I'd be surprised if even the original game didn't have a floating RNG. Even back on the Spectrums/Commodores/BBCs you could generate within most any range by typing something like RNG*N. I tried graphing TAN(RAND()*1.5) then TAN(1.5*(RAND()+RAND()+RAND())-2.25), though the first formula wasn't right and the second was worse. :( It's a bit too steep (a little like what you get from 1/x but flopped around). Maybe something a bit higher then 1.5 would sort that out, but I dunno how high you can legally go with TAN? - [[User:Bomb Bloke|Bomb Bloke]] 20:36, 16 April 2009 (EDT)

::::: tan goes unbounded at ±π/2 radians i.e. ±90° Given that the initial bounds appear to be ~±25°, I'd calibrate things so that we were looking at a total span of 50° i.e. ~0.872 radians. In radians, with rand() being a uniform distribution 0..1: TAN(0.872*(rand()+rand()+rand())-0.436) would be my guess.

::::: XCOM 1.2 had some source code comments indicating that the C source targeted Watcom C. That means the "easy rand" available is the C standard library rand(), which without processing returns an integer from 0..RAND_MAX, where RAND_MAX may be as low as 32,767. -- [[User:Zaimoni|Zaimoni]] 12:36, 17 April 2009 (CDT)

: 55 degrees horizontal deviation range corresponds to 440 1/8 degree units; quick-but-lousy-RNG C source for the eighths-of-degrees input to the tangent function at accuracy 0 should be <code>(rand()%147+rand()%147+rand()%147)-219</code> . This plausibly is from a "deviation output" function that returns 73 at accuracy 0, 45 at accuracy 50, and 31 at accuracy 75. Corresponding psuedocode:
<pre>const int tmp = acc_func(...);
const int rng_scale = 2*tmp+1;
const int rng_bias = 3*tmp;

....

(rand()%rng_scale+rand()%rng_scale+rand()%rng_scale)-rng_bias;</pre>

: -- [[User:Zaimoni|Zaimoni]] 13:58, 26 December 2010 (CST)

: That means the deviation output function should be something like <tt>73-INT(14*Accuracy/25)</tt>. -- [[User:Zaimoni|Zaimoni]] 14:31, 26 December 2010 (CST)

===Vertical Error vs Horizontal Error===

Hmmm.... I don't know about you guys, but I notice that in my games, when firing from Level 0 at enemies on level 0, my soldiers seem like their vertical deviation tends to be very small, even with high inaccuracy. Their horizontal deviation seems much much larger. Is this my imagination?

- [[User:Jasonred|Jasonred]]

----

You're quite right, they're two different things. There's enough error there to miss at point blank range against a short target, but still nothing like what you get in the horizontal scheme of things.

- [[User:Bomb Bloke|Bomb Bloke]] 08:46, 17 April 2009 (EDT)

== Target Size ==

Units are cylinders, made up of a [[LOFTEMPS.DAT]] layer determined by [[UNITREF.DAT|UnitRef[48]/[52]]], stacked according to their [[Height]].

The full purpose of UnitRef[52] is still in doubt, though it always seems to mirror the value held at [48]. My personal guess is that one is (or at least, was supposed to be) used when bullets come in on one angle, and the other value is used when bullets come in on a perpendicular-ish angle (hence allowing the cylinder to act more like a squished tube, which is closer to the shape of a real person - or it would do if 48/52 didn't always match).

So, yeah, set [48] to 0, all your units get set to an empty LOFTemps record, they cannot be seen/hit by the aliens. Hurrah.

== See Also ==

Pages relevant to this subject:
*[[Firing Accuracy]]
*[[Accuracy formula]]
*[[Firing Accuracy Testing]]
*[[Height]]
*[[LOFTEMPS.DAT]]

User talk:Bomb Bloke:Firing Accuracy

2010-12-26T20:27:45Z

Zaimoni: augment retrofiltting

{{tocright}}Consider this [[User:Bomb Bloke|Bomb Bloke's]] draft/discussion about firing accuracy. This topic has been dragging on for quite some time now, so I figure it to about time I had a stab at it.

My view on the matter is this: When you fire a gun, UFO works out the horizontal and vertical angles between your unit and the target, then modifies these depending on your [[Accuracy_formula|overall accuracy stat]].

Say for example you have a perfect 100% (or better) "accuracy". The lines are nearly unmodified, and so near guaranteed to hit (assuming there are no obstructions, in which case you should get a "No LOF!" message when you attempt to fire. Note that the game doesn't ALWAYS give this message and will sometimes allow you to attempt "impossible" shots. In these cases, less-then-perfect aim might still allow the shot to land).

As your rated accuracy decreases, target size and distance become all important: As size decreases and distance increases, the range of angles that could land a hit fall. As accuracy decreases, the range of angles that a shot can take rises and so it becomes less likely that a given shot will fall within the "hitting" range of angles.

(As for why multiple angles can "hit", think of your target as a dartboard: Perfect aim would result in a bullseye, approximate aim would still hit the board, and bad aim would miss altogether. However, in X-Com, you get full "points" so long as the bullet hits the target at all).

That is to say, the ultimate firing accuracy formula would be (range of acceptable hitting angles)/(range of possible firing angles). Assuming, of course, that when firing you're just as likely to fire at your maximum "worst" angle as you are your "best", the range of angles that can hit is determined by target distance and size, and the range of angles that can be fired along is determined by your rated firing accuracy.

However, as it turns out, the angle your shots take isn't entirely random - they follow a bell curve. You're more likely to at least hit near the target then you are to get a massive "air ball" shot. So the formula in truth will end up looking a bit more complex then that.

== Firing Point Origin ==

To get the absolute range of angles a unit can fire along, you first need to know where a unit is firing from. To this end I created a copy of my game folder and modified a save game, some terrain files, and the LOF templates.

[[image:BBFiringPointTest2.png|right|thumb|200px|A basic map of a tile. As it turns out the Y axis really points the other way.]]Now, when we talk about UFO maps, we generally refer to their dimensions in terms of how many tiles there are. However, each tile is really made up of smaller "points": A 16x16x24 point space. This means that a 30x30x4 map has 3,600 tiles in it, and 22,118,400 points within those. When a unit fires, he doesn't aim from his tile at his target's tile, he aims from a point within his tile at a point within his target's tile.

This first test was aimed at discovering exactly where a shot originates from, by creating tiles on units to selectively block their LOF. By seeing which tiles did and which did not, it could be seen exactly (or, at least, as accurately as I think I'm going to get it) where the shots were coming from.

[[image:BBFiringPointTest3.png|right|thumb|200px|The Empire's got nothing on BB's clone army.]]The first row of units served as targets for the second, which stood on tiles similar to the large earth blocks you see in bases but with one layer removed from each. Each therefore entirely blocked LOF so long as the removed layer wasn't at the same height as the unit's firing origin point. The only unit able to fire through the gap was the one sitting on the tile with the third layer down removed.

However, when defining tiles with [[LOFTEMPS.DAT|LOFTemps]], you can only stack the layers 12 high. Presumably the game "double stacks" them to make the resulting 24 point high object. Because of this, the removed layers accounted for two possible Z co-ordinates, meaning the exact value there is still unknown. Might be able to work something out to get it more precise, I dunno.

The third row stood on walls facing to the east/west. Unlike the second row, in this example I moved a single thin wall through each tile, as opposed to moving a "gap". This meant that only one unit would not be able to fire, and that was the one sitting on the ninth tile (made up of my layers from LOFTemps[15]).

[[image:BBFiringPointTest1.png|right|thumb|200px|LOFtemps used, as opposed to the [[LOFTEMPS.DAT|usual set]].]]The forth row followed more or less the same concept, with the walls facing north/south. Only the first unit was unable to fire (LOFTemps[23]).

So! With this information, getting a (x,y,z) co-oridinate is easy enough: It's either (8,15,18) or (8,15,19) (the Z co-ord being imprecise due to the 12 LOFTemp layer limitation).

Note that this value only goes for units with a facing of north. When I get time I'll go through and work it out for the other directions. Furthermore, Sectoids are likely to have a lower firing point (as their guns are rendered lower on the screen).

----

[[Image:origins.png|frame]]

I found an interesting piece of code (offset 40D8E0 for the curious). The formula for the starting zpos when firing looks like this:
''unitpos.zpos*24+unitref.terrain_height-unitref.standing_height+27-unitref.floating_height''
and for kneeling units:
''unitpos.zpos*24+unitref.terrain_height-unitref.kneeling_height+27-unitref.floating_height''
(unitref.terrain_height is offset 0x27 in unitref.dat)
I did a live check with a debugger, for a standing unit on the lowest level it gives this:
''3*24+0-16+27-0=77''
Since the engine seems to use zpos=0 for the ceiling of the topmost level, then the floor must be at offset 4*24=96. floor_level-firing_level=96-77=19, in accord with your empirical results.

Now for xpos and ypos, the engine uses several tables, indexed by the facing orientation (offset 0xa in unitref.dat):
''.data:0046B5E4 dw 8,0Eh,0Fh,0Fh, 8, 1, 1, 1''
for xpos, and
''.data:0046B5C4 dw 1, 1, 8,0Fh,0Fh,0Fh, 8, 1''
for ypos. When facing north, the shot should come from 8x1x19. Note that it is in disaccord with your experience. Maybe you don't use the same point of origin as the engine? [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

You are correct. Moving my origin to match yours brings my data into line (I was limited to guessing it's correct location). Awesome to see the ceiling size confirmed at long last. :D - [[User:Bomb Bloke|Bomb Bloke]] 02:52, 8 May 2008 (PDT)

----

Big units use 2 other tables located at offsets 46B604 and 46B624. I did not try to change these values to see if it changes the position where the shots come from. [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

The xpos/ypos information agrees with my own in vivo research (it explains several LOS different than LOF paradoxes I have explicitly verified). -- [[User:Zaimoni|Zaimoni]] 11:49, 3 May 2008 (CDT)

== Rated Accuracy Vs Angle Range ==

[[image:BBFiringPointTest4.png|thumb|200px]][[image:BBFiringPointTest5.png|thumb|200px]]Just a few results before I go off camping for the weekend. First off, note that [http://www.strategycore.co.uk/forums/index.php?act=ST&f=22&t=5805 the logger] used on this occasion is one I wrote up a year ago. It's not entirely accurate, and needs to approximate values (this is because I can only get it to think in terms of angles between tiles, as opposed to angles between points - as a result you see "steps" in the line graphs provided here). I've thought up some improvements for it (like sticking a roof in the map used so I can get some decent vertical angle stats), but even if I implemented those it'd still never be "accurate".

That said, I got [http://pastebin.com/mcbc752a 2550 results for 0% firing accuracy] overnight and [http://pastebin.com/mdf60034 1876 for 50%] today. I've got the system in concern running trials for 25% until tomorrow.

The graphs displayed summarise these angles. Essentially they go from "those that went to the left" across to "those that went to the right". The longer the line stays at a given level, the more shots took that angle.

At 0% accuracy, the largest horizontal angle I got AWAY from the target was 27.5 degrees (that is to say, a shot could go anywhere within a range of 55 degrees), the average angle being 7.32 degrees. With the side graph you can get an idea of the distribution: Your shots are more likely to hit or at least get close then they are to be far away.

Bumping the rated accuracy to 50% lowered the maximum angle to 17.01 degrees (average of 2.75). Again, you're a lot more likely to get close to the target then you are to reach the possible extremes.

I've since done tests at 100% accuracy and found that the same curve exists, just squished right down. You still have a chance to miss, but only by slight amounts. A formula should be apparent in there somewhere.

At a glance I think it's an exponential equation divided by your rated accuracy? With a few more tests I suppose it'd be more apparent.

: My theory is this that the program first runs "was shot accurate?" check. If yes, then shot deviates 0 and hits the target. If shot misses, calculate path of bullet. Path of bullet follows formula that gives that bell curve.
: I rather suspect that at 25% accuracy, 25% of your shots will be on target, at 50%, 50% will be on target, so on and so forth.
: There might be some additional weird "random drift" that makes 100% and higher accuracy still miss. *Shrugs*. - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: I am absolutely convinced that there is no "was shot accurate?" check. If there was one, I reckon it'd be apparent on the graphs here. I could be wrong, but I believe I've seen no data that supports the theory. No, finding that a certain accuracy rating "seems right" when firing from a certain distance is not supporting data, in that this is the case regardless of whether an "accurate shot" check exists. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)
: Despite the fact it will make your life even harder, I have to remind you that there is also PARTIAL COVER to factor into the tests... what happens when the target is behind a window (modded to be indestructible?), behind a hedge, only his head is visible poking out through the floor (bug here lol)... sometimes a shot will go THROUGH a window, sometimes it will HIT the window... - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: Remember, the "accuracy formula" I'm looking to determine simply returns an angle, which, dependant on your overall accuracy score an the random number generator, will go off on some who knows what direction. Whether that angle leads to the target is dependent on the visible target area versus the angles you'll get based on your accuracy stat (this "target area" concept is the purpose of the next section down, mostly unwritten because it's pointless until THIS formula is figured out).

:: That is to say, there's no real formula that can tell you the REAL chance to hit a target without actually inputting all the tile data in addition to using the "angles formula" I'm after here. Luckily, once the angle formula is determined, it shouldn't be too hard to have my battlescape editor calculate the "true" chance of a shot hitting. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)

: I wonder if it's possible that the game's maximum firing angle (e.g. at zero accuracy) is one radian - about 57.3 degrees? This is near your observed limit of 55 degrees. The game engine would probably use trig functions based on radians as I believe they are the most efficient. Given the power of the computers they were programming for, this vector work was pushing the envelope so they would need to be efficient. - [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)
::I would say that yes, given the close proximity (and the inherent inaccuracy of my logger, due to the inability to pick up on the precise ''point'' a bullet hit), one radian is correct.

::The [[COS.DAT]] page will probably be relevant at some point, dunno if you've read that. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Also could you clarify the axes on these 2 graphs/histograms? I'm having a lot of trouble understanding them. Is it possible that the vertical axis should be frequency, and the angle should be on the horizontal axis? Or am I being dumb? If I'm understanding them correctly, we are not seeing a linear distribution of error angles - as you would get from say

ActualAngle=AngleToTarget+(rand(57)-(57/2))

:what we are getting is angles that cluster together near the correct aimpoint, and frequency falls off quickly as you move away from the correct aimpoint.

:: You are reading the charts correctly. The vertical axis shows how often a specific angle was picked to fire along by the game, and the horizontal axis shows the angles themselves. The reason the charts are symetrical is because shots can either go to the left or right of the target (an angle of 0 means it hit). Even with 0 FFA, you're a lot more likely to send a bullet near the target then you are to send one on the maximum diverging angle - hence my statement, "I think it's an exponential equation divided by your rated accuracy". - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Guess: The graphs look not unlike a tangent or inverse tangent function. That might suggest that the firing function injects a linear amount of perpendicular drift (horizontal and maybe vertical) onto the bullet's vector. Maybe try graphing the tan() or arctan() of the data from the "zero accuracy" tests, and see if you get a horizontal straight line.

: arctan (0.5), which might be relevant if maximum "perpendicular error" is 1 map square wide per map distance unit, is 26.565 degrees, near to your value of 27.5 degrees. Arctan (0.25), which corresponding to half that "perpendicular error", half a map square wide per map distance unit (and maybe corresponding to 50% FFA????), is 14.036 degrees, again near to your value of 17 degrees for 50% FFA. But only 'near', and higher. Hmm. Your data have a horizontal granularity of 1/16th of a map square distance unit, is that right? So there could be some data slightly outside the true upper limit for angles. It depends on the range to your target in your test setup I guess. [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)

:: This is where my brain starts to melt, mind you, it's 3:15am here so I'm probably not good for any number crunching right now. But I reckon you're onto something even if I can't wrap my brain around what!

:: I put the target about 25 squares back (middle of the map). Really can't remember. Ideally I'd've set him to be a pixel in size, but back then the "using LOFTemps for unit size" thing was just a theory I had, not a proven fact (I never got around to updating this page when it WAS proven, that's how long these notes have been here).

:: Yes, granularity is a 16th of a standard user-visible map tile. On the horizontal plane anyway. Can't remember if I set it to 24ths on the vertical, but I probably did. The problem is, of course, that it can only pick up data according to whether a bullet hit a tile or not (as opposed to data on where the tile was hit), so although the range of angles should be "close to accurate" there's still those nasty steps everywhere which have to be "guesstamated".

:: I never really bothered much with the vertical data as I was mostly "proving the concept", figured I'd get to that later. I know I logged it (I was even able to draw an ellipse to show where all the bullets would fall, your maximum vertical angles are of course no where near your maximum horizontal ones), but I can't find the charts in concern. They weren't that good anyway as the test map had no ceiling.

:: I distinctly remember logging and graphing the 100% FFA data but can't find that either. Probably deleted it from my system (in the misguided belief that I'd uploaded it all here). I cannot find any of my related logs at all, in fact, just a single zip file with the logger, test map and automated script file ready to go. Again, this may be because I've deleted them, or because I have nearly ten thousand files in my UFO directory. My main one, anyway. I have a few such directories. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

: OK. The curve you graph above for "zero accuracy" looks not unlike what happens if you graph tan(x) (in degrees), where x is from +0.5 to +0.5. But I think that's a coincidence, since your graph is not a standard histogram - you are showing "frequency" by the length of lines on the x axis, rather than by the height of bars along the y axis as in a standard histogram. In order to turn your graph into a standard histogram it would need to be more or less inverted I think.
: The link to the "zero accuracy" data set is broken now. From what you said above, the data is lost now, which is a shame as it would be nice to do a histogram of tan(a) for all the angles "a" in that data set. You might see a flat line, linear distribution. Or not. If the angles are "bunching up" in frequency toward the target centre, then that suggests a ''linear perpendicular'' distribution of angles. With a linear perpendicular distribution (eg varies by +/- 0 to N units, perpendicular to the path to target, per unit of distance), you would expect a "bunched" angular distribution, i.e. if you sorted all the angles in the data set, the separation between one angle and the next widest would steadily increase.
: The Z component is going to complicate things and prevent finding an exact solution. For example, say that the Z (vertical) error/cone and X (lateral) error/cone are not independent of each other. For example, they might be constrained to add up to some constant N that's related to FFA: Z + Y < N. Or in fact, it might be more like (vertical x 4 + horizontal x 1) < N (since we suspect the actual 'bullet group' is an oval, wider than it is high, rather than a circle). A circle is almost the simplest case, but again unless Z and X are totally independent, you're not going to find a close fit for the function without knowing both terms. Hopefully the oval is very 'flat' and so the horizontal-only function will be a good enough approximation of the data to get in the right ballpark. Or even better, maybe the Z component is a totally independent function. Hope so.
: Let me make a prediction or a series of predictions then for maximum angle off-target:
:* 0% FFA = 1.0 perpendicular error per unit distance = +/ 0.500, arctan(0.500) = +/- 26.6 degrees
:* 50% FFA = 0.5 perpendicular error per unit distance = +/ 0.250, arctan(0.250) = +/- 14.0 degrees
:* 75% FFA = .25 perpendicular error per unit distance = +/ 0.125, arctan(0.125) = +/- 7.1 degrees
:* in general, horizontal maximum angle off target = +/- arctan(((100-FFA)/100)/2)
: Well that's most likely wrong but it's good to have a starting point for testing! [[User:Spike|Spike]] 17:40, 15 March 2009 (EDT)

Hey, guess what? First thing on completing a fresh round of tests, I discover all my old logs.

Of course.

Originals (with no roof on the map so the vertical shot data is a bit iffy): [[User_talk:Bomb_Bloke:0acc1|0%]] - [[User_talk:Bomb_Bloke:25acc1|25%]] - [[User_talk:Bomb_Bloke:50acc1|50%]] - [[User_talk:Bomb_Bloke:75acc1|75%]] - [[User_talk:Bomb_Bloke:100acc1|100%]]

New data (with a roof, vertical shot data might actually be worth something): [[User_talk:Bomb_Bloke:0acc2|0%]] - [[User_talk:Bomb_Bloke:25acc2|25%]] - [[User_talk:Bomb_Bloke:50acc2|50%]] - [[User_talk:Bomb_Bloke:75acc2|75%]] - [[User_talk:Bomb_Bloke:100acc2|100%]]

Comma separated data, one shot per line. First three columns are the absolute tile x/y/z co-ords of where the shot ended up hitting (keeping in mind the shooter is at tile 24/49/2). Next three columns are the x/y/z of where the shot landed, relative to where the shooter is. Final two columns are the important ones, they cover the horizontal and vertical angles the shot took, respectively.

Yes, the wiki doesn't represent it very neatly. Use the edit button to get the line breaks back.

Hrm. Looks like the max angle at 75% comes out to 11.53 degrees... Not 7.1. :(

- [[User:Bomb Bloke|Bomb Bloke]] 09:37, 18 March 2009 (EDT)

----

[[image:BBFiringPointTest6.png|thumb|200px]]
Here is a graph that somewhat better displays the results of my initial 0FA results. The blue line represents the recorded numbers (2550 different values). The red line represents an equal number of results generated by the spreadsheet formula "SIN(RAND()*1.5)*28.64788975*IF(RAND()>0.5;-1;1)".

(Which is, effectively, "The sine of a random number between -1.5 and 1.5 multiplied by half a radian").

Unfortunately the two formulas don't line up (even if you mirror 'em on the diagonal), but they're fairly close. Much closer then the exponential equations I tried graphing, at any rate. I'm thinking I might be able to get something better still with TAN, but I don't seem to be having much luck with that...

- [[User:Bomb Bloke|Bomb Bloke]] 02:18, 15 April 2009 (EDT)

: tan eyeballs great if you assume the distribution going in is some flavor of "sum of linear distributions". tan-1(25°)=0.466307658155; halving this and taking the tangent again gets me ~13.1°, which is reached about 1/16th of the way across. I'm assuming some sort of discretization error for the asymmetry. (My initial gut reaction was "sum of two linear distributions", but that isn't correct; that would have landed about 1/8th of the way across. The quick-and-dirty way to fake a bell curve is to sum three linear distributions.) -- [[User:Zaimoni|Zaimoni]] 11:52, 15 April 2009
(CDT)

: Per geometric check; tan works if the incoming angle is from a sum of three linear distributions. That is: tan(K*rand()*rand()*rand()) should recover the graph up to discretization error, for some K. -- [[User:Zaimoni|Zaimoni]] 12:02, 15 April 2009 (CDT)

:: Is there any chance it's some function of (Kx rand(x), Ky rand(y), Kz rand(z)? [[User:Spike|Spike]] 17:53, 15 April 2009 (EDT)

::: It depends on what you mean...

::: I was presuming rand() was a zero-parameter function that needed "massaging" to get to any range other than its default. C rand() would be 0..RAND_MAX. XCOM almost certainly has a wrapper that returns values in a range 0..N. Given when XCOM was written, I don't think it has any sort of floating-point RNG. I wrote K to subsume all of the range-massaging that was needed.

::: That said, a general sum of three linear distributions would have been tan(K1*rand()+K2*rand()+K3*rand()-AVERAGE) [ignoring overflow issues], where AVERAGE is the statistical average expected from K1*rand()+K2*rand()+K3*rand(). The geometric check almost certainly wouldn't pass if the three constants were obviously distinct. The actual expression I'd try retrofitting is tan(K*(rand()+rand()+rand())-AVERAGE). -- [[User:Zaimoni|Zaimoni]] 14:07, 16 April 2009 (CDT)

:::: If rand() was to receive any parameter at all, it'd be a seed; but calling the function three times should result in three different numbers anyway (typically you seed the RNG first). I'd be surprised if even the original game didn't have a floating RNG. Even back on the Spectrums/Commodores/BBCs you could generate within most any range by typing something like RNG*N. I tried graphing TAN(RAND()*1.5) then TAN(1.5*(RAND()+RAND()+RAND())-2.25), though the first formula wasn't right and the second was worse. :( It's a bit too steep (a little like what you get from 1/x but flopped around). Maybe something a bit higher then 1.5 would sort that out, but I dunno how high you can legally go with TAN? - [[User:Bomb Bloke|Bomb Bloke]] 20:36, 16 April 2009 (EDT)

::::: tan goes unbounded at ±π/2 radians i.e. ±90° Given that the initial bounds appear to be ~±25°, I'd calibrate things so that we were looking at a total span of 50° i.e. ~0.872 radians. In radians, with rand() being a uniform distribution 0..1: TAN(0.872*(rand()+rand()+rand())-0.436) would be my guess.

::::: XCOM 1.2 had some source code comments indicating that the C source targeted Watcom C. That means the "easy rand" available is the C standard library rand(), which without processing returns an integer from 0..RAND_MAX, where RAND_MAX may be as low as 32,767. -- [[User:Zaimoni|Zaimoni]] 12:36, 17 April 2009 (CDT)

: 55 degrees horizontal deviation range corresponds to 440 1/8 degree units; quick-but-lousy-RNG C source for the eighths-of-degrees input to the tangent function at accuracy 0 should be <code>(rand()%147+rand()%147+rand()%147)-219</code> . This plausibly is from a "deviation output" function that returns 73 at accuracy 0, 45 at accuracy 50, and 31 at accuracy 75. Corresponding psuedocode:
<pre>const int tmp = acc_func(...);
const int rng_scale = 2*tmp+1;
const int rng_bias = 3*tmp;

....

(rand()%rng_scale+rand()%rng_scale+rand()%rng_scale)-rng_bias;</pre>

: -- [[User:Zaimoni|Zaimoni]] 13:58, 26 December 2010 (CST)

===Vertical Error vs Horizontal Error===

Hmmm.... I don't know about you guys, but I notice that in my games, when firing from Level 0 at enemies on level 0, my soldiers seem like their vertical deviation tends to be very small, even with high inaccuracy. Their horizontal deviation seems much much larger. Is this my imagination?

- [[User:Jasonred|Jasonred]]

----

You're quite right, they're two different things. There's enough error there to miss at point blank range against a short target, but still nothing like what you get in the horizontal scheme of things.

- [[User:Bomb Bloke|Bomb Bloke]] 08:46, 17 April 2009 (EDT)

== Target Size ==

Units are cylinders, made up of a [[LOFTEMPS.DAT]] layer determined by [[UNITREF.DAT|UnitRef[48]/[52]]], stacked according to their [[Height]].

The full purpose of UnitRef[52] is still in doubt, though it always seems to mirror the value held at [48]. My personal guess is that one is (or at least, was supposed to be) used when bullets come in on one angle, and the other value is used when bullets come in on a perpendicular-ish angle (hence allowing the cylinder to act more like a squished tube, which is closer to the shape of a real person - or it would do if 48/52 didn't always match).

So, yeah, set [48] to 0, all your units get set to an empty LOFTemps record, they cannot be seen/hit by the aliens. Hurrah.

== See Also ==

Pages relevant to this subject:
*[[Firing Accuracy]]
*[[Accuracy formula]]
*[[Firing Accuracy Testing]]
*[[Height]]
*[[LOFTEMPS.DAT]]

User talk:Bomb Bloke:Firing Accuracy

2010-12-26T19:59:32Z

Zaimoni:

{{tocright}}Consider this [[User:Bomb Bloke|Bomb Bloke's]] draft/discussion about firing accuracy. This topic has been dragging on for quite some time now, so I figure it to about time I had a stab at it.

My view on the matter is this: When you fire a gun, UFO works out the horizontal and vertical angles between your unit and the target, then modifies these depending on your [[Accuracy_formula|overall accuracy stat]].

Say for example you have a perfect 100% (or better) "accuracy". The lines are nearly unmodified, and so near guaranteed to hit (assuming there are no obstructions, in which case you should get a "No LOF!" message when you attempt to fire. Note that the game doesn't ALWAYS give this message and will sometimes allow you to attempt "impossible" shots. In these cases, less-then-perfect aim might still allow the shot to land).

As your rated accuracy decreases, target size and distance become all important: As size decreases and distance increases, the range of angles that could land a hit fall. As accuracy decreases, the range of angles that a shot can take rises and so it becomes less likely that a given shot will fall within the "hitting" range of angles.

(As for why multiple angles can "hit", think of your target as a dartboard: Perfect aim would result in a bullseye, approximate aim would still hit the board, and bad aim would miss altogether. However, in X-Com, you get full "points" so long as the bullet hits the target at all).

That is to say, the ultimate firing accuracy formula would be (range of acceptable hitting angles)/(range of possible firing angles). Assuming, of course, that when firing you're just as likely to fire at your maximum "worst" angle as you are your "best", the range of angles that can hit is determined by target distance and size, and the range of angles that can be fired along is determined by your rated firing accuracy.

However, as it turns out, the angle your shots take isn't entirely random - they follow a bell curve. You're more likely to at least hit near the target then you are to get a massive "air ball" shot. So the formula in truth will end up looking a bit more complex then that.

== Firing Point Origin ==

To get the absolute range of angles a unit can fire along, you first need to know where a unit is firing from. To this end I created a copy of my game folder and modified a save game, some terrain files, and the LOF templates.

[[image:BBFiringPointTest2.png|right|thumb|200px|A basic map of a tile. As it turns out the Y axis really points the other way.]]Now, when we talk about UFO maps, we generally refer to their dimensions in terms of how many tiles there are. However, each tile is really made up of smaller "points": A 16x16x24 point space. This means that a 30x30x4 map has 3,600 tiles in it, and 22,118,400 points within those. When a unit fires, he doesn't aim from his tile at his target's tile, he aims from a point within his tile at a point within his target's tile.

This first test was aimed at discovering exactly where a shot originates from, by creating tiles on units to selectively block their LOF. By seeing which tiles did and which did not, it could be seen exactly (or, at least, as accurately as I think I'm going to get it) where the shots were coming from.

[[image:BBFiringPointTest3.png|right|thumb|200px|The Empire's got nothing on BB's clone army.]]The first row of units served as targets for the second, which stood on tiles similar to the large earth blocks you see in bases but with one layer removed from each. Each therefore entirely blocked LOF so long as the removed layer wasn't at the same height as the unit's firing origin point. The only unit able to fire through the gap was the one sitting on the tile with the third layer down removed.

However, when defining tiles with [[LOFTEMPS.DAT|LOFTemps]], you can only stack the layers 12 high. Presumably the game "double stacks" them to make the resulting 24 point high object. Because of this, the removed layers accounted for two possible Z co-ordinates, meaning the exact value there is still unknown. Might be able to work something out to get it more precise, I dunno.

The third row stood on walls facing to the east/west. Unlike the second row, in this example I moved a single thin wall through each tile, as opposed to moving a "gap". This meant that only one unit would not be able to fire, and that was the one sitting on the ninth tile (made up of my layers from LOFTemps[15]).

[[image:BBFiringPointTest1.png|right|thumb|200px|LOFtemps used, as opposed to the [[LOFTEMPS.DAT|usual set]].]]The forth row followed more or less the same concept, with the walls facing north/south. Only the first unit was unable to fire (LOFTemps[23]).

So! With this information, getting a (x,y,z) co-oridinate is easy enough: It's either (8,15,18) or (8,15,19) (the Z co-ord being imprecise due to the 12 LOFTemp layer limitation).

Note that this value only goes for units with a facing of north. When I get time I'll go through and work it out for the other directions. Furthermore, Sectoids are likely to have a lower firing point (as their guns are rendered lower on the screen).

----

[[Image:origins.png|frame]]

I found an interesting piece of code (offset 40D8E0 for the curious). The formula for the starting zpos when firing looks like this:
''unitpos.zpos*24+unitref.terrain_height-unitref.standing_height+27-unitref.floating_height''
and for kneeling units:
''unitpos.zpos*24+unitref.terrain_height-unitref.kneeling_height+27-unitref.floating_height''
(unitref.terrain_height is offset 0x27 in unitref.dat)
I did a live check with a debugger, for a standing unit on the lowest level it gives this:
''3*24+0-16+27-0=77''
Since the engine seems to use zpos=0 for the ceiling of the topmost level, then the floor must be at offset 4*24=96. floor_level-firing_level=96-77=19, in accord with your empirical results.

Now for xpos and ypos, the engine uses several tables, indexed by the facing orientation (offset 0xa in unitref.dat):
''.data:0046B5E4 dw 8,0Eh,0Fh,0Fh, 8, 1, 1, 1''
for xpos, and
''.data:0046B5C4 dw 1, 1, 8,0Fh,0Fh,0Fh, 8, 1''
for ypos. When facing north, the shot should come from 8x1x19. Note that it is in disaccord with your experience. Maybe you don't use the same point of origin as the engine? [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

You are correct. Moving my origin to match yours brings my data into line (I was limited to guessing it's correct location). Awesome to see the ceiling size confirmed at long last. :D - [[User:Bomb Bloke|Bomb Bloke]] 02:52, 8 May 2008 (PDT)

----

Big units use 2 other tables located at offsets 46B604 and 46B624. I did not try to change these values to see if it changes the position where the shots come from. [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)

----

The xpos/ypos information agrees with my own in vivo research (it explains several LOS different than LOF paradoxes I have explicitly verified). -- [[User:Zaimoni|Zaimoni]] 11:49, 3 May 2008 (CDT)

== Rated Accuracy Vs Angle Range ==

[[image:BBFiringPointTest4.png|thumb|200px]][[image:BBFiringPointTest5.png|thumb|200px]]Just a few results before I go off camping for the weekend. First off, note that [http://www.strategycore.co.uk/forums/index.php?act=ST&f=22&t=5805 the logger] used on this occasion is one I wrote up a year ago. It's not entirely accurate, and needs to approximate values (this is because I can only get it to think in terms of angles between tiles, as opposed to angles between points - as a result you see "steps" in the line graphs provided here). I've thought up some improvements for it (like sticking a roof in the map used so I can get some decent vertical angle stats), but even if I implemented those it'd still never be "accurate".

That said, I got [http://pastebin.com/mcbc752a 2550 results for 0% firing accuracy] overnight and [http://pastebin.com/mdf60034 1876 for 50%] today. I've got the system in concern running trials for 25% until tomorrow.

The graphs displayed summarise these angles. Essentially they go from "those that went to the left" across to "those that went to the right". The longer the line stays at a given level, the more shots took that angle.

At 0% accuracy, the largest horizontal angle I got AWAY from the target was 27.5 degrees (that is to say, a shot could go anywhere within a range of 55 degrees), the average angle being 7.32 degrees. With the side graph you can get an idea of the distribution: Your shots are more likely to hit or at least get close then they are to be far away.

Bumping the rated accuracy to 50% lowered the maximum angle to 17.01 degrees (average of 2.75). Again, you're a lot more likely to get close to the target then you are to reach the possible extremes.

I've since done tests at 100% accuracy and found that the same curve exists, just squished right down. You still have a chance to miss, but only by slight amounts. A formula should be apparent in there somewhere.

At a glance I think it's an exponential equation divided by your rated accuracy? With a few more tests I suppose it'd be more apparent.

: My theory is this that the program first runs "was shot accurate?" check. If yes, then shot deviates 0 and hits the target. If shot misses, calculate path of bullet. Path of bullet follows formula that gives that bell curve.
: I rather suspect that at 25% accuracy, 25% of your shots will be on target, at 50%, 50% will be on target, so on and so forth.
: There might be some additional weird "random drift" that makes 100% and higher accuracy still miss. *Shrugs*. - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: I am absolutely convinced that there is no "was shot accurate?" check. If there was one, I reckon it'd be apparent on the graphs here. I could be wrong, but I believe I've seen no data that supports the theory. No, finding that a certain accuracy rating "seems right" when firing from a certain distance is not supporting data, in that this is the case regardless of whether an "accurate shot" check exists. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)
: Despite the fact it will make your life even harder, I have to remind you that there is also PARTIAL COVER to factor into the tests... what happens when the target is behind a window (modded to be indestructible?), behind a hedge, only his head is visible poking out through the floor (bug here lol)... sometimes a shot will go THROUGH a window, sometimes it will HIT the window... - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
:: Remember, the "accuracy formula" I'm looking to determine simply returns an angle, which, dependant on your overall accuracy score an the random number generator, will go off on some who knows what direction. Whether that angle leads to the target is dependent on the visible target area versus the angles you'll get based on your accuracy stat (this "target area" concept is the purpose of the next section down, mostly unwritten because it's pointless until THIS formula is figured out).

:: That is to say, there's no real formula that can tell you the REAL chance to hit a target without actually inputting all the tile data in addition to using the "angles formula" I'm after here. Luckily, once the angle formula is determined, it shouldn't be too hard to have my battlescape editor calculate the "true" chance of a shot hitting. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)

: I wonder if it's possible that the game's maximum firing angle (e.g. at zero accuracy) is one radian - about 57.3 degrees? This is near your observed limit of 55 degrees. The game engine would probably use trig functions based on radians as I believe they are the most efficient. Given the power of the computers they were programming for, this vector work was pushing the envelope so they would need to be efficient. - [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)
::I would say that yes, given the close proximity (and the inherent inaccuracy of my logger, due to the inability to pick up on the precise ''point'' a bullet hit), one radian is correct.

::The [[COS.DAT]] page will probably be relevant at some point, dunno if you've read that. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Also could you clarify the axes on these 2 graphs/histograms? I'm having a lot of trouble understanding them. Is it possible that the vertical axis should be frequency, and the angle should be on the horizontal axis? Or am I being dumb? If I'm understanding them correctly, we are not seeing a linear distribution of error angles - as you would get from say

ActualAngle=AngleToTarget+(rand(57)-(57/2))

:what we are getting is angles that cluster together near the correct aimpoint, and frequency falls off quickly as you move away from the correct aimpoint.

:: You are reading the charts correctly. The vertical axis shows how often a specific angle was picked to fire along by the game, and the horizontal axis shows the angles themselves. The reason the charts are symetrical is because shots can either go to the left or right of the target (an angle of 0 means it hit). Even with 0 FFA, you're a lot more likely to send a bullet near the target then you are to send one on the maximum diverging angle - hence my statement, "I think it's an exponential equation divided by your rated accuracy". - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

:Guess: The graphs look not unlike a tangent or inverse tangent function. That might suggest that the firing function injects a linear amount of perpendicular drift (horizontal and maybe vertical) onto the bullet's vector. Maybe try graphing the tan() or arctan() of the data from the "zero accuracy" tests, and see if you get a horizontal straight line.

: arctan (0.5), which might be relevant if maximum "perpendicular error" is 1 map square wide per map distance unit, is 26.565 degrees, near to your value of 27.5 degrees. Arctan (0.25), which corresponding to half that "perpendicular error", half a map square wide per map distance unit (and maybe corresponding to 50% FFA????), is 14.036 degrees, again near to your value of 17 degrees for 50% FFA. But only 'near', and higher. Hmm. Your data have a horizontal granularity of 1/16th of a map square distance unit, is that right? So there could be some data slightly outside the true upper limit for angles. It depends on the range to your target in your test setup I guess. [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)

:: This is where my brain starts to melt, mind you, it's 3:15am here so I'm probably not good for any number crunching right now. But I reckon you're onto something even if I can't wrap my brain around what!

:: I put the target about 25 squares back (middle of the map). Really can't remember. Ideally I'd've set him to be a pixel in size, but back then the "using LOFTemps for unit size" thing was just a theory I had, not a proven fact (I never got around to updating this page when it WAS proven, that's how long these notes have been here).

:: Yes, granularity is a 16th of a standard user-visible map tile. On the horizontal plane anyway. Can't remember if I set it to 24ths on the vertical, but I probably did. The problem is, of course, that it can only pick up data according to whether a bullet hit a tile or not (as opposed to data on where the tile was hit), so although the range of angles should be "close to accurate" there's still those nasty steps everywhere which have to be "guesstamated".

:: I never really bothered much with the vertical data as I was mostly "proving the concept", figured I'd get to that later. I know I logged it (I was even able to draw an ellipse to show where all the bullets would fall, your maximum vertical angles are of course no where near your maximum horizontal ones), but I can't find the charts in concern. They weren't that good anyway as the test map had no ceiling.

:: I distinctly remember logging and graphing the 100% FFA data but can't find that either. Probably deleted it from my system (in the misguided belief that I'd uploaded it all here). I cannot find any of my related logs at all, in fact, just a single zip file with the logger, test map and automated script file ready to go. Again, this may be because I've deleted them, or because I have nearly ten thousand files in my UFO directory. My main one, anyway. I have a few such directories. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)

: OK. The curve you graph above for "zero accuracy" looks not unlike what happens if you graph tan(x) (in degrees), where x is from +0.5 to +0.5. But I think that's a coincidence, since your graph is not a standard histogram - you are showing "frequency" by the length of lines on the x axis, rather than by the height of bars along the y axis as in a standard histogram. In order to turn your graph into a standard histogram it would need to be more or less inverted I think.
: The link to the "zero accuracy" data set is broken now. From what you said above, the data is lost now, which is a shame as it would be nice to do a histogram of tan(a) for all the angles "a" in that data set. You might see a flat line, linear distribution. Or not. If the angles are "bunching up" in frequency toward the target centre, then that suggests a ''linear perpendicular'' distribution of angles. With a linear perpendicular distribution (eg varies by +/- 0 to N units, perpendicular to the path to target, per unit of distance), you would expect a "bunched" angular distribution, i.e. if you sorted all the angles in the data set, the separation between one angle and the next widest would steadily increase.
: The Z component is going to complicate things and prevent finding an exact solution. For example, say that the Z (vertical) error/cone and X (lateral) error/cone are not independent of each other. For example, they might be constrained to add up to some constant N that's related to FFA: Z + Y < N. Or in fact, it might be more like (vertical x 4 + horizontal x 1) < N (since we suspect the actual 'bullet group' is an oval, wider than it is high, rather than a circle). A circle is almost the simplest case, but again unless Z and X are totally independent, you're not going to find a close fit for the function without knowing both terms. Hopefully the oval is very 'flat' and so the horizontal-only function will be a good enough approximation of the data to get in the right ballpark. Or even better, maybe the Z component is a totally independent function. Hope so.
: Let me make a prediction or a series of predictions then for maximum angle off-target:
:* 0% FFA = 1.0 perpendicular error per unit distance = +/ 0.500, arctan(0.500) = +/- 26.6 degrees
:* 50% FFA = 0.5 perpendicular error per unit distance = +/ 0.250, arctan(0.250) = +/- 14.0 degrees
:* 75% FFA = .25 perpendicular error per unit distance = +/ 0.125, arctan(0.125) = +/- 7.1 degrees
:* in general, horizontal maximum angle off target = +/- arctan(((100-FFA)/100)/2)
: Well that's most likely wrong but it's good to have a starting point for testing! [[User:Spike|Spike]] 17:40, 15 March 2009 (EDT)

Hey, guess what? First thing on completing a fresh round of tests, I discover all my old logs.

Of course.

Originals (with no roof on the map so the vertical shot data is a bit iffy): [[User_talk:Bomb_Bloke:0acc1|0%]] - [[User_talk:Bomb_Bloke:25acc1|25%]] - [[User_talk:Bomb_Bloke:50acc1|50%]] - [[User_talk:Bomb_Bloke:75acc1|75%]] - [[User_talk:Bomb_Bloke:100acc1|100%]]

New data (with a roof, vertical shot data might actually be worth something): [[User_talk:Bomb_Bloke:0acc2|0%]] - [[User_talk:Bomb_Bloke:25acc2|25%]] - [[User_talk:Bomb_Bloke:50acc2|50%]] - [[User_talk:Bomb_Bloke:75acc2|75%]] - [[User_talk:Bomb_Bloke:100acc2|100%]]

Comma separated data, one shot per line. First three columns are the absolute tile x/y/z co-ords of where the shot ended up hitting (keeping in mind the shooter is at tile 24/49/2). Next three columns are the x/y/z of where the shot landed, relative to where the shooter is. Final two columns are the important ones, they cover the horizontal and vertical angles the shot took, respectively.

Yes, the wiki doesn't represent it very neatly. Use the edit button to get the line breaks back.

Hrm. Looks like the max angle at 75% comes out to 11.53 degrees... Not 7.1. :(

- [[User:Bomb Bloke|Bomb Bloke]] 09:37, 18 March 2009 (EDT)

----

[[image:BBFiringPointTest6.png|thumb|200px]]
Here is a graph that somewhat better displays the results of my initial 0FA results. The blue line represents the recorded numbers (2550 different values). The red line represents an equal number of results generated by the spreadsheet formula "SIN(RAND()*1.5)*28.64788975*IF(RAND()>0.5;-1;1)".

(Which is, effectively, "The sine of a random number between -1.5 and 1.5 multiplied by half a radian").

Unfortunately the two formulas don't line up (even if you mirror 'em on the diagonal), but they're fairly close. Much closer then the exponential equations I tried graphing, at any rate. I'm thinking I might be able to get something better still with TAN, but I don't seem to be having much luck with that...

- [[User:Bomb Bloke|Bomb Bloke]] 02:18, 15 April 2009 (EDT)

: tan eyeballs great if you assume the distribution going in is some flavor of "sum of linear distributions". tan-1(25°)=0.466307658155; halving this and taking the tangent again gets me ~13.1°, which is reached about 1/16th of the way across. I'm assuming some sort of discretization error for the asymmetry. (My initial gut reaction was "sum of two linear distributions", but that isn't correct; that would have landed about 1/8th of the way across. The quick-and-dirty way to fake a bell curve is to sum three linear distributions.) -- [[User:Zaimoni|Zaimoni]] 11:52, 15 April 2009
(CDT)

: Per geometric check; tan works if the incoming angle is from a sum of three linear distributions. That is: tan(K*rand()*rand()*rand()) should recover the graph up to discretization error, for some K. -- [[User:Zaimoni|Zaimoni]] 12:02, 15 April 2009 (CDT)

:: Is there any chance it's some function of (Kx rand(x), Ky rand(y), Kz rand(z)? [[User:Spike|Spike]] 17:53, 15 April 2009 (EDT)

::: It depends on what you mean...

::: I was presuming rand() was a zero-parameter function that needed "massaging" to get to any range other than its default. C rand() would be 0..RAND_MAX. XCOM almost certainly has a wrapper that returns values in a range 0..N. Given when XCOM was written, I don't think it has any sort of floating-point RNG. I wrote K to subsume all of the range-massaging that was needed.

::: That said, a general sum of three linear distributions would have been tan(K1*rand()+K2*rand()+K3*rand()-AVERAGE) [ignoring overflow issues], where AVERAGE is the statistical average expected from K1*rand()+K2*rand()+K3*rand(). The geometric check almost certainly wouldn't pass if the three constants were obviously distinct. The actual expression I'd try retrofitting is tan(K*(rand()+rand()+rand())-AVERAGE). -- [[User:Zaimoni|Zaimoni]] 14:07, 16 April 2009 (CDT)

:::: If rand() was to receive any parameter at all, it'd be a seed; but calling the function three times should result in three different numbers anyway (typically you seed the RNG first). I'd be surprised if even the original game didn't have a floating RNG. Even back on the Spectrums/Commodores/BBCs you could generate within most any range by typing something like RNG*N. I tried graphing TAN(RAND()*1.5) then TAN(1.5*(RAND()+RAND()+RAND())-2.25), though the first formula wasn't right and the second was worse. :( It's a bit too steep (a little like what you get from 1/x but flopped around). Maybe something a bit higher then 1.5 would sort that out, but I dunno how high you can legally go with TAN? - [[User:Bomb Bloke|Bomb Bloke]] 20:36, 16 April 2009 (EDT)

::::: tan goes unbounded at ±π/2 radians i.e. ±90° Given that the initial bounds appear to be ~±25°, I'd calibrate things so that we were looking at a total span of 50° i.e. ~0.872 radians. In radians, with rand() being a uniform distribution 0..1: TAN(0.872*(rand()+rand()+rand())-0.436) would be my guess.

::::: XCOM 1.2 had some source code comments indicating that the C source targeted Watcom C. That means the "easy rand" available is the C standard library rand(), which without processing returns an integer from 0..RAND_MAX, where RAND_MAX may be as low as 32,767. -- [[User:Zaimoni|Zaimoni]] 12:36, 17 April 2009 (CDT)

: 55 degrees horizontal deviation range corresponds to 440 1/8 degree units; quick-but-lousy-RNG C source for the eighths-of-degrees input to the tangent function at accuracy 0 should be <code>(rand()%147+rand()%147+rand()%147)-219</code> . This plausibly is from a "deviation output" function that returns 73 at accuracy 0. Corresponding psuedocode:
<pre>const int tmp = acc_func(...);
const int rng_scale = 2*tmp+1;
const int rng_bias = 3*tmp;

....

(rand()%rng_scale+rand()%rng_scale+rand()%rng_scale)-rng_bias;</pre>

: -- [[User:Zaimoni|Zaimoni]] 13:58, 26 December 2010 (CST)

===Vertical Error vs Horizontal Error===

Hmmm.... I don't know about you guys, but I notice that in my games, when firing from Level 0 at enemies on level 0, my soldiers seem like their vertical deviation tends to be very small, even with high inaccuracy. Their horizontal deviation seems much much larger. Is this my imagination?

- [[User:Jasonred|Jasonred]]

----

You're quite right, they're two different things. There's enough error there to miss at point blank range against a short target, but still nothing like what you get in the horizontal scheme of things.

- [[User:Bomb Bloke|Bomb Bloke]] 08:46, 17 April 2009 (EDT)

== Target Size ==

Units are cylinders, made up of a [[LOFTEMPS.DAT]] layer determined by [[UNITREF.DAT|UnitRef[48]/[52]]], stacked according to their [[Height]].

The full purpose of UnitRef[52] is still in doubt, though it always seems to mirror the value held at [48]. My personal guess is that one is (or at least, was supposed to be) used when bullets come in on one angle, and the other value is used when bullets come in on a perpendicular-ish angle (hence allowing the cylinder to act more like a squished tube, which is closer to the shape of a real person - or it would do if 48/52 didn't always match).

So, yeah, set [48] to 0, all your units get set to an empty LOFTemps record, they cannot be seen/hit by the aliens. Hurrah.

== See Also ==

Pages relevant to this subject:
*[[Firing Accuracy]]
*[[Accuracy formula]]
*[[Firing Accuracy Testing]]
*[[Height]]
*[[LOFTEMPS.DAT]]

Game Files

2010-12-24T13:53:03Z

Zaimoni: There is no geoscape savefile representation for alien base floorplans.

Not-for-profit, just-for-fun reverse engineering.

* General note re: [[HackerTools|Hex editing game files]]
:Contains a quick introduction to using a most unlikely program to edit your game files, and suggestions on other editors out there.
* A primer for the [[Command Prompt]] (aka the command console).
:Information on how to manage directories, files, plus other neat tricks that can be done through the command console that should not be forgotten in today's era of point and click madness.

[http://www.stonepool.com/xcom/hacking/index.html Hatfarm / Chris Voss] and [http://www.daishiva.com/phpBB2/generic.php?page=progLinks.shtml DaiShiva] (see [http://www.daishiva.com/programs/XCFormat.html file formats]) also have notes on a number of XCOM's file formats not yet detailed on this wiki.

= General File Information =
== Program Files ==

These are program files and static data files that are not part of the saved game files.

<table {{StdDescTable}}>
<th {{StdDescTable_Heading}}>File</th><th {{StdDescTable_Heading}}>Description</th>
<tr><td>[[GEODATA]]</td><td>Geoscape data. Includes localization strings, [[OBDATA.DAT]] for objects like weapons, [[WORLD.DAT]] for globe terrain.</td></tr>
<tr><td>[[GEOGRAPH]]</td><td>Graphics for [[UFOpaedia]] and research screen backgrounds.</td></tr>
<tr><td>[[MAPS]]</td><td>Pre-generated Battlescape terrain blocks (.MAP). These are filled in with terrain tiles. A few dozen blocks make up a battlescape.</td></tr>
<tr><td>[[Saved_Game_Files#Missdat_Files|MISSDAT]]</td><td>Holds the data from the previous mission. (Can be [[ExploitsA#Score_Points_For_Free|exploited]]).</td></tr>
<tr><td>[[ROUTES]]</td><td>Alien route maps (.RMP) for moving around the pre-generated Battlescape terrain blocks.</td></tr>
<tr><td>[[SOUND]]</td><td>1990-era sound drivers, or MIDI files for Windows version.</td></tr>
<tr><td>[[TERRAIN]]</td><td>Battlescape graphic tiles for buildings, ships, and terrain (.MCD, .PCK, and .TAB).</td></tr>
<tr><td>UFO2EXE\[[TACTICAL.EXE]]</td><td>The "Battlescape" program in DOS-release of UFO.</td></tr>
<tr><td>UFOEXE\[[GEOSCAPE.EXE]]</td><td>The "Geoscape" program that handles base management and aircraft.</td></tr>
<tr><td>UFOEXE\BLACK.EXE</td><td>The black screen UFO.BAT puts up when swapping between the above two programs.</td></tr>
<tr><td>[[UFOGRAPH]]</td><td>Misc graphics (.PCK) for soldier equipment screens, smoke, motion detector blobs.</td></tr>
<tr><td>[[UFOINTRO]]</td><td>Holds the introduction movie (.FLI) and the endgame pictures (.LBM).</td></tr>
<tr><td>[[UNITS]]</td><td>Battlescape graphics for soldiers, aliens, and the pixelated guns they hold. (.PCK and .TAB).</td></tr></table>

== Geoscape Files ==
These are savegame files used by the [[Geoscape]] portion of the game. This can be considered a 'standard' save.

<table {{StdDescTable}}>
<th {{StdDescTable_Heading}}>File</th><th {{StdDescTable_Heading}}>Description</th>
<tr><td>[[ACTS.DAT]]</td><td>Contains information which acts with which priority in respective zones aliens are going to try.</td></tr>
<tr><td>[[AKNOW.DAT]]</td><td></td></tr>
<tr><td>[[ALIEN.DAT]]</td><td>Contains Alien activity in Countries and areas, for graphs.</td></tr>
<tr><td>[[ASTORE.DAT]]</td><td>Has the info on aliens in [[Alien Containment]].</td></tr>
<tr><td>[[BASE.DAT]]</td><td>Has all of the [[X-COM Bases|base]] layout and contents information, radar scanning abilities and other base information.</td></tr>
<tr><td>[[BPROD.DAT]]</td><td>List of [[Equipment (EU)|equipment]] being [[manufacturing|produced]].</td></tr>
<tr><td>[[CRAFT.DAT]]</td><td>Has all the [[craft]] info, [[Craft Weapons|weapons]], fuel, damage and items onboard. Also stores UFO information, although information is handled differently from friendly aircraft.</td></tr>
<tr><td>[[DIPLOM.DAT]]</td><td>Diplomacy info, and current and historical [[Country Funding]].</td></tr>
<tr><td>[[DUM.BIN]]</td><td>Dummy file for keeping directory structure. Not used.</td></tr>
<tr><td>[[FACIL.DAT]]</td><td>Info on [[Base Facilities]] you can build.</td></tr>
<tr><td>[[IGLOB.DAT]]</td><td>Date and time.</td></tr>
<tr><td>[[INTER.DAT]]</td><td>Info on interception windows</td></tr>
<tr><td>[[LEASE.DAT]]</td><td></td></tr>
<tr><td>[[LIGLOB.DAT]]</td><td>Money! Also financial graph information.</td></tr>
<tr><td>[[LOC.DAT]]</td><td>Location of bases on the planet as well as other things like ships, waypoints and missions. Basically anything that is an icon on the Geoscape world view.</td></tr>
<tr><td>[[MISSIONS.DAT]]</td><td>Contains counters and race info on the ongoing alien acts.</td></tr>
<tr><td>[[PRODUCT.DAT]]</td><td>Info on things you can produce.</td></tr>
<tr><td>[[PROJECT.DAT]]</td><td>These are things you are [[research]]ing.</td></tr>
<tr><td>[[PURCHASE.DAT]]</td><td>Info on stuff you can buy.</td></tr>
<tr><td>[[RESEARCH.DAT]]</td><td>Completed research.</td></tr>
<tr><td>[[SAVEINFO.DAT]]</td><td>Name of the saved game.</td></tr>
<tr><td>[[SITE.DAT]]</td><td>List of recent Terror Sites. (May be TFTD-only.)</td></tr>
<tr><td>[[SOLDIER.DAT]]</td><td>Data about the [[soldiers]].</td></tr>
<tr><td>[[TRANSFER.DAT]]</td><td>Personnel and equipment being transferred.</td></tr>
<tr><td>[[UIGLOB.DAT]]</td><td>Holds the next numbers for [[UFOs]], Terror Sites, [[Interceptor]]s, etc. Also contains monthly scores for research.</td></tr>
<tr><td>[[UP.DAT]]</td><td>[[UFOpaedia]] info.</td></tr>
<tr><td>[[XBASES.DAT]]</td><td>Schedules [[Base Defense|attacks on X-COM bases]].</td></tr>
<tr><td>[[XCOM.DAT]]</td><td>Contains X-Com activity in Countries and areas, for graphs.</td></tr>
<tr><td>[[ZONAL.DAT]]</td><td>Information on which zones and with what priority aliens are going to attack.</td></tr></table>

(28 files. Note that if you find a geoscape save with additional files, this simply means a battlescape save was made in that slot at some prior point. UFO does not remove unused save files).

== Battlescape Files ==
These are savegame files created and used by the tactical portion of the game. They are only created if the game is saved while in the battlescape. [[Battlescape]] saves also contain all the files used in a standard save.

<table {{StdDescTable}}>
<th {{StdDescTable_Heading}}>File</th><th {{StdDescTable_Heading}}>Description</th>
<tr><td>[[BGLOB.DAT]]</td><td>Describes ambient light on map.</td></tr>
<tr><td>[[GEODATA.DAT]]</td><td>Details the map type and overall map structure.</td></tr>
<tr><td>[[MAP.DAT]]</td><td>Stores tile information for the whole map. Basically all static structures, such as trees, walls, floors and furniture.</td></tr>
<tr><td>[[MISDATA.DAT]]</td><td>Contains information on craft in use and which alien artefacts are available for use in combat.</td></tr>
<tr><td>[[OBPOS.DAT]]</td><td>Stores all the objects that your soldiers can pick up (guns, corpses, etc).</td></tr>
<tr><td>[[ROUTES.DAT]]</td><td>Stores nodes for soldier and alien spawn points, also acts as waypoints for AI pathfinding.</td></tr>
<tr><td>[[SEEMAP.DAT]]</td><td>Fog of war overlay.</td></tr>
<tr><td>[[SMOKBIT.DAT]]</td><td>Smoke particles and fire patches on the map.</td></tr>
<tr><td>[[SMOKREF.DAT]]</td><td>Smoke particles and fire patches on the map.</td></tr>
<tr><td>[[SOURCEMP.DAT]]</td><td>Light source overlays for mobile light sources (i.e. your soldiers).</td></tr>
<tr><td>[[TERMP.DAT]]</td><td>Light source overlays for ambient (or fixed) lighting.</td></tr>
<tr><td>[[UNITPOS.DAT]]</td><td>Controls ownership, visibility, whether the unit is under temporary mind control, etc. Works hand in hand with [[UNITREF.DAT]].</td></tr>
<tr><td>[[UNITREF.DAT]]</td><td>Contains the primary stats for all units in combat. X-Com owned soldiers in this file are ''virtual'' copies of the soldiers in soldier.dat. Works very closely with unitpos.dat.</td></tr>
<tr><td>[[WGLOB.DAT]]</td><td>Battlescape map global information such as map dimensions and the number of turns that have elapsed.</td></tr></table>

(14 unique files, plus all 28 standard save files, totaling 42).

== Missdat Files ==
These temporary files are used at run time, when a battlescape game is in progress. The missdat folder also contains all the files needed to create a standard Geoscape save for the game in progress.

When the tactical game engine starts, it first checks [[SAVEINFO.DAT]] to see if this is a new battle, or if you're loading a battlescape save game. In the case of the former, it generates a new map, based off these files:
*[[GEODATA.DAT]]
*[[MISSION.DAT]]
*[[OBPOSREF.DAT]]
*[[UNIPOS.DAT]]
*[[UNIREF.DAT]]

If you load a game, the tactical engine loads from the save slot directly, as according to [[DIRECT.DAT]] (which details the path to the slot in concern).

When combat ends, these files are created:
*[[CODE.DAT]]
*[[MISSION2.DAT]]
*[[OBPOS2.DAT]]
*[[OPTION.DAT]]
*[[UNIREF2.DAT]]
*[[UNITPOS.DAT_(MISSDAT)|UNITPOS.DAT]]

(12 unique files, plus 27 standard save files (does not use dum.bin), totaling 39).
-----

=File Format information=

==Graphics==

A list of specific image formats used by EU/TFTD.

<table {{StdDescTable}}>
<th {{StdDescTable_Heading}}>Extension</th><th
{{StdDescTable_Heading}}>Description</th>
<tr><td>[[Image Formats#PCK|PCK]]</td><td>A run-length-encoded image format for storing one or more images with a dimension of 32x40 pixels. Used for sprites, tiles and inventory images. Usually accompanied by a TAB file, serving as an index to the image archive.</td></tr>
<tr><td>[[Image Formats#SCR & DAT|SCR & DAT]]</td><td>Stores uncompressed image data for the full screen backgrounds and the inventory screen icons.</td></tr>
<tr><td>[[Image Formats#SPK|SPK]]</td><td>Paper doll and UFOpedia images, among other full screen pictures.</td></tr>
<tr><td>[[Image Formats#BDY|BDY]]</td><td>Often used by TFTD in place of SPK.</td></tr>
</table>

=Did You Know?=
* If your game crashes and you are returned to previous mission, the game is actually referring to the battlescape information in the MISSDAT directory. Also, if a tactical mission is abnormally aborted, the results are obtained from the MISSDAT folder as well. Because the game was not able to update the files that hold the results of the last mission, your current game will be updated with information from the ''previous'' mission that was able to end normally. Abnormal program termination simply means that the tactical game engine crashed or was forced to crash by the user. This [[ExploitsA#Score_Points_For_Free|can be abused]].

* Other exploits with gamefiles can be found [[ExploitsF|here]].

=See Also=

[[Game editors]]

[[Category:Game Files]]

Talk:Alien Base

2010-12-24T13:48:49Z

Zaimoni:

== Base Camp(er) ==
----

After getting my ass handed to me a few times by a blaster bomb during alien base assaults, I decided to experiment with new tactics. I tried having everyone stay in the "green rooms", and sent a scout down every turn who spun around and came back up if he didn't see anything. I also dumped a smoke grenade below for a little extra cover.

If the scout saw any alien, I had everyone go down the lift to take a single autoshot each until the alien(s) were dead. I used a Mind Probe to figure out if the aliens had TUs left, and to use stun ammo if I spotted a Commander.

It worked really well. Those lifts are a regular duck blind. Twice they sent a blaster bomb my way; one circled around in the room below me before exploding, the other blew up in adjacent room. The first one might have missed due to the vertical-movement waypoint bug, although if that was the case, I think it would have just blown up, not gone through several waypoints like that. It may simply be that they were aiming for where they had seen my troops on the lower level, having never spotted the team on the upper level.

Right towards the end the Commander finally came at me. He had panicked so he wasn't carrying his weapon, but I wanted to capture him and none of the soldiers near him had stun weapons. I had my troops turn their back to him so they wouldn't kill him with reaction fire and had the other team make their way across the map. However, it turns out the Commander still had an alien grenade. He came up the lift, tossed it, and killed two of my soldiers as well as himself. Heh.--[[User:Ethereal Cereal|Ethereal Cereal]] 01:20, 9 March 2007 (PST)

I tried it a second time, it continued to work well. I should note that it was a Snakeman base on Superhuman. With other races, and maybe other difficulty settings, this technique might not work too well.--[[User:Ethereal Cereal|Ethereal Cereal]] 04:07, 9 March 2007 (PST)

: I actually do this all the time. I wait at the entrance, plugging the upper landings with soldiers or a tank to prevent sneak attacks and let the aliens approach the lifts. Ever turn I lower a scout down, look around and when anyone's spotted, I have other soldiers drop down, open fire or perhaps drop or throw a grenade and then flee back upstairs. If I'm daring enough, I attempt an angled blaster bomb attack (with everyone fleeing to the far end of the room - even this doesn't protect them 100% of the time). I keep this up for a while until I feel it's safe to venture out. The CE vertical blaster bomb bug also helps heaps with mass self-inflicted kills. I wouldn't count on it for the dos version.

:However, it's not a foolproof strategy and a spanner can easily be thrown into the works if the aliens get just one lucky break.

:A mini-camper strategy involves having soldiers hide up those small lifts that lead to small isolated areas. In the CE version of the game, this ensures that you're 100% blaster-bomb and chryssalid/reaper proof. Of course, you'll need a grenade or some other explosive to clear the landing if the aliens get smart(or dumb-depending on your viewpoint) and plug the lift so that you cannot descend. - [[User:NKF|NKF]]

----
And it works for all types of lifts. From 1x1 to 3x3, as long as you plug it the aliens can't send a Blaster Bomb up there. Only true for the CE version though. The Playstation version doesn't have BB waypoint problems and thus it forces you to play without exploiting a bug.--[[User:Zombie|Zombie]] 08:53, 9 March 2007 (PST)

:If you stay out of sight though (using smoke and avoiding "visible" edges of the lift), can they see you up there? Will they attempt to send a bomb up if they've only seen troops on the lower level? (If not, then this is potentially an AI exploit, which is more legit than a bug exploit.)

:Incidentally, do you really want to "plug" the lifts (I assume by putting a soldier/tank on every upper lift square)? I tried it where everyone was adjacent to the lift, staying away from positions that might be visible from lower-level corridors. If any alien made a mad dash for the lift, they'd be so out of TUs that reaction fire would take care of them. But again, so far I've only tried it with snakes/chryssalids, and only on CE.--[[User:Ethereal Cereal|Ethereal Cereal]] 15:50, 9 March 2007 (PST)

:Okay, I tested it on a Muton base this time. It works (occasionally you'll get shot at while coming down the lift), but I saw several blaster bombs lobbed at me and they all made a beeline for the lift, then went straight south. So that's the CE vertical movement bug all right. It doesn't look like you need to "plug" the lifts, though.--[[User:Ethereal Cereal|Ethereal Cereal]] 17:25, 10 March 2007 (PST)

== Base lighting? ==

The article states "Alien bases start dim and remain dim, so bring electroflares." They certainly ''appear'' dark in certain parts, but it seems to me I routinely see aliens more distant than 9 squares away, even when they're not near a source of illumination and appear quite dark. This ought to be tested. Even if it is true, the short corridors and multiple sources of illumination make bad lighting a fairly limited hazard in alien bases.--[[User:Ethereal Cereal|Ethereal Cereal]] 00:46, 14 March 2007 (PDT)
----
These are the items which produce light in an alien base:
[[Image:Container1.png]][[Image:Container2.png]][[Image:Container3.png]][[Image:Container4.png]][[Image:Eye.png]][[Image:Plasma_Conduit1.png]][[Image:Plasma_Conduit2.png]]
All of these items produce 10 for light except for the "bloodshot eyeball on a stem" which pumps out 12. BTW, the 4th container isn't used in the game. And with the containers, only the SE corner pumps out light - the other quarters are unlit.

Basically, the modules which have light are UBASE_00 (command center), UBASE_02 (storage room with tower) and UBASE_03 (maintenance/storage facility). The other modules do not have a light source. In the alien base on Cydonia, the modules which have light are UBASE_12 (power source with 4 plasma conduits along the outside), UBASE_13 (4 plasma conduits in the middle with 4 small storage containers on the outside) and UBASE_15 (the brain room). --[[User:Zombie|Zombie]] 09:48, 14 March 2007 (PDT)
----
Just for completeness' sake, you left out UBASE_10 and UBASE_11 (plasma conduits & alien entertainment rooms). It took a fair amount of testing until I was able to find a situation where I knew where an alien was but couldn't see it due to darkness. (Would've been easier if I had just used MC.) "Personal" lighting produced a few false results. But I was finally able to confirm alien bases are "dark" maps, lighting sources not withstanding.

However, these tests just confirmed to me that it's pretty rare that an alien goes unspotted due to darkness. There's too much cover for long-distance sighting to be common, lighting or no. Electroflares aren't great for bases either, since you're limited to about 12 squares throwing distance with the low ceiling overhead. AC-IN works okay but at that point I'd rather "illuminate" a room with a rocket or Blaster Bomb.--[[User:Ethereal Cereal|Ethereal Cereal]] 20:22, 14 March 2007 (PDT)
----
Right, forgot about UBASE_10. But the UBASE_11 alien entertainment module is not illuminated. The walls tiles certainly aren't lit and neither are the floor tiles.

I have a suspicion that if I edit all the modules in an alien base not to throw out light that the base would be as dark as a night time mission. In this case, Electroflares would be somewhat helpful if you could throw them far enough. A problem with incendiary is that the fire will only stick around for 3 turns max in an alien base for most items. The vats mostly remain lit longer than this (4-7 turns depending on type) but those locations do not need any extra lighting since the items around them throw off so much light. I guess incendiary is helpful in those garden areas as anything which isn't green stays lit by fire for quite a while. But a Blaster can fix any type of illumination problem you may be having in an alien base. Carpet bomb the garden area to flush the aliens out and use saturation bombing on the command center to make sure nothing is moving and the command tables are destroyed in case you need to dust off in a hurry. ;)--[[User:Zombie|Zombie]] 21:15, 14 March 2007 (PDT)

== Base Camper ==

One of the reasons I love this game after playing it for ten years is that it still can surprise me.

I tried out the Base Camper tactic last night on a Snakeman base. It work great on the first base in Siberia so I thought I'd take a bunch of rookies for some training on another Snakeman base in the artic. After killing two soldiers they stopped coming. I sent a guy down and he got blasted by a Snakeman hiding in a hall. I waited several more turns but the snakeman didn't come out. I sent another guy down and he managed to survive a direct hit. He then finished off the sniper.

I figured that now the aliens would head for the lift but no one showed for 20 turns! I moved my guys around figuring the movement would make them react. Nothing! I sent a guy down. Looking around a corner he spotted a crysalid down a dark hall. Several times I popped down then back up but the bug just stared at me. So I had a rookie shoot it. Behind the crysalid was a medic and he stunned my rookie on a reaction shot. Luckily he knocked himself out as well. I pulled the rookie back up the lift and revived him.

Then I waited and waited turn after turn but still no one came. THEY WERE LEARNING! I got goosebumps! It did not seem like a game anymore but as if I was really there. They knew what I was doing and were ambushing me instead. I have never seen this in any other game before. But I have seen it in X-Com time after time. Just when I think I know the game it scares the #@$% out of me.

So I sent down a good squadie and he saw a similar ambush; a crysalid hiding in a long dark hall next to the lift. He shot on autofire and nailed the bug on the first shot. But to my horror behind him was a bunch of aliens waiting to shoot. The second autofire burst killed another bug and the third killed a Snakeman. Three with one autofire! I never saw that in ten years of play. I quickly got him up the lift where the squad was cheering at his shot.

And then I pushed the next turn button. All the Snakemen in the base panicked! The three for one shot broke their moral. Finally they crowded around the lift and my guys had a turkey shoot. Unfortunately the base commander came to his senses before I could stun the leaders and drag them up the lift. He fired a blaster shot that killed them all and wiped out the equipment.

I am half afraid to try the base camper tactic again. Who knows what new strategy they will try next. And I definately will not take rookies next time.

== Validity of Page ==

I was reading through the article page today and noticed a lot of issues concerning validity. This is probably due to lack of knowledge/experience or just plain carelessness.

Issue #1: Just because Mutons do not have Leaders or Commanders, it doesn't mean that the base will not have aliens carrying Blasters. See, Mutons substitute soldiers for the missing ranks and those soldiers are equipped as if they are the original rank. Commanders (or the substitute rank) do not carry Blasters in an alien base mission either. They only carry a Heavy Plasma, 2HP clips and an Alien Grenade.

Issue #2: Not really an issue I guess, but an addendum. Aliens do not carry Blaster Launchers in base missions in the early-mid part of the game. Ever. Later on, yes, then they start to show up. So what this means is that you can be a little more aggressive on base missions early on since you don't have to worry about one of those silver footballs flying out of the blue and ruining your day.

Issue #3: According to recent research into the game files, an alien base is equally as dark as a night time mission. And besides those objects/rooms I mentioned in the talk page which shed light, the base is basically bathed in darkness. You really don't need Electro-flares or fire to light a base since most rooms are small and offer some level of concealment, but they are helpful down long corridors leading to the command center.

Issue #4: On Superhuman, Commanders rarely spawn in the command center. Reason? There are 4 spawn points upstairs which are reserved for Leaders and/or Commanders, but on Superhuman, 4 Leaders are slated to spawn. Since Leaders spawn before Commanders do (it goes according to the pecking order in the alien loadouts section of the executable) they will usually occupy all those slots (it's not guaranteed, but there is a very high probability). Since there isn't a reserved slot for the commander anymore, it gets placed anywhere it is allowed. This makes it important to have Mind Probes along to identify (and capture) rogue commanders wandering around the base.

Issue #5: Building on #2, leaders always carry Blasters later in the game, so on Superhuman skill level it's fairly safe to storm the upstairs part of the command center with nothing more than a group of guys wearing T-shirts carrying Stun Rods. Due to self-preservation, the leaders will refrain from firing on your men since they are going to be caught within the explosion. The Small Launcher works fine too, but you may have to back up a bit or fire from below to prevent from being caught in the splash.

Issue #6: If the UBASE_03 module is present (that's the one with the Power Sources), alien engineers are guaranteed to be upstairs as there are 4 slots reserved just for them. With a maximum of 2 engineers slated to show up (usually it's only one on the lower difficulty levels) and with 4 slots available... you do the math.

That's all I have time for at the moment, but I thought I'd better toss some of these issues down before I forget. --[[User:Zombie|Zombie]] 22:12, 25 November 2008 (CST)

: You can't go in with stun rods because reaction-fired blaster bombs seem to ignore self-preservation. Getting them to reaction fire is my primary base-destroying technique. --[[User:(name here)|(name here)]] 05:56, 26 November 2008 (CST)

I tried to get aliens to reaction fire the Blaster Launcher a long time ago with no luck. Today I revisited it again. Dropped reactions of my soldiers to 0 and ran a soldier in front of a Sectoid Leader with full TU until my soldier ran out of TU himself. Nothing. Might be a version specific issue (I'm using the CE version). --[[User:Zombie|Zombie]] 07:34, 26 November 2008 (CST)

: Maybe, I generally use DOS. Try it with multiple commanders, and try it with shooting. --[[User:(name here)|(name here)]] 12:22, 26 November 2008 (CST)

== Alienly Inconsistent Floor Plans ==

(Testing with CE/UFOExtender)

I tried start-scumming to force a UBASE_03 module. This was eminently successful. More interesting is that the alien base layout is randomized even on repeat visits.

That is, there doesn't appear to be a Geoscape savefile representation for alien bases.

--[[User:Zaimoni|Zaimoni]] 07:48, 24 December 2010 (CST)

User talk:Zaimoni

2010-11-24T04:11:49Z

Zaimoni:

"Welcome to Base Aleph-NULL in Nigeria. We managed to get the Prince of Darkness off of the base planning committee, so Aleph-NULL is a real base. Base Continuum near Tokyo has just started construction.

And ETA for the first pair of UFOs is 14:30 sharp."

<hr width="80%" align="center">

The redeeming feature of putting the first base in Nigeria is...it's nearly antipodal to Hawaii. Very good scummy Interceptor coverage for a single base. [Holes: Half of Australia, the entire Pacific Ocean, parts of Siberia and North America.] The second base completes scummy Interceptor coverage for all land masses of interest.

It's not like there shouldn't be an automatic alarm that goes off when UFO reports start coming in.

[[User:Zaimoni|Zaimoni]] -- 9:11AM, 18 July 2006 (CDT)

[[Exercising The AI]]

[[UFO Flight Patterns]]

[[Encumbrance (Apocalypse)]]

[[Sketching Executing Aliens Efficiently]]

[[Image:Zaimoni Strength vs. Throwing Distance.zip]]

[[Known Bugs (Apocalypse)]]

[[Zaimoni's Apocalypse Checklists]]

[[TU Threshold tables (Apocalypse)]]

[[Zaimoni's XCOM1 Editor]]

<hr width="80%" align="center">

=== Things to remember to do at some point (when work schedule not haywire) ===
* probability of MC plane graph (not sure whether to do this manually, or write C++ programs to automate)
* suite of Python game editing scripts; basically, cover holes in ClarkWehyr and XcomUtil editors. Curses module doesn't exist in Windows port; looks like it targets ncurses, which has not been ported to either Windows or DOS.
** Base layout: automatically handle radar detection from radars
** Battlescape saves: help out the AI (turn 1 alien facing, ROUTES.DAT fixups), probably will have to integrate with XcomUtil. Need to research LOS more carefully first.
** Advanced two-player hotseat (individual visibility support, allow aliens to fire alien weapons, working explosives).

[[User:Zaimoni|Zaimoni]] -- 6:29PM, 19 Sept 2006 (CDT)

=== Some working notes on advanced swap ===
* XcomUtil's default visibility hack is workable for the alien side (they're there first). Backup and restore [[SEEMAP.DAT]] to handle human visibility. [Done]
* Need two backups for [[MISDATA.DAT]]: human and alien. Alien has all alien tech enabled. [Done.]
* [[WGLOB.DAT]] probably can be automatically fixed when going from alien turn to human turn (backup when alien turn starts, then parse for changes and invert). [Done]
** May want to do something about turn counters.
* Autoclosing doors can be dealt with (it appears that whatever closes them in-game is silent). While it would be nice to parse the MCD files, a lookup table of indices by terrain type will work. [Done.]
* [[UNITREF.DAT]] experience counters cannot be automatically fixed for XCOM (they are not incremented in alien turn mode). Theoretically, they should be patched for alien units "just in case" (We have other reasons for backing up UNITREF.DAT).
* One of the StrategyCore posts mentioned that hacking a Stun Rod into a Chryssalid enabled the native melee attack. Need to check whether this gives the native attack speed (14 TU?)...if so, can automate this directly (leaving only grenades to deal with).
* Grenades, Alien Grenades, and melee aliens can be enabled as follows (to automate, need an environment that can inject mouse events into XCOM)
** "anchor" the shooting aliens using various current/recovery energy hack
** end the turn, then quit.
** backpatch energy/TU/facing-related values into non-melee aliens
** or we could just do the lazy thing and directly emulate the exploding grenade.
* If replacing XcomUtil's SWP function outright:
** be sure not to repair damaged armor.
** Fatal wounds can be handled properly ("wraith" problem is from not updating the [[UNITPOS.DAT]] entry). Remember to force the health of dead units to 0 to prevent the resurrection bug post-battle.

Note that my local copy of XcomUtil is patched to use <code>COPY /Y ...</code> rather than <code>COPY ...</code>; this prevents waiting for an interactive prompt in a batchfile. [Default behavior doesn't work right in Win2000.] I got this from some thread in the xcomufo forums.

The simpler parts will be implemented in Python.

[[User:Zaimoni|Zaimoni]] -- 11:50PM, 16 April 2007 (CDT)

=== Testing plans: Doomed to Decline Prices in Apocalypse ===
...because they don't go up even when completely bought out. Results go into the corresponding XCOMUFO thread, I just don't want to forget what I'm doing.

I got suspicious while experimenting with Sunday Inventory Management. Nothing with a base price of 30 or less went up when I bought them out...a 0% rate of return on the fiat money I parked in them. The following didn't go up
* vehicle autocannon ammunition (stayed at 5)
* Lawpistol clips (stayed at 10)
* M4000 ammunication (stayed at 20)
* AP autocannon clips (stayed at 30)

Note that more expensive items (e.g., autocannon explosive clips) did twang upwards.

[[User:Zaimoni|Zaimoni]] -- 14:58, 27 Jul 2007 (CDT)

Finally completed week 2. Vehicle autocannon ammunition and Lawpistol clips will be tested next; both prices did go down as expected, by 1.
* Ahem...need to be more careful; lawpistol clips were not testable after all. Worse, I had an attack of perfectionism: it turns out that firing biochemists also fires soldiers.... Restart game, and contemplate command-line utility.

[[User:Zaimoni|Zaimoni]] -- 10:13, 05 Aug 2007 (CDT)

Bungled a real-time game strategically (may restart), but did get in some testing.
* Buying out an item that costs 30, does not cause a price increase. Doing the same for 40, does. Results were consistent for more extreme prices (in both directions). [Ended up doing a doctrine change, so restart. Two LAW pistols as backup for a personal autocannon works very nicely in RT. Too bad there's very little ammunition for LAW pistols.]
* I was able to make smoke grenades go down from 30 to 29 by selling all of them. Likewise, 2100+ vehicle autocannon rounds appears to be a reliable way to drop the price from 5 to 4. Now, if these are truly irrecoverable....

[[User:Zaimoni|Zaimoni]] -- 19:51, 14 Sep 2007 (CDT)

=== Tactical notes, Apocalypse ===
* I use framestepping at 50% speed in hairy situations for real-time. This makes it possible to actually run from primed grenades, and occasionally dodge rockets and long-range fire.
* 10 biochemists...run out of projects near the end of week 2, temporarily. (Stalled by needing an advanced biochemistry lab, really should consider a new base the instant an advanced biochemistry lab is constructable).
* Jumping into empty space costs 0 TUs for non-flying units. Real-time is not so user-friendly. On the other hand, picking up objects appears to be free in real-time (but picking up live grenades doesn't stop them from detonating).
* It is unclear whether the martial art of dodging incorrectly aimed large rockets is a skill, or supernatural. On the other hand, kneeling may be a somewhat reliable way of assuring that it takes two large rockets to die rather than one.
* Real-time visibility updates appear to be closely related to full-second updates. Units with low reactions take more frames to see the same alien.
* Turn-based TU calculation for shots: aimed is per reference. INT(aimed/2) to get snap shot TUs. INT(aimed/4) to get autofire TUs. Yes, this means an aimed shot of 7TUs will grant an autoshot of 1 TU. An important special case for the M-4000, moderately useful for the LAW pistol.
* Early-game note: hovercars are much easier to hit than hoverbikes. Get over the ego trip and put the small Rendors on hoverbikes, at least until vehicle shields are researched.
* Stun raids do not trigger promotions, even if soldiers involved would otherwise qualify.
* Tired of dwarf maps when raiding the Cult of Sirius? There's a breakpoint at 20 X-COM Agents. 19 Agents or less gets you a 2x2 map just like 12 Agents, 20 Agents gets you a 3x2 map. This makes a disproportionate difference in how many [[Psiclone|Psiclones]] can be recovered. (Lower bound not verified, possibility of yet larger maps not verified.)
::This seems to be the case with traditional semi-random maps like the cult temples or maybe the Recyclotorium. Fixed maps, which are frequent in this game, aren't affected. But to make things interesting, later in the game there may even be a massive alien drop that will generate a two fixed map mission (aka two slum maps or fixed apartment maps side by side for example). Alien population could be a factor. -[[User:NKF|NKF]] 22:39, 13 January 2009 (CST)
::: Actually, total population is a factor. I probably should do a proper save-scum screening; I just ran across a case where 20 Agents + 9 CoS resulted in a 2x2 map, so it seems that the threshold is actually 30. Also, the map randomization varies by at least one of corporation or building type (stun-raiding Marsec's Arms One starts at 1x3, not 2x2). -- [[User:Zaimoni|Zaimoni]] 10:52, 17 Jan 2009 (CST)
* Turn-based abuse: wall-running. Not all diagonal jumps that start can be completed; those that don't end up being a free move. SE/SW jumps thoroughly obstructed by a north wall end up being E/W moves. NE/SE jumps thoroughly obstructed by a W wall end up being N/S moves. Note that the reverse (NE/NW and north wall, NW/SW and west wall) are not obstructed at all.
* Testing in hotseat mode suggests brainsuckers have problems with "unusual relative heights" in turn-based mode. (They have no need for attack controls; if they have at least 18MP and are no more than L1/Manhattan distance 1 they will athletically jump onto humans and hybrids. They do not jump onto androids.) In particular, launching from a 45° grade from below onto an agent kneeling on level ground is harmless to the agent. Not only that, the brainsucker will jump repeatedly until it has less than 18 MP.
* Some early-game kits
** base: Megapol armor, medikit, 2 frag grenades, 2 stun grenades. Deduct up to two grenades to reach a speed breakpoint. Note that real-time speeds are a multiple of 8 (they index how many 80ths of a square are covered when running in one frame); you'll look a bit faster in real-time than in turn-based. Haven't made up my mind what to use Marsec armor for.
** Rifleman: Marsec machine gun. Two spare clips.
** Disruptorman: light disruptor rather than machine gun.
** Autocannon: need STR 50 to qualify. Start with one AP clip loaded, 1 spare AP clip, and 1 explosive clip. The RT version ideally is equipped with two identical pistols and 2 spare clips for those pistols. Start with LAW pistols, upgrade to plasma pistols when available.
** LAWgunner: Real-time kit. A rifleman that both cannot be faster by losing grenades from his kit, and is not slowed by two LAW pistols with eight spare clips. The fastest average rate-of-fire kit in the early game. The analogous kit with plasma pistols would have four spare clips.

[[User:Zaimoni|Zaimoni]] -- 22:06, 13 Jan 2009 (CDT)

== Medium Scout Ambushing ==

[[Image:MediumScout.gif]]

So, the thought of directly covering the exit of a medium scout doesn't sound too good, for whatever reason. How about piling up on the side walls and getting some reaction shots that way?

Say...

<pre> _____
XX / \XX
RX | |XR
x | |R
| |
\_____/
o</pre>Oh, wait...those obnoxious fake walls are causing problems. x cannot fire on the alien at o, but o not only can fire at the agent at x but actually prefers x to the agent at R that can return fire.

Zaimoni's XCOM1 Editor

2010-11-24T03:42:20Z

Zaimoni:

[[Image:ZaiXcomSuite.0.1.zip|ZaiXcomSuite.0.1.zip]]

This set of DOS batch files and Python 2.5.x scripts is a command-line savegame editor and turn-swapping utility. You will also need the (http://www.python.org/) Python scripting language installed. Unzip into c:\mps\ufo (will need editing if the XCOM1 install is elsewhere)

The Python scripts may work with later versions of Python (tested with 2.5.0, 2.5.1, 2.5.2, 2.6.0). They will not work with Python 2.4.x due to incompatible changes in the struct module, and presumably will not work with earlier versions either.

Usage:
* Soldier.py : Soldier and battlescape editor. Intended to run from the savegame directory being edited: <code>..\Soldier.py ....</code>
* Base.py : Base editor. Intended to run from the savegame directory being edited: <code>..\Base.py ....</code>
* Transfer.py : Transfer editor. Intended to run from the savegame directory being edited: <code>..\Transfer.py ....</code>
* PrepareSWP.py : Prepares a battlescape savegame for turnswapping. Run from the savegame directory to be enabled: <code>..\PrepareSWP.py</code>
* Alienturn.bat : Swaps a game from the human player to the alien player. Run from the main directory, e.g. <code>Alienturn.bat game_8</code>
* Humanturn.bat : Swaps a game from the alien player to the human player. Run from the main directory, e.g. <code>Humanturn.bat game_8</code>

AutoClose.py may also be useful for repairing savefiles with UFO doors stuck open. Run from the savegame directory to be fixed: <code>..\AutoClose.py</code>
<hr>
<tt>Base.py</tt>

<code>Supported subcommands for Base.py
unbuild_dirt:
sets days-to-completion for dirt to 255/-1 (never) at all bases. This bypasses a bug.
fast_construction:
forces all in-construction facilities to complete at next midnight. Cheat.
overview Name:
lists all items in inventory at base Name.</code>

<tt>Soldier.py</tt>

<code>Supported subcommands for Soldier.py
list
lists soldier names in internal order.
sort:
sorts soldiers according to the function SOLDIERS_CMP.
Soldiers in transit will be left in place to prevent eliciting gross bugs.
rename OldName NewName:
renames soldier from oldname to newname. NewName will be truncated to fit, if
needed.
swap Name1 Name2:
swaps the soldiers named Name1 and Name2.
max_recruit Name:
sets recruit stats for Name to maximum. Cheat.
inactive Name:
reduces mission count and score for Name by 1. Cheat.
battlescape
military intelligence overview...vaguely like XCOMUtil DIS:2
facing [unitref index] [facing]
changes facing of target index
transpose [unitref index] [unitref index]
transposes two units on the battlescape. Unreliable in the presence of
large units.</code>
<hr>The shipped sort order is moderately useful if you want psi-weakings to soak reaction fire.

<tt>Transfer.py</tt>

<code>Supported subcommands for Transfer.py

fast_shipment:
forces all in-progress transfers to arrive at the next hour transition. Cheat.</code>

==See Also==
[[User_talk:Zaimoni]]

File:ZaiXcomSuite.0.1.zip

2010-11-24T03:34:46Z

Zaimoni: uploaded a new version of "File:ZaiXcomSuite.0.1.zip": various augmentations

Python-based XCOM1 savefile editor

Alien movement patterns

2010-11-22T06:10:37Z

Zaimoni:

Closely linked to [[Spawn Points]] are the alien movement patterns (aka routes). Although the maps are randomly generated, each module (especially ones with doorways) have patrol points defined. Aliens on patrol will follow a route through these points until they spot the enemy (you). Then the [[aggression formula]] takes over.

== Guards ==

There's a safe method to dealing with almost every UFO. Due to odd positioning, some ship have alien 'guards' that do not move from their spot until you 'trigger' them somehow, either by walking through a door or standing at certain locations in the UFO. In general, they'll head in the general direction of the nearest soldier to them.

''[ [[User:Hobbes|Hobbes]]: This is debatable - When the AI is moving an alien it can happen that the next waypoint is already occupied by another alien unit and thus it will freeze on its location without moving. In those cases what will happen is that the alien will wait until the path is clear before moving.'']

For example: The [[Large Scout]] occasionally has one nasty one, depending on the exact location where the alien spawns in the bridge. When approaching the bridge, head to the left passage (your soldier's relative left), rather than the more obvious one to the right (relative o the screen, this is the upper passage)- where you often get killed instantly the moment you step through that door.

Wait at the corner just before the left door and the alien will start moving towards you. By the next turn it should be in the room just beyond -- exhausted and unable to fight back.

Other UFOs may require bigger weaponry to deal with these 'guards'. The [[Abductor]] for example has a guard that always waits in the centre of the bridge. It's untested, but it may be possible to get this guard to face in a different direction by placing a soldier as close as possible to it and ending the turn. On the next turn, have a soldier barge through the door. Again, this is untested, so use it at your own risk. More practical solutions to this include cutting a hole through the rear or floor of the room with a [[Heavy Plasma]], deploying a smoke grenade in front of the door, stepping through and launching a rocket or a grenade, or even just standing underneath the alien and firing a high explosive weapon directly at the ceiling.

== Dislodging Guards ==

Recent testing has suggested that aliens which remain fixed in place are stuck in "aggression mode" against one X-COM unit. As long as that unit does not move, the alien will not move either. To flush aliens out of fixed positions, try moving all your units, one at a time, and keep an ambush posted outside the UFO in case the alien emerges.

== Floaters and the Koan of Stairs ==

How did those Floaters get up those stairs in the first place? They certainly don't know how to go down them.

Eventually, the hapless floater will have the AI try to route it from the top of a staircase to the bottom of the same staircase. Unfortunately, not having legs, the art of walking down stairs escapes the floater. With a few precautions to abuse line-of-fire bugs, this makes the stuck Floater easy prey for even a lone X-COM agent.

[[Category: Tactics]]

Line of sight

2010-11-20T12:19:23Z

Zaimoni:

All units, both X-Com and alien, have a ''line of sight''. A unit's line of sight encompasses any objects or other units which are:

*Within visible range
::Visible range for X-Com soldiers is 20 tiles during the day and dawn/dusk, 9 at [[Night Missions|night]]
::Aliens are not subject to the lighting penalties and have a 20-tile range at all times
*Not blocked by terrain, smoke, or other units
*Within the unit's ''field of vision''

All units have a 90 degree field of vision, radiating outward in a cone in whichever direction they are facing.

[[Image:LOS_straight_facing.gif|left|framed|Unit facing South. Visible squares are in white.]][[Image:LOS_diagonal_facing.gif|left|framed|Unit facing Southeast. Visible squares are in white.]]
 

Note that ''line of fire'' is not necessarily the same as ''line of sight''. There are cases where you can shoot around objects (such as corners) that you cannot see around, and you can always shoot beyond the 20-square visual range (see [[Scouting#Scout/Sniper Tactics|Sniper Tactics]]). You can also shoot through smoke that you can't necessarily see through.

Also note that you can't see aliens ''right next to you'' when you first go through a door. To see adjacent aliens, you will need to turn twice to check your flanks: one facing (45 degrees) to the left, then two facings (90 degrees) to the right (or vice-versa). This will allow you to scan a whole room upon entry, obstacles notwithstanding. Thankfully, turning in place does not trigger [[Reaction_fire_triggers|reaction fire]].

== Visual range ==

[[Image:VizRange20.gif|right|thumb|200px|Tiles visible in daylight (range 20) or with [[Night Missions|night]] illumination (9, inner border).]] The visual-range map is "rounded" and decreases by 2 tiles in one dimension for every 1 tile in the other dimension, until it reaches the pure diagonal (see inset map). You may want to have soldiers e.g. just outside visual range of a UFO exit, so that enemies have used a chunk of their TUs before they see you (the better to [[Reaction_fire_triggers|reaction fire]]). Anyone directly lateral to the exit (no diagonal offset) should be at range 20, but others (with diagonal offset) should be "closer". For example: An offset of 19 tiles in one dimension (e.g. north-south) and 1 tile in the other (e.g. east-west) is also just outside the "20" visual range. Using this can help you have multiple shooters able to reaction-shoot to a particular tile at the same time - aliens are liable to stop and shoot as soon as they see even one soldier.

Elevation does not add distance to visual range. You will see an alien on the ground when at range 20 (horizontally) and elevated 4 levels, just as you'd see him at range 20 when at ground level. Keep this in mind if stacking flying-suit shooters vertically in "alley" situations (or any other time, for that matter). But beware overhangs that might block your LOS.

Note that "visual range of 20" is for sighting ''enemies'', the most important thing in X-COM. ''Terrain'' works slightly different. Specifically: At ground level, you see terrain to 21 tiles away, not 20 (counting from your tile as 0, as was demonstrated in inset for sighting enemies). Also, if you are elevated, the range increases by one for each level, up to 24 tiles away for 4th level. Yet this is only for terrain. You will not see enemies past 20 tiles, as explained above. It can still be useful to know, however. You may think you've visualized the whole map out to the edge, but actually you haven't swept the last few edge tiles for enemies if you are flying high and stopping as soon as you can see all the way to the edge. Then again, it's unlikely that an alien is there and/or doesn't wander into view around the time you're checking it out. An exception exists with several [[Arctic_Terrain|arctic]] map [[Module|tilesets]], where puddles have the potential to trap non-flying aliens. Also known as: if you can't find the last alien on an arctic map when you thought you'd checked the whole thing, double-check corners or other edges where tilesets have made "traps".

 

== Blind spots around corners ==
[[image:Blind_spots.gif|right]]
There are cases where aliens can see around corners (and shoot at you) when you cannot see them. Unfortunately, the rules that govern this are complicated: a seemingly-identical or mirrored situation can produce different visibility for you and the alien depending on whether it is a northeastern, northwestern, southeastern, or southwestern corner. Furthermore, there are cases where you can shoot back at the alien (even though you can't see it), and other cases where you can't shoot it, even though it can shoot at you with impunity.

In the diagram at right, the colored arrows represent aliens (and their facings), and the colored X's represent "blind spots" -- places where your units can be shot at by unseen aliens of the corresponding color. ''Depending on compass direction'' (only a northeastern corner is diagrammed here), some of these blind spots may not be experienced by your units.

If you can spot an alien at the same instant it spots you, it will not fire upon you until your next action (see [[reaction fire triggers]]). This is why these blind spots are so deadly: in a mutual-visibility situation, your units would normally be allowed to fire first.

Due to the large number of blind spots around corners (dependent on alien placement), there is no completely safe way to round a corner. The safest approach in most cases may be the path traced by the yellow line -- and if you have few [[Time Units]] left, you should stop before reaching the green or blue X's.

Furthermore, certain narrow corridors inside UFOs and alien bases restrict the path you can follow, guaranteeing that you will pass through one or more blind spots. If you believe an alien is hiding around a corner, it may be best to throw a grenade around the corner and wait until the next turn to approach. A motion scanner might also come in handy, but beware false negatives... aliens sometimes don't move for long periods. This may be especially true of psi-capable aliens.

 

== Quirks ==

In certain cases, it is possible to see into a UFO from the outside (see [[External UFO Windows]]).

== Orchards, Cacti, and other non-wall terrain ==

These block line of sight much more effectively than line of fire, but are not as prone to one-way edges as walls. Examples (X is the soldier, O is the terrain; obviously, one should crouch behind half-height terrain to benefit):
<pre>.......
.....__
...____
XO_____
...____
.....__
.......</pre>

<pre>X....
.O...
..__.
..___
...__</pre>Aliens on the _ squares, at the same elevation, will not see the soldier even if facing him. (Cacti are less reliable than other features.) One square up is trickier, but generally crouching behind a full-height terrain feature works as above.

== One Way Diagonals ==

Proper North and West walls have a logical thickness of 1, and belong in their square. Due to a pixel-level asymmetry, for small units:
* North wall 1 square west: allows outbound line of sight/line of fire due northwest, blocks one of inbound line of sight or inbound line of fire due southeast
** extrapolated North wall 1 square south: allows inbound line of sight/line of fire due northwest, blocks one of outbound line of sight or outbound line of fire due southeast
* North wall 1 square east: blocks outbound line of sight due northeast, allows inbound line of sight due southwest (but provides cover against accurate shots anyway)
** extrapolated North wall 1 square south: blocks inbound line of sight due northeast, allows outbound line of sight due southwest (but will block your accurate shots anyway)

(Zaimoni: above was tested in turn-swapping mode for a Floater Terrorship. The wording assumes that reaction shots and intentional shots are equivalent, but this is merely Occam's Razor; it really should be tested more carefully. It is also possible that species makes a difference. In particular, the blind-spot diagram above isn't consistent with this testing.

The door-opener x was summarily ambushed, testing was done with the live agent X
<pre>A...A
__x__
..X..
..L..
</pre>)

Using the LOFTemps format, it might be possible to compute where the possibly distinct voxels used to compute line of sight and line of fire actually are.

Informative cases for future testing:
* West wall one square north, alternately West wall one square west
* West wall in own square, alternately West wall one square northwest

== Sectoid Reaction Fire ==

Sectoids are short. This noxiously changes their line of sight/line of fire.
* The Skyranger walls to the sides of the exit ramp do not block Sectoid reaction fire from the side. Other aliens evidently cannot infer the agent's presence from the visibility of their feet.
* Farm terrain? Regrettably, sectoids see your agents through fences far more easily than your agents see sectoids. Should the triggering agent survive the initial reaction fire through a still-intact fence, he should crouch immediately to get a visual on the sectoid.

Talk:Image Formats

2010-09-01T04:09:36Z

Zaimoni:

== BDY format algorithm ==

The following line isn't quite right:

''If "a" is 129 or greater, then draw 257-a pixels of the next byte; otherwise, '''read "a" bytes''' from the file and draw those colors sequentially.''

It appears to be "read a+1 bytes" for BDY files, which makes sense. If this were not the case, the value of '0' would mean "read 0 bytes and draw", which would be wasting a whole code.

~ [[User:Renegrade|Renegrade]] 10:23, 19 August 2010 (EDT)

: You're right, a+1 is correct. - [[User:Bomb Bloke|Bomb Bloke]] 19:54, 19 August 2010 (EDT)

== PCK ==
''Typically images are stored sequentially in their archives, so once you know the offset to an image and the image after that you can then read out "x" number of bytes starting at TAB[i] (where "x" is TAB[i+1]-TAB[i] and "i" is the index of the image you wish to view).''

This is not right. What if "i" was the last image, TAB[i+1] would point outside the TAB data. The system starts reading PCK data at the offset in the TAB data and stopped when 0xFF was read, that is where the 0xFF byte is for.
I assume it is ok that I rewrite this a bit.

: That is the exception that makes "Typically" right. Clearly if i is the last image then the "next image" doesn't exist, and any reader who was paying attention would know the delta procedure didn't apply.

: Generally, these articles are written to be read vernacularly, rather than with philosophical or mathematical precision. That said, rewrites that increase clarity are welcome even if they convey the same information as before. -- [[User:Zaimoni|Zaimoni]], 23:09 Aug 31 2010 CDT