UFOpaedia - User contributions [en]

User talk:Bomb Bloke:Firing Accuracy

2012-03-05T16:52:40Z

Kyrub: /* Stuff from the code */

{{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?

:: (checked) x = aFa is treated as a failure. But RNG chooses 0 as well, so no problem. BUT, as it seems, X-COM has a strange world (strange RNG, should I say) where 100% means actually more than 100%, because RNG (100) generates ['''0''',1,2... 99, '''100''']. 101 numbers. If aFa is displayed as "13%", it will actually mean that [0....12], e.g. only (13/101) = 12,87% shots get the low "dispersion effect". ((come to think about it, I guess many of non round %% acquired through testing all over wiki are probably due to the strange X-com RNG setting...)). Well well well. --[[User:Kyrub|kyrub]] 11:24, 5 March 2012 (EST)

: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)

: I still am doubtful about your whole angle approach, BBloke. As it seems to me (from the code, but it's not very clear area, I admit), there is some sort of a complicated distance factor, which is afterwards taken quite simply as RNG [divergence * distance factor]. The result is added to X (or Y) coordinate of the target. Also, be aware that the firing seems to take dispersion differently when the shot is not along straight lines (delta_x > 0, delta_y > 0). For delta_x > delta_y, dispersion along X axis is doubled (2 * delta_x -1), and vice versa. ( BTW, Note, that this probably causes the vertical shot bug. When delta_x = delta_y = 0 (e.g. unit is standing just above), the dispersion becomes an automatic 2* 0 -1 = -1. ((Now, since this bug is reported only in CE version, we really should check DOS version because it may have different approach to determining accuracy!! )).

:I checked vertical divergence and it uses the very same dispersion effect (based on RNG (distance_factor * dispersion) ), only, it is halved (weaker). --[[User:Kyrub|kyrub]] 11:39, 5 March 2012 (EST)

:: On the second thought, the vertical divergence is significantly weaker than that (4x weaker) because of the extra doubled factor for longer x or y distance to target.--[[User:Kyrub|kyrub]] 11:52, 5 March 2012 (EST)

 

===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]]

User talk:Bomb Bloke:Firing Accuracy

2012-03-05T16:52:09Z

Kyrub: /* Stuff from the code */

{{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?

:: (checked) x = aFa is treated as a failure. But RNG chooses 0 as well, so no problem. BUT, as it seems, X-COM has a strange world (strange RNG, should I say) where 100% means actually more than 100%, because RNG (100) generates ['''0''',1,2... 99, '''100''']. 101 numbers. If aFa is displayed as "13%", it will actually mean that [0....12], e.g. only (13/101) = 12,87% shots get the low "dispersion effect". ((come to think about it, I guess many of non round %% acquired through testing all over wiki are probably due to the strange X-com RNG setting...)). Well well well. --[[User:Kyrub|kyrub]] 11:24, 5 March 2012 (EST)

: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)

: I still am doubtful about your whole angle approach, BBloke. As it seems to me (from the code, but it's not very clear area, I admit), there is some sort of a complicated distance factor, which is afterwards taken quite simply as RNG [divergence * distance factor]. The result is added to X (or Y) coordinate of the target. Also, be aware that the firing seems to take dispersion differently when the shot is not along straight lines (delta_x > 0, delta_y > 0). For delta_x > delta_y, dispersion along X axis is doubled (2 * delta_x -1), and vice versa. ( BTW, Note, that this probably causes the vertical shot bug. When delta_x = delta_y = 0 (e.g. unit is standing just above), the dispersion becomes an automatic 2* 0 -1 = -1. ((Now, since this bug is reported only in CE version, we really should check DOS version because it may have different approach to determining accuracy!! )).

:I checked vertical divergence and it uses the very same dispersion effect (based on RNG (distance_factor * dispersion) ), only, it is halved (weaker). --[[User:Kyrub|kyrub]] 11:39, 5 March 2012 (EST)

:: On the second thought, the vertical divergence is significantly weaker than that (4x weaker) because of the extra doubled factor for longer x or y distance to target.

 

===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]]

User talk:Bomb Bloke:Firing Accuracy

2012-03-05T16:47:19Z

Kyrub: /* Stuff from the code */

{{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?

:: (checked) x = aFa is treated as a failure. But RNG chooses 0 as well, so no problem. BUT, as it seems, X-COM has a strange world (strange RNG, should I say) where 100% means actually more than 100%, because RNG (100) generates ['''0''',1,2... 99, '''100''']. 101 numbers. If aFa is displayed as "13%", it will actually mean that [0....12], e.g. only (13/101) = 12,87% shots get the low "dispersion effect". ((come to think about it, I guess many of non round %% acquired through testing all over wiki are probably due to the strange X-com RNG setting...)). Well well well. --[[User:Kyrub|kyrub]] 11:24, 5 March 2012 (EST)

: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)

: I still am doubtful about your whole angle approach, BBloke. As it seems to me (from the code, but it's not very clear area, I admit), there is some sort of a complicated distance factor, which is afterwards taken quite simply as RNG [divergence * distance factor]. The result is added to X (or Y) coordinate of the target. Also, be aware that the firing seems to take dispersion differently when the shot is not along straight lines (delta_x > 0, delta_y > 0). For delta_x > delta_y, dispersion along X axis is doubled (2 * delta_x -1), and vice versa. ( BTW, Note, that this probably causes the vertical shot bug. When delta_x = delta_y = 0 (e.g. unit is standing just above), the dispersion becomes an automatic 2* 0 -1 = -1. ((Now, since this bug is reported only in CE version, we really should check DOS version because it may have different approach to determining accuracy!! )).

:I checked vertical dispersion and it uses the very same dispersion effect (based on RNG (distance_factor * dispersion) ), only, it is halved (weaker). --[[User:Kyrub|kyrub]] 11:39, 5 March 2012 (EST)

 

===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]]

User talk:Bomb Bloke:Firing Accuracy

2012-03-05T16:46:56Z

Kyrub: /* Stuff from the code */

{{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?

:: (checked) x = aFa is treated as a failure. But RNG chooses 0 as well, so no problem. BUT, as it seems, X-COM has a strange world (strange RNG, should I say) where 100% means actually more than 100%, because RNG (100) generates ['''0''',1,2... 99, '''100''']. 101 numbers. If aFa is displayed as "13%", it will actually mean that [0....12], e.g. only (13/101) = 12,87% shots get the low "dispersion effect". ((come to think about it, I guess many of non round %% acquired through testing all over wiki are probably due to the strange X-com RNG setting...)). Well well well. --[[User:Kyrub|kyrub]] 11:24, 5 March 2012 (EST)

: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)

: I still am doubtful about your whole angle approach, BBloke. As it seems to me (from the code, but it's not very clear area, I admit), there is some sort of a complicated distance factor, which is afterwards taken quite simply as RNG [divergence * distance factor]. The result is added to X (or Y) coordinate of the target. Also, be aware that the firing seems to take dispersion differently when the shot is not along straight lines (delta_x > 0, delta_y > 0). For delta_x > delta_y, dispersion along X axis is doubled (2 * delta_x -1), and vice versa. ( BTW, Note, that this probably causes the vertical shot bug. When delta_x = delta_y = 0 (e.g. unit is standing just above), the dispersion becomes an automatic 2* 0 -1 = -1. ((Now, since this bug is reported only in CE version, we really should check DOS version because it may have different approach to determining accuracy!! )).

:I checked vertical dispersion and it uses the very same dispersion effect (based on RNG (distance_factor * dispersion) ), only, it is halved (weaker).
--[[User:Kyrub|kyrub]] 11:39, 5 March 2012 (EST)

 

===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]]

User talk:Bomb Bloke:Firing Accuracy

2012-03-05T16:46:36Z

Kyrub: /* Stuff from the code */

{{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?

:: (checked) x = aFa is treated as a failure. But RNG chooses 0 as well, so no problem. BUT, as it seems, X-COM has a strange world (strange RNG, should I say) where 100% means actually more than 100%, because RNG (100) generates ['''0''',1,2... 99, '''100''']. 101 numbers. If aFa is displayed as "13%", it will actually mean that [0....12], e.g. only (13/101) = 12,87% shots get the low "dispersion effect". ((come to think about it, I guess many of non round %% acquired through testing all over wiki are probably due to the strange X-com RNG setting...)). Well well well. --[[User:Kyrub|kyrub]] 11:24, 5 March 2012 (EST)

: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)

: I still am doubtful about your whole angle approach, BBloke. As it seems to me (from the code, but it's not very clear area, I admit), there is some sort of a complicated distance factor, which is afterwards taken quite simply as RNG [divergence * distance factor]. The result is added to X (or Y) coordinate of the target. Also, be aware that the firing seems to take dispersion differently when the shot is not along straight lines (delta_x > 0, delta_y > 0). For delta_x > delta_y, dispersion along X axis is doubled (2 * delta_x -1), and vice versa. ( BTW, Note, that this probably causes the vertical shot bug. When delta_x = delta_y = 0 (e.g. unit is standing just above), the dispersion becomes an automatic 2* 0 -1 = -1. ((Now, since this bug is reported only in CE version, we really should check DOS version because it may have different approach to determining accuracy!! )).

I checked vertical dispersion and it uses the very same dispersion effect (based on RNG (distance_factor * dispersion) ), only, it is halved (weaker).
--[[User:Kyrub|kyrub]] 11:39, 5 March 2012 (EST)

 

===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]]

User talk:Bomb Bloke:Firing Accuracy

2012-03-05T16:39:44Z

Kyrub: /* Stuff from the code */

{{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?

:: (checked) x = aFa is treated as a failure. But RNG chooses 0 as well, so no problem. BUT, as it seems, X-COM has a strange world (strange RNG, should I say) where 100% means actually more than 100%, because RNG (100) generates ['''0''',1,2... 99, '''100''']. 101 numbers. If aFa is displayed as "13%", it will actually mean that [0....12], e.g. only (13/101) = 12,87% shots get the low "dispersion effect". ((come to think about it, I guess many of non round %% acquired through testing all over wiki are probably due to the strange X-com RNG setting...)). Well well well. --[[User:Kyrub|kyrub]] 11:24, 5 March 2012 (EST)

: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)

: I still am doubtful about your whole angle approach, BBloke. As it seems to me (from the code, but it's not very clear area, I admit), there is some sort of a complicated distance factor, which is afterwards taken quite simply as RNG [divergence * distance factor]. The result is added to X (or Y) coordinate of the target. Also, be aware that the firing seems to take dispersion differently when the shot is not along straight lines (delta_x > 0, delta_y > 0). For delta_x > delta_y, dispersion along X axis is doubled (2 * delta_x -1), and vice versa. ( BTW, Note, that this probably causes the vertical shot bug. When delta_x = delta_y = 0 (e.g. unit is standing just above), the dispersion becomes an automatic 2* 0 -1 = -1. ((Now, since this bug is reported only in CE version, we really should check DOS version because it may have different approach to determining accuracy!! )). --[[User:Kyrub|kyrub]] 11:39, 5 March 2012 (EST)

 

===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]]

User talk:Bomb Bloke:Firing Accuracy

2012-03-05T16:39:17Z

Kyrub: /* Stuff from the code */

{{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?

:: (checked) x = aFa is treated as a failure. But RNG chooses 0 as well, so no problem. BUT, as it seems, X-COM has a strange world (strange RNG, should I say) where 100% means actually more than 100%, because RNG (100) generates ['''0''',1,2... 99, '''100''']. 101 numbers. If aFa is displayed as "13%", it will actually mean that [0....12], e.g. only (13/101) = 12,87% shots get the low "dispersion effect". ((come to think about it, I guess many of non round %% acquired through testing all over wiki are probably due to the strange X-com RNG setting...)). Well well well. --[[User:Kyrub|kyrub]] 11:24, 5 March 2012 (EST)

: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)

: I still am doubtful about your whole angle approach, BBloke. As it seems to me (from the code, but it's not very clear area, I admit), there is some sort of a complicated distance factor, which is afterwards taken quite simply as RNG [divergence * distance factor]. The result is added to X (or Y) coordinate of the target. Also, be aware that the firing seems to take dispersion differently when the shot is not along straight lines (delta_x > 0, delta_y > 0). For delta_x > delta_y, dispersion along X axis is doubled (2 * delta_x -1), and vice versa. ( BTW, Note, that this probably causes the vertical shot bug. When delta_x = delta_y = 0 (e.g. unit is standing just above), the dispersion becomes an automatic 2* 0 -1 = -1. ((Now, since this bug is reported only in CE version, we really should check DOS version because it may have different approach to determining accuracy!! )).

 

===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]]

User talk:Bomb Bloke:Firing Accuracy

2012-03-05T16:24:45Z

Kyrub: /* Stuff from the code */ , strange X-Com RNG

{{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?

:: (checked) x = aFa is treated as a failure. But RNG chooses 0 as well, so no problem. BUT, as it seems, X-COM has a strange world (strange RNG, should I say) where 100% means actually more than 100%, because RNG (100) generates ['''0''',1,2... 99, '''100''']. 101 numbers. If aFa is displayed as "13%", it will actually mean that [0....12], e.g. only (13/101) = 12,87% shots get the low "dispersion effect". ((come to think about it, I guess many of non round %% acquired through testing all over wiki are probably due to the strange X-com RNG setting...)). Well well well. --[[User:Kyrub|kyrub]] 11:24, 5 March 2012 (EST)

: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:Accuracy formula

2012-03-01T21:13:00Z

Kyrub: /* Height? */

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)

== Height? ==

I've been testing a new terrain which has several 2 and 3 level buildings and one thing that I am noticing is that accuracy seems to be affected by differences in height. The terrain allows for long range gunfights between different heights and it has become common to see my elite soldiers hitting nearly all targets at the same height but missing close to half while firing at a different height. [[User:Hobbes|Hobbes]] 17:28, 28 February 2012 (EST)

:Units seem to have better accuracy vertically then they do horizontally, but as you get higher and higher above your target, their profile effectively gets smaller (eg, if you're directly above someone, all you're shooting at is their head).

:Though there may be more to it then this. Kneeling when standing directly next to an alien (forcing them to fire downwards at you) dramatically increases your life expectancy, way more then you'd expect it to. In fact kneeling increases the odds so dramatically in your favour that you could just about believe there's a bug in the firing engine somewhere.

:Shots are weighted (according to a bellcurve) so that they'll typically be closer to what you're shooting at, on average, then they could be. At 0% accuracy, you "can" fire anywhere up to half a radian to either the left or the right of the target - at 100%, you're still not guaranteed a hit, but you will never miss by MUCH (dunno what percentage you need to achieve "perfect" accuracy). This is why rookies are more likely to hit other team members then veterans are - because even if a vet misses, odds are his firing line is going to be closer to the alien then that of a rookie, so he has less chance of hitting anything that isn't directly between him and the target.
::: (from the code: there seems to be two type of "misses", 1) a big miss, when the soldier completely misses agaisnt the odds displayed in the shooting menu, the bullet has high dispersion factor, and a 2) close shot, when the odds put the bullet just on target (close RNG call), there is a small extra divergence factor. So the rookies, obviously, get more of the first type. The first type of miss is probably responsible for the unreal "close miss" 1 or 2 tiles away. --[[User:Kyrub|kyrub]] 16:13, 1 March 2012 (EST)

:But I digress. Vertically speaking, the angle range is much lower (though I haven't measured that one precisely yet - I just know it's smaller), but it may be that the same "weighting" isn't performed. This'd make height deviations much more important then they'd first appear as shot deviations would be less predictable. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:14, 1 March 2012 (EST)
::I should have mentioned that the shooting at buildings usually involves targets at both different vertical and horizontal levels. And it gets really weird to see because you have a soldier with 90 to 100 Firing Accuracy and its shots come as if he has only half the accuracy. [[User:Hobbes|Hobbes]] 14:24, 1 March 2012 (EST)

User talk:Kyrub

2012-02-28T03:03:04Z

Kyrub:

So live Tentaculats, Hallucinoids, Xarquids, Bio-Drones, and Triscenes give you M.C. tech? Did you check them all? [[User:Magic9mushroom|Magic9mushroom]] 00:46, 25 February 2012 (EST)
: Haven't looked into this a great deal myself, but most players will probably get to research Deep One or Calcinite well before the other terrorist types. It may be the terrorist rank rather than the species that does this. -[[User:NKF|NKF]] 15:14, 25 February 2012 (EST)
It's quite possible, I know, but TFTD does have a thing about "right race" as well as "right rank". Remember that Aquatoid Navigators or even Commanders don't give you The Ultimate Threat (while both Gill Man and Lobster Man ones do). Hence I wanted to make sure of it. [[User:Magic9mushroom|Magic9mushroom]] 22:27, 26 February 2012 (EST)

I checked just the code, not the game, but I am adamant about the information. It is totally clear, no room for error. I think NKF is right, 99% players research Calcinite or a Deep one before anything else. That is how it got into the table. --[[User:Kyrub|kyrub]] 21:49, 27 February 2012 (EST)

User talk:Kyrub

2012-02-28T02:49:16Z

Kyrub:

So live Tentaculats, Hallucinoids, Xarquids, Bio-Drones, and Triscenes give you M.C. tech? Did you check them all? [[User:Magic9mushroom|Magic9mushroom]] 00:46, 25 February 2012 (EST)
: Haven't looked into this a great deal myself, but most players will probably get to research Deep One or Calcinite well before the other terrorist types. It may be the terrorist rank rather than the species that does this. -[[User:NKF|NKF]] 15:14, 25 February 2012 (EST)
It's quite possible, I know, but TFTD does have a thing about "right race" as well as "right rank". Remember that Aquatoid Navigators or even Commanders don't give you The Ultimate Threat (while both Gill Man and Lobster Man ones do). Hence I wanted to make sure of it. [[User:Magic9mushroom|Magic9mushroom]] 22:27, 26 February 2012 (EST)

I just checked the code, not the game, but I am adamant about the information. It is totally clear, no room for error. I think NKF is right, 99% players research Calcinite or a Deep one before anything else. That is how it got into the table. --[[User:Kyrub|kyrub]] 21:49, 27 February 2012 (EST)

Talk:Known Bugs (TFTD)

2012-02-24T00:23:15Z

Kyrub:

==More Unconscious Bugs==

OK maybe TFTD is just plain buggy. This may be related to the Mind Controlled units MIA bug. What I saw was:

* All human units are killed or stunned, but the game does not end, a Coelecanth keeps working (this is a bug right?). I ran the Coelecanth for at least 4 more turns, with all Aquanauts either dead or stunned.
* If I saved and restored this game with the Coelecanth, on the first restored turn I had no units. I could not use the Units menu, the Next Unit button, or the Centre on Unit button. Nothing. After letting the aliens move for one turn, I could see my Coelecanth again.
* If I aborted this mission with the Coelecanth in the ship, as expected it says "Submarine Lost" and the stunned crew - who had been placed aboard the Triton - do not make it back to base.
* However, one of the stunned crew members does make it back to base. The stunned crew were all psi weak but some were stunned whilst under alien mind control, others were not - they were just panicked. I'm not sure if the crew member who teleported back to base was mind controlled or just (morale) panicked. But I would guess he was panicked, since most of them were mind controlled.
* When this crew member gets back to base he is shown as being assigned to craft called "Weapon-1" (since the craft he was assigned to no longer exists). Since this craft doesn't exist, there is no way to unassign him from it. Even if I had a new Triton I doubt I would be able to assign him to it. Shame he wasn't injured!
* Like in a similar incident I saw before, the affected Aquanaut was the first in the list and also the most senior rank. So that ''might'' be a factor.
* In this underwater mission I saw that the Hallucinoid's melee attack definitely works, and is lethal against unarmoured Aquanauts. The melee attack is ineffective against a Coelecanth (with XComUtil improved tank armour I think). I saw no evidence of its ranged attack working, ever, despite many opportunities. It may be possible that (like the HJ Cannon on land), the Hallucinoid's ranged attack might be able to reaction-fire underwater. I didn't do enough to test this, I might try that later.
[[User:Spike|Spike]] 14:08, 8 August 2009 (EDT)

I got this situation:
Was on a ship attack mission (passenger ship). On the 2nd level, at the lift (big room with crates), one of my soldiers got MC'd while still standing on the lift. He shot a thermal shok bomb and became unconscious (while MC'd). He remained unconscious until I eliminated all aliens, waiting patiently on the lift. Now, the game didn't notify me about a dead or MIA agent, but he disappeared from my aquanauts list. Dunno what was the cause of this misbehaviour.
[[User:mingos|mingos]]

: I imagine it's the bug Zombie reported [[Exploiting_Mind_Control#Zombie.27s_Permanent_Control_of_Aliens_via_Stunning|here]] in reverse - your dude turned into an alien. He didn't count as MC'd (so no MIA message), and he didn't count as dead (so no DIA message either). That bug - and the others on the same page - really should be documented on the "master lists"... - [[User:Bomb Bloke|Bomb Bloke]] 02:45, 4 December 2009 (EST)

So... If I applied stimulant on him, he'd be hostile for one turn and then magically return to my team, I assume. Damn, all this stunned/revived/MC'd/un-MC'd and the mixtures thereof are really weird. Multiple bugs at play... [[User:mingos|mingos]]]

:Seb76's loader fixes all the mind control / unconscious bugs. These bugs have many different manifestations. [[User:Spike|Spike]] 14:05, 8 December 2009 (EST)

== Gill-men reported as Snakemen ==

I get these interesting bugs playing TFTD. A Gill-man corpse is described as a Snakeman corpse. And I get messages saying "Snakeman soldier has panicked", "Snakeman soldier has gone Berserk", when the Gillmen have morale failures. Now the game I'm running using XComUtil, and these Gill-men were created by using XComUtil REPlace command, changing them from Aquatoids and Tasoths. So this may be a fluke. Has anyone else ever noticed this? [[User:Spike|Spike]] 17:27, 8 August 2009 (EDT)

:It's due to XcomUtil. There isn't a string containing "Snakeman" (or any variant thereof) in ENGLISH.DAT, ENGLISH2.DAT or even the executable. --[[User:Zombie|Zombie]] 19:45, 8 August 2009 (EDT)

==Survey Ship v. Escort==
The Survey Ship and Escort are not interchanged on the battlescape. The sub that comes up matches the UFOpaedia entry and the picture that pops up during interception. [[User:Magic9mushroom|Magic9mushroom]] 04:31, 21 August 2009 (EDT)

: Not sure what you mean exactly. I would expect that during Interception it would look like an Escort, but when you shoot it down you see a small 1 room craft (Survey Ship) on the Battlescape map but the expected large crew and loadout from an Escort. And vice versa. Is this not what you see? [[User:Spike|Spike]] 16:17, 21 August 2009 (EDT)

No. When you shoot an Escort down the picture (although not the size of the blob) matches the design of what you term a Survey Ship, the 1 room craft. When you shoot down a Survey Ship the picture (though again, not the size of the blob) matches the larger, 3 room craft. Which is also confirmed by the UFOpaedia entries. The UFOpaedia entry for the Survey Ship looks like the larger craft and the UFOpaedia entry for the Escort looks like the smaller craft.

So the sub seen on the battlescape matches the sub picture seen during interception and the sub picture in the UFOpaedia. There's no switching in the Battlescape relative to the stuff seen in the interception window and UFOpaedia. It may be that the Survey Ship was intended to be the one-room craft (and indeed, this seems logical) but if that's the case, it's switched in all three. I checked and double-checked this. [[User:Magic9mushroom|Magic9mushroom]] 05:03, 22 August 2009 (EDT)

Ok this is interesting, you may have uncovered a general misunderstanding. It's been suggested before that maybe it's just the ''names'' that are switched.

I know you have double checked that you have never run XcomUtil or a map pack? Definitely a virgin install?

Do you still see a large crew on a small craft and a 1 man crew on the larger craft?

That the sonar blob size is wrong does suggest maybe a problem in the .exe rather than the map files.

[[User:Spike|Spike]] 05:47, 22 August 2009 (EDT)

:I don't even know how to use Xcomutil and have never downloaded it, so I can guarantee it's not been run on my Collector's Edition version.

: I see multiple aliens on the 1-room craft and 1 alien on the 3-room craft.

:I don't think the names are switched, since IIRC the Survey Ship still appears first and the Escort second in a mission. Besides, it'd have to be names ''and crew'' switched to make sense.

:The sonar blob size isn't wrong, it coincides with the reported size of the craft. Escorts are reported as Small while Survey Ships are reported as Very Small. The problem, however, is that that reported size doesn't agree with the actual size of the ships, although it does agree with their loadouts. [[User:Magic9mushroom|Magic9mushroom]] 05:57, 22 August 2009 (EDT)

:::Ok you have been very thorough on this. Let me try to summarise. The battlescape map, UFOpaedia picture and Interception window picture all agree in showing the Survey Ship as the larger of the two. The reported detection size, crew loadouts, spawn points, order of appearance, combat power, & sonar blob size all agree in showing the Escort as the larger. (We haven't looked at Mission types, a further clue.)

::: I think the most likely explanation is your earlier suggestion that all 3 "pictures" (map, intercept, UFOPaedia) were switched. Probably the last 2 are configured in the same place in the exe. As Zombie said, a miscommunication between different parts of the development team. Good investigative work! [[User:Spike|Spike]] 12:57, 22 August 2009 (EDT)

::::You two have convinced me that it is probably unintentional. I don't think it should be listed under bugs though, as it always happens and doesn't actually screw up the game or anything. It's a very odd state of affairs and one that should be listed on the pages for the ships though. I still think the Survey Ship and Escort pages should reflect what actually happens in-game, ie that we should have the bigger floor plans under Survey Ship and the smaller ones under Escort, along with listing the UFOpaedia pics as they're actually noted in-game. [[User:Magic9mushroom|Magic9mushroom]] 05:00, 23 August 2009 (EDT)

Magic9mushroom, your investigation has improved the understanding of this issue. It should definitely be flagged up on the wiki pages of both craft. And the other picture-swapping case, the supply ship, should also be flagged on the relevant wiki pages. I think both should be considered Bugs, as they are illogical / inconsistent and don't behave as a player would reasonably expect. It's not necessary that an issue is unpredictable, nor that it damage game play, to be called a bug. Most listed bugs are always repeatable, and quite a few arguably aid gameplay. So I think we should list these as bugs, add your additional findings, and update the craft wiki pages. I'm not sure if we should swap the pictures and descriptions on the wiki pages back to the unmodified state or not. I'm thinking it over. You're right that it's confusing to players who use the unmodified game. [[User:Spike|Spike]] 09:57, 23 August 2009 (EDT)

: I'll put my support for the motion that Wiki should present this information as per what players will find in an unmodified game. So if they see pictures of an apple in the Ufopaedia but find an Orange in the Battlescape instead, while the Ufopaedia Orange entry comes up with a Battlescape Apple, then let it be so, but also note that the objects have been unintentionally swapped either in one place or the other. There are plenty more inconsistencies in TFTD anyhow. -[[User:NKF|NKF]]

So then, if there are no further objections, I plan to do the following:

- Swap the listed UFOpaedia pics for the Escort and Survey Ship to match the ones found in the in-game UFOpaedia.

- Swap the listed floorplans to agree with what is actually found on the Battlescape

- Add a note to both articles that there's likely some sort of mixup.

Any objections? [[User:Magic9mushroom|Magic9mushroom]] 19:47, 25 August 2009 (EDT)

:Generally agreed but you could consider putting both images on each page, listing the unmodified one first, and saying "it looks like THIS but should probably look like THIS". [[User:Spike|Spike]] 07:45, 26 August 2009 (EDT)

I'll link each page to the other of course, so that seems a bit redundant. It's been over a day by my count so I'll do the switch. [[User:Magic9mushroom|Magic9mushroom]] 07:54, 26 August 2009 (EDT)

...and done! [[User:Magic9mushroom|Magic9mushroom]] 08:32, 26 August 2009 (EDT)

== disappearing corpses ==
I thought this one is quite well known but could not find it on the list(Remove this if I missed it somehow).
This annoying bug is regularly encountered in settings with large maps containing lots of aliens (ship lane terror missions, XCOM base assault, Alien base assault, Artefact sites). Since the item table gets too full at some point and alien corpses and I think stunned aliens as well are items they are simply disappearing when any more killed/stunned. Too bad if this happens to be your hard earned lobsterman commander...
The easiest way to reproduce it is to take leviathan load of aquanauts including a squad of strong MC troopers, bring a taser, drills and a medikit and assault an Alien base. At sea level use MC chains to put every alien under molecular control and and march them to your transport. ASAP stun one aquatoid soldier,revive it with the medikit and wall it in. Then cull the rest of the Alien garrison and stuff your pockets and backpacks with DPLs and ammo, Sonic pulsers, corpses and other weapons and ammo(unload ammo from weapons) until you can carry no more. Once you are done finish the off the last aquatoid and proceed to the second stage. There drop the stuff and play hunt the last alien(in order to get all the loot from the base) and soon you will encounter the bug.--[[User:Tauon|Tauon]] 15:13, 11 October 2010 (EDT)

== Multi-part map ammo loss ==

I believe this is XComutil related. It was intended to solve the problem of not recovering any loot on the first part of the mission.

It's actually worse than that. Plain vanilla TFTD loses everything on the first map that is not being carried by aquanauts. Including everything in the Triton floor area. So if you had a few spare Gas Cannons on standby at the sub for example, but left them when you proceeded to the second part, you'll lose them for good.

Partly to avoid this bug, and to allow you to collect any loot in the first map, XComutil returns this stuff back to base. Although, it seems that XComutil sometimes gets carried and removes all your carried ammo as well.

This is just a guess, but it might be related to ammo that the game placed in inventory at the start of the mission. If you haven't moved them or unloaded/reloaded the weapons, XComutil may be seeing them as not being owned by anyone. -[[User:NKF|NKF]] 04:02, 31 October 2010 (UTC)

:Thanks NKF I will investigate further. [[User:Spike|Spike]] 19:04, 31 October 2010 (UTC)

:Well this just gets weirder. In one test, I left everything as loaded by the equip phase. In that case, when I get to stage 2, every clip that was originally loaded, is in the equipment pile. I can live with that. Everything that was left in the stage 1 equipment pile is gone - I can live with that, too. Not clear if the stage 1 equipment pile has been teleported back to my base-of-origin. It's hard to tell, because automatic re-equip of guns and ammo after the mission is instant (hence the "Not enough equipment to fully re-equip troops" message).

:In the 2nd test, instead I manually reloaded every item. Every ammo unit that I had manually loaded into a gun during stage 1, was gone at the stage 2 equip phase. Even all the ammo that Aquanauts had been carrying as spares, was gone. The only ammo I had was one gauss pistol clip which I suspect I forgot to manually reload - so it was only there because of the behaviour observed in the preceding test (previous paragraph). And, the ammo had definitely not teleported back to base, because after I aborted the mission (at the stage 2 start area), my ammo stores back at base were depleted by pretty much the same amount as the missing ammo. So I think something's going badly wrong here.

:(Tests were done using XcomUtil 9.60, not XcomUtil 9.7 Beta.) [[User:Spike|Spike]] 20:41, 1 November 2010 (UTC)

:I tried installing XcomUtil 9.7 Beta, to test that version, but had some issues with my Steam TFTD installation. I'll try again tomorrow. [[User:Spike|Spike]] 21:54, 1 November 2010 (UTC)

:: Perhaps the older version of XComutil was just too eager with sending the loose items back home? Either way, don't forget to do a test in the plain vanilla copy of the game if you get a chance. My tests were based on a vanilla copy of the v2.0 dos version in Dosbox. Of course, your mileage certainly may vary.

::: OK I checked plain vanilla - full reinstall of Steam version (Dosbox, though reported by XcomUtil 9.7 as TFTDWin 1.0 version). Plain vanilla install, using the savegame from the XCU9.6 game, and a Turn 1 state (so XCU9.6 may have messed with things during the equip phase). The results are as expected - all carried equipment and loaded ammunition, including ammo counts, are preserved between stage 1 and stage 2. Equipment pile or other dropped items from stage 1 are not carried over to stage 2. Alien kills, corpses and artefacts from stage 1 are credited upon abort from stage 2. All civilians from both stages die upon abort. Mission was a cargo ship mission. [[User:Spike|Spike]] 20:38, 3 November 2010 (UTC)

::: I also checked XCU 9.7 Build 422, clean install on a clean install of TFTD (Steam). Good news, the bug is fixed. I can't reproduce any of the bad behaviour - no missing ammo, no missing equipment. Cool! [[User:Spike|Spike]] 20:45, 3 November 2010 (UTC)

::One thing that has come from this is that I'm never going to leave any excess items in the Triton on two-parters ever again. Well, unless it's every-day easy-to-get stuff like the Sonic Cannons. Just have to be mindful of the spare tazers and chem. flares. -[[User:NKF|NKF]] 07:11, 2 November 2010 (UTC)

: And just a minor update note for this discussion since I noted it in the article on the two-parters: The losing-everything in the first part bug is a TFTD v1.0 issue. Not a problem for 2.0 or CE. -[[User:NKF|NKF]] 23:18, 26 April 2011 (EDT)

:; Actually, 2.0 only resolves this issue in the case that you KILL everything in part 1. If you placed your guys in the exit zone and hit abort, you might still lose stuff. You definitely don't get the loot in this case. [[User:Jasonred|Jasonred]] 14:34, 27 April 2011 (EDT)

== Land missions reaction fire bug ==

This is an expansion of a bug known as [http://www.ufopaedia.org/index.php?title=Known_Bugs_%28TFTD%29#X-COM_Equipment_Glitches "X-COM underwater-only weapons fire on land missions"]. The bug may actually be more serious than that and it may extend to all present units.

The game tries to check for land availability of a weapon in hand, but it wrongly tests the first OBPOS.dat item instead. If the first item stored in OBPOS is not allowed on land, no reaction fire is possible, during the whole mission, both for X-Com and for Alien side! If, however, the first item is allowed, all reaction fire is always possible, for both normal and underwater-only weapons.
Note: This has not been tested in game. I don't know how the first OBPOS.dat is selected. Maybe this effect occures very rarely, or never. The code leaves the possibility open. --[[User:Kyrub|kyrub]] 07:19, 26 April 2011 (EDT)

:Very interesting research. Also very scary! [[User:Spike|Spike]] 16:34, 26 April 2011 (EDT)

:: They probably failed to point to the right index. Either hardcoding a 0 in as the obpos index (or offset if using memory pointers). That actually makes me wonder if this is what influences the aliens' reluctance to react against the cannon or aquajet Coelacanths? If it is then my theory that Coelacanths are (nearly) immune to reaction fire may stem from this. -[[User:NKF|NKF]] 23:18, 26 April 2011 (EDT)

== Deep One "shooting" is suspect ==
The Deep One seems to miss most of the time, and it hits VERY rarely. This is strange, since his internal (turret) accuracy is not bad at all (75% for Snap shot, 110% for aimed shot, but the latter is less used due to the closer distance of engagement). Deep one has FA = 50 which on normal difficulty gives: 50*75% = 37,5% for a snapshot. This does not seem to match the reality.
What could go wrong? The "shot" seems to follow the grenade trajectory. Grenades, however, are always targeted at the ground. As it seems, there is no adjustment for the Deep One targetting in the code. My guess is, the Deep One shoots on the ground under the soldier and it hits him only by accident. Same should be true for Celatid in UFO. Can anybody confirm the experience? --[[User:Kyrub|kyrub]] 19:23, 23 February 2012 (EST)

TRTBAG

2012-02-24T00:06:29Z

Kyrub: /* Molecular Control Technology (optional) */

__NOTOC__
= The TFTD Research Tree Bug Avoidance Guide =
<div align = "right" style = "font-size:80%;">A needlessly wordy article by [[User:NKF|NKF]]</div>

__TOC__

 

==Foreword==

The designers of X-Com Terror From The Deep seem to have attempted to make the research process in TFTD much more complicated than its very straightforward predecessor's research tree. They have succeeded in doing this, but have also introduced many glaringly unacceptable errors in the process that can prevent you from completing the game.

Some players may have had the luck of not bumping into any of these errors by picking all the right research at the right time, or have a game that doesn't seem to have these problems. Unfortunately, as the research order in TFTD is non-linear, that is to say you can research anything you've got in any order you want, a lot of us are less fortunate. This guide should help to assist and point out some of the stickier bits.



Also note that ''this is not a reproduction of the research tree''.
There are many documents in a variety of formats describing the complete research tree on the Internet that you can peruse. This document is merely a supplement.

===Definitions===
The word 'prerequisite' is used quite frequently
throughout this document. As prerequisite is not
an everyday word, here is its definition.

:;Pre-Requisite: Pre- means 'before', Requisite means something that is required in order to achieve something. In Layman terms and in context with the game: to get this thingy, you need to research orhave these other thingies first.
 
=== Spoiler Warning ===
While this may spoil the game if you are new to
it, it is better to be informed than to make a
mistake that is irreversible. The game IS hard,
even for X-Com UFO veterans.

With the exception of MC technology, this
document discusses a branch of the research tree
that will take you from the very start of the
game all the way to the final chamber in T'Leth. (Well, not exactly, but it'll give you everything you need!)

== Glitches in the System ==

There are two major occasions where research can grind to a halt:

* An alien is required to further research AFTER certain projects are completed
* An object is needed in storage before research is completed

== Interrogations ==

A large portion of the research can be cut off by researching an alien in the incorrect sequence.

For example, in order to open a new research branch, you need to have researched project A and B and then interrogate alien C in order to get new technology D.
If you were to interrogate alien C before completing research on A and B, technology D will not appear for research once you've completed research on A and B.
In order to get D to appear, you must capture another alien and interrogate it again.

So, as a rule of thumb, if an alien is a prerequisite for any particular tech item,
it is highly recommended that you hold off the completion of the interrogation until
all the prerequisites have been researched.

== The Deep One Dilemma==

The primary research path at an abstract level looks roughly like so:
  
<center>
{| cellspacing="3"
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Armour
|| →
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Subs
|| →
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | T'Leth
|}
</center>
 
The path for Armour looks roughly like:
  
<center>
{| cellspacing="3"
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Deep One Corpse
|| →
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Aqua Plastics
|| →
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Plastic Aqua Armour
|| →
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Ion Beam Accelerators
|| →
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Live Deep One Terrorist
|| →
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Ion Armour
|| →
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Magnetic Navigation
|| →
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Mag. Ion Armour
|}
</center>
 
Not all of the technologies need to be reseached in the exact order - with the exception of the live [[Deep One]], which should only be reseached after you have met the other prerequisites for Ion Armour.

Without Armours you won't get to research advanced subs; without advanced subs you can't reach T'leth and defeat the aliens once and for all.

You will need a living specimen and a
corpse. In older versions of the game, where you
need a lobsterman navigator to get magnetic
navigation, getting a live Deep One Terrorist is
not that important. However, in TFTD versions
with the v2 update, success hinges on getting a
living Deep One terrorist.

Deep One Terrorists can be found in most Gill-man
land missions. They do not appear underwater (1),
and are replaced with Xarquids if you shoot down
Gill-Men terror ships.

:(1) ''you may find some Deep One Terrorists in the second level of T'Leth; however, you may only get there after when you already have the tech they provide.''


Don't worry if you missed them, Gill-Man terror
sites do still appear when it's late in the game,
although they are abundant early in game.


Deep One Terrorists also appear in 'mixed' alien
crew land missions. A mixed crew is made up of a
variety of species, and in terror sites and base
attacks, will be supported by a variety of
land-based terror units, which includes the Deep
One Terrorist as well as the odd Xarquid (which
normally replaces the Deep One Terrorist for
underwater missions).


Just promote a terror site by leaving any ships
on terror missions alone, or encourage the
Gill-Men or 'mixed' crews to attack your base by
shooting some of their USOs down near your base.
You might also want to dismantle your M.C
generator to improve the likelihood of an attack.


Before starting research on the Deep One
Terrorist, refer to the Ion Armour section.


Finally, researching an alien medic and getting
information on the Deep One Terrorist or its
corpse is not the same as researching the real
thing. You will not get any research benefits
from the alien medic's report. Keep this in mind.


== The Tasoth Commander Trap==

Note that it is unfortunately difficult to double check the validity of this bug at the present time, so this section has been intentionally left vague for now, but is left for the benefit of the that may experience it.

Most copies of the game do not recognise the Tasoth Commander as a legal alien (Although the alien/rank combination can still exist) and cannot be researched. If for whatever reason one does somehow appear on your research list, do not complete the research on it until after obtaining a Leviathan and the final mission launch button. Researching it will prevent these topics from being researched through normal means.

If you're unsure whether you'll face this bug or otherwise, update your game with the v2 patch if you are using the Dos version. The Collectors edition of TFTD is already updated to v2.

==Required Objects ==
=== The MC Reader and Sub Construction samples===

These two items, the MC Reader and the Sub
Construction store item, are special in that they
will only become available for research if and
only if a sample is available in your general
stores before completing research for their
prerequisite technologies.


If you do not have any when completing research
on the last of their required technologies, they
will NOT appear later even after acquiring a few
samples.


For example: If you've done Zrbite and are about
to finish research on the Transmission Resolver,
make sure that you have the 'sub construction'
item in stores before the research on the
Transmission Resolver hits 100%, or vice-versa.


Between the MC Reader and the Sub Construction
store item, the 'sub construction' store item is
required to win the game. The MC Reader is
optional.


Note: This does not apply to Aqua Plastics. You
can research it even without any samples.


Note: If this happens to you and you don't have a suitable save game to revert, you can still rescue your game using a hex editor. Open the file RESEARCH.DAT that resides in the appropriate save game folder and set the byte at the hexadecimal offset 0x1B4 to 1. This will allow you to research Alien Sub Construction. (It will allow you to research it even if you don't have the prerequisite technologies, in fact, but you wouldn't cheat that way, would you?) 


Note: Another way to combat the research tree bug for Alien Sub Construction is to modify
[http://www.ufopaedia.org/index.php?title=PROJECT.DAT_%28TFTD%29 PROJECT.DAT]. Open the file with a hex editor and set the byte at the hexadecimal offset 0x26 to 01. This will make Alien Sub Construction appear in your research, then all you have to do is assign some scientists and complete it. Note that this bypasses all prerequisites. (tested on TFTD v2 but should also work on other versions)
 


'''Modify save games at your own risk. You should always create a backup first.'''


 

== Version differences==

There are two versions of TFTD. The original
unpatched version of TFTD and the one with the v2
update.


Players with the Collectors Edition of TFTD have
the version with the v2 patch.


The known changes in the research tree are as
follows:


====Unpatched====


A Lobsterman Navigator is needed to research
Magnetic Navigation


Ion Armour is not required for Magnetic Ion
Armour. All the technologies you need for
Magnetic Ion Armour are Plastic Aqua Armour, Ion
Beam Accelerators and Magnetic Navigation.


====v2====


Magnetic Navigation can be researched as soon as
one is in storage. The lobsterman navigator is
NOT required.


Ion Armour is required for Magnetic Ion Armour.
Magnetic Ion Armour now just requires Magnetic
Navigation and Ion Armour.


Yes, in other words, the v2 patch makes it easier
to get Mag. Ion Armour. However, it also means
that winning the game hinges on your ability to
obtain a live Deep One terrorist AND researching
it in the right order.


If you patch your game and reload a campaign
created before the patch, you might face a few
research problems. It's not that common, but you
might find that you'll have some trouble with
researching the more advanced armour via the V2
method. There should be no problems if you
haven't even started on the Ion Armour or Mag Ion
Armour yet. It's mostly for campaigns where
you're already half-way through researching the
armour.

====v2.1====
Only difference from v2 (per [http://www.strategycore.co.uk/files/index.php?dlid=192 StrategyCore]) is that the MC Reader bug is fixed: it can be research even if you didn't have a sample when MC Lab was complete. Note that TFTD CE is v2 and does not include this fix.

= The Good Bit=
The all important good bit gets down to the brass tacks. It's probably why you're here, so dig in!
 

=== Alien Sub Components ===

{| cellpadding="6" cellspacing="0" rules="all" style="border: 1px solid gray; text-align: center; background: #F9F9F9"
|- style="background: lavender; border: 1px gray solid"
! width="15%" | Technology !! width="20%" | Prerequisities !! Notes
|-
| Zrbite || None || style="text-align: left" | A clump of Zrbite can be found underneath an Ion Beam Accelerator unit. If any explosive detonations occur near the IBA unit, it will be destroyed as it is very brittle (or rather, the IBA will blow up).

You can pick up these clumps, but finding a clump only occurs in unusual circumstances. For example, throwing an unconscious soldier into an IBA and waiting for him or her to wake up. Falling down onto one or walking into one with the walk-through-walls bug.

Xcomutil users will often find Zrbite clumps lying about when selecting a USO floor map that is not the same as the type of USO you're actually attacking.
|-
| Aqua Plastics || Deep One corpse || style="text-align: left" | You don't need any aqua plastics to research it. You just need the Deep One corpse.
|-
| Ion Beam Accelerators || None || style="text-align: left" | Ion Beam Accelerator units are found in intact alien USOs. Most smaller enemy subs will lose their IBA units if shot down, although some of the IBA units may survive if they're in larger ships.
|-
| Magnetic Navigation || None (TFTD v2) or Lobsterman Navigator (TFTD pre-v2) || style="text-align: left" | In older versions of the game, a Lobsterman Navigator is required to get Magnetic Navigation. Otherwise, it should appear immediately on the research list once one is in storage.
|-
| Transmission Resolver || Magnetic Navigation || style="text-align: left" |  
|-
| Sub Construction || Sub Construction (item), Zrbite, Transmission Resolver || style="text-align: left" | Keep at least one 'sub construction' component in storage before completing either of the two prerequisites. If you don't have one when both the prerequisites have been met, you will not get the 'sub construction' tech item, which is required for the advanced submarines
|}
 

=== Armour ===
{| cellpadding="6" cellspacing="0" rules="all" style="border: 1px solid gray; text-align: center; background: #F9F9F9"
|- style="background: lavender; border: 1px gray solid"
! width="15%" | Technology !! width="20%" | Prerequisities !! Notes
|-
| Plastic Aqua Armor || Aqua Plastics || style="text-align: left" | Aqua Plastics are obtained from a Deep One corpse. You need not have any actual aqua-plastics in storage to get the Aqua Plastics research item.
|-
| Ion Armour || Ion Beam Accelerators, Plastic Aqua Armour and a Deep One Terrorist || style="text-align: left" | Research the first two prerequisites in any order you wish. However, you MUST research the live Deep One Terrorist LAST. If you researched this alien earlier, you won't get Ion Armour. Capturing another Deep One Terrorist is possible, but there is a small chance that you will not be able to research any more of them.

This is especially important in versions of TFTD patched with the v2 update, as without Ion Armour, you cannot get Magnetic Ion Armour, which in turn is needed to get the advanced submarines.
|-
| Magnetic Ion Armour (TFTD v2) || Ion Armour, Magnetic Navigation || style="text-align: left" | If you don't know what version of the game you have, the method in which you obtain Mag. Ion Armour will tell you which one it is.

For versions v2 and up, Magnetic Navigation becomes available the moment you have a sample in storage. Also keep in mind that Ion Armour is compulsory.
|-
| Magnetic Ion Armour (TFTD pre-v2) || Magnetic Navigation, Ion Beam Accelerators || style="text-align: left" | In older versions of TFTD, to get Magnetic Navigation, you need a Lobsterman Navigator. Keep in mind, Ion Armour is not compulsory.
|}
 

=== Submarines ===
{| cellpadding="6" cellspacing="0" rules="all" style="border: 1px solid gray; text-align: center; background: #F9F9F9"
|- style="background: lavender; border: 1px gray solid"
! width="15%" | Technology !! width="20%" | Prerequisities !! Notes
|-
| Manta || Magnetic Ion Armour, Sub Construction || style="text-align: left" | Refer to the sub component section for notes on Sub Construction. This submarine allows construction of the more advanced SWS.
|-
| Hammerhead || Manta ||  
|-
| Leviathan || Hammerhead, Lobsterman Commander || style="text-align: left" | The Lobsterman Commander should be researched after the Hammerhead. Also, for your convenience, don't forget to research 'alien origins' first so that you don't have to capture a third lobsterman commander to win the game.

If you did not research the commander and the hammerhead in the right order, don't worry, just research another Lobsterman Commander.

Note (to Hexedit): Open the file RESEARCH.DAT that resides in the appropriate save game folder and set the byte at the hexadecimal offset 0x27A to 1. This will allow you to research The Latest Flying Sub aka Leviathan
|}
 

=== Techs to Win the Game ===
{| cellpadding="6" cellspacing="0" rules="all" style="border: 1px solid gray; text-align: center; background: #F9F9F9"
|- style="background: lavender; border: 1px gray solid"
! width="15%" | Technology !! width="20%" | Prerequisities !! Notes
|-
| Alien Origins || Any live alien ||
|-
| The Ultimate Threat || Alien Origins and a Lobsterman Commander || style="text-align: left" | Research the commander last. If you researched the commander before alien origins, don't worry. Just research another commander.
'''* A lobsterman Navigator can also substitute for the commander'''
|-
| T'Leth, the Alien's City || The Ultimate Threat and a Lobsterman Commander (another one) || style="text-align: left" | You need to research another lobsterman commander.

If you researched the Tasoth commander any time in the past, then there's a possibility that this very
important tech item will not appear, which means your current campaign has been scuttled and has already sunk all the way to the bottom of the ocean floor. Period.

If you don't have any saves made before completing research on the Tasoth commander, then your only recourse is to start a new game.
|}
 

=== Disruptor Pulse Launcher (optional) ===

Optional as you do not need the DPL torpedoes to win the game. It's not a serious problem, but is mentioned anyway to ally any concerns about the launchers not appearing for research.

{| cellpadding="6" cellspacing="0" rules="all" style="border: 1px solid gray; text-align: center; background: #F9F9F9"
|- style="background: lavender; border: 1px gray solid"
! width="15%" | Technology !! width="20%" | Prerequisities !! Notes
|-
| Disruptor Pulse Launcher || Zrbite || style="text-align: left" | As soon as you've researched Zrbite, you can start research on the DPL launcher and its ammo - assuming you had a sample in storage upon completion of the project.

However, unlike Sub Construction and the Mind Probe, the DPL Launcher has a failsafe. If you did not have any samples upon completion of Zrbite, you will be able to make them appear for research the moment the '''next''' research project is completed.
|}
 

=== Molecular Control Technology (optional) ===

Optional because you don't need MC tech to win the game. But as its research branch has a notable bug, is included as well.

{| cellpadding="6" cellspacing="0" rules="all" style="border: 1px solid gray; text-align: center; background: #F9F9F9"
|- style="background: lavender; border: 1px gray solid"
! width="15%" | Technology !! width="20%" | Prerequisities !! Notes
|-
| M.C.-LAB || Any Live Terrorist || style="text-align: left" | Either of the two terrorist units will give you the M.C.-Lab.

Deep One Terrorists generally follow Gill-men and Calcinites associate themselves with Aquatoids. Both aliens can be found in 'mixed' crew land missions.
|-
| MC Reader || MC Reader (item), M.C.-Lab || style="text-align: left" | The MC Reader research item will only become available if research on the M.C.-Lab is completed while an MC Reader is in storage.

If you miss out on this, you will NOT get the MC Disruptor or the MC Generator for the rest of the campaign.
|-
| MC Disruptor || MC Reader and any live Tasoth || style="text-align: left" | Excluding the Tasoth Commander, of course.

While the Ufopaedia says it only works underwater, this item will work on land. I believe the text was meant to say that only aquanauts with 'MC implants' can use it, the word 'underwater' seems like a typo that was never removed.

Again, if you research the live Tasoth before completing the research on M.C. Reader, you will be forced to capture and interrogate another live Tasoth in order to get the M.C. Disruptor technology.
|-
| MC Generator || MC Disruptor || style="text-align: left" | This item will protect your base from being found, but it does not work 100% of the time. Aliens can still attack shielded bases if their scouts are lucky. The magnitude of USOs successfully spotting your base is reduced.
|}
 

=== Melee Weapons (optional, but handy) ===

Vibro Blade research comes from the Calcinite corpse. Once that research is done, if you've autopsied a Gillman corpse by that point (more than likely) you also get to research Thermic Lance. Once Thermic Lance is researched, Heavy Thermic Lance, last in this line, can be researched

=== Obligatory Disclaimer Claptrap ===

This document will not always be 100% accurate, as the game tends to behave differently for
different players with different computer systems and game editions.


These notes are derived through many controlled tests and observations with the MS-DOS
edition of Terror From The Deep with the TFTDv2 patch. Any noticeable difference between the
patched game and the older versions are noted. Otherwise, these notes are valid for practically
any version of TFTD available on the PC, with the possible exception of TFTD for the Sony Playstation.


TFTD, Terror From The Deep, X-Com, XCOM, et. al.
originally developed by some very fine people. Originally distributed by Microprose. Now? Who knows.


As the purpose of this document is to inform, feel free to distribute any information in this
document as you see fit.


Many thanks for the input and feedback from the
regular posters on the Xcommand and X-Com
Tactical Command forums for assisting in the
preparation of this document. Some indirect
thanks to the fine folks on the alt.games.x-com
Usenet newsgroup as well. Extra bits and pieces here and there picked up from the xcomufo.com forums as well.


[[Category:Research (TFTD)]]

Talk:PROJECT.DAT (TFTD)

2012-02-24T00:04:50Z

Kyrub:

For me it looks like Transmission resolver is at offset 52, not 58? [[User:Battlesquid|Battlesquid]] 20:25, 25 July 2010 (EDT)

Showing the first 0x5f bytes:
<pre>
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 74 03 00 00 00 00 00 00 00 00 00 00 00 00
</pre>

This is how the file looked like when researching Transmission resolver
[[User:Battlesquid|Battlesquid]] 20:32, 25 July 2010 (EDT)

Yes, the sequence is wrong. Gauss weapon's clips are not where the table shows them to be. It's Gauss Pistol, Gauss Rifle, Gauss Canon.... All three clip research entries are inserted after Mag Ion Armour, before Coelacanth- Gauss. --[[User:Kyrub|kyrub]] 19:04, 23 February 2012 (EST)

Talk:PROJECT.DAT (TFTD)

2012-02-24T00:04:20Z

Kyrub:

For me it looks like Transmission resolver is at offset 52, not 58? [[User:Battlesquid|Battlesquid]] 20:25, 25 July 2010 (EDT)

Showing the first 0x5f bytes:
<pre>
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 74 03 00 00 00 00 00 00 00 00 00 00 00 00
</pre>

This is how the file looked like when researching Transmission resolver
[[User:Battlesquid|Battlesquid]] 20:32, 25 July 2010 (EDT)

Yes, the sequence is wrong. Gauss weapon's clips are not where the table shows them to be. It's Gauss Pistol, Gauss Rifle, Gauss Canon.... They are inserted after Mag Ion Armour, before Coelacanth- Gauss. --[[User:Kyrub|kyrub]] 19:04, 23 February 2012 (EST)

PALETTES.DAT

2011-12-19T21:55:23Z

Kyrub: /* TFTD Tactical Palettes */

=Introduction=

Back in the days of low video memory, storing each pixel as a multi-byte color value (such as in today's "High Color" and "True Color" modes common under MS Windows) was not practical. Instead, a common method for was to create a palette of 256 different colors (usually of 3 bytes each), and then use single byte values to index into that. The ability of a video card to use such a palette was known as "VGA compatibility". 
 
This dramatically decreased the memory requirements of a given image, though it lowered the amount of colors that could be used in any single moment. 
 
There are a total of five "complete" palettes for UFO and three for TFTD, each for a different situation. Each is made up of the standard 256 colors stored as three byte RGB records (A value for Red, a value for Green, and a value for Blue). This makes a total of 768 bytes per palette. 
 
Each RGB value has a maximum intensity of 63/x3F (making a total of 262,144 shades available, which seems to be [http://en.wikipedia.org/wiki/Mode_13h standard for VGA]), as opposed to 255/xFF (which would have provided 16,777,216). If you want to use the 64 intensity values in a 256 intensity world, just multiply each value by 4 and you'll achieve the correct strength (or near enough - at least, this is how the CE versions of the game deal with the issue). Each palette has a six byte 'buffer' following it. While their meanings are unknown, they are:

UFO: TFTD:
Pal1: B7 13 FF 76 FE 50 Pal1: 66 83 7D F8 01 75
Pal2: A1 E8 13 0B 06 E6 Pal2: 45 F0 01 C0 01 D0
Pal3: 01 00 8B 46 FA 0B Pal3: B8 13 00 00 00 E8
Pal4: FF 76 10 FF 76 0E
Pal5: C8 1E 00 00 1E B8

Five palettes of 768 bytes each, plus five buffers of 6 bytes each,
makes 3,870 bytes in Palettes.Dat (or 2,322 for TFTD's three palettes).

=Usage=

Color 0 is not used in the game, it instead represents "transparency" (ie. Pixels which should not be drawn to the screen). 
 
The UFOpedia uses the first, second, fourth or fifth palettes, depending on the requirements of the entry being displayed. 
 
The second-to-final 16 colors of each palette are reserved. These are replaced in-game by the colors from the appropriate [[PALETTES.DAT#BACKPALS.DAT|BACKPALS.DAT]] palette, and used to draw the backgrounds of the bordered windows; where there are no background images they are unused. 
 
[[Image:5_BattleScapePal2.Png|right|frame]]
The exception to this is the Tactical palette, where the final 16 colors are replaced by a greyscale set stored in neither of the palette files (pictured right; presumably they are hard coded into the [[TACTICAL.EXE|executable]] instead). These colors can be used by objects or terrain, etc, but are not loaded for the UFOpedia display. 
 
Because of this there are two different sets of item images, each bearing the title "[[BIGOBS.PCK|BigObs]]": Those used in the UFOpedia (a collection of 57 PCK files in the [[UFOGRAPH]] folder), and those used in Tactical mode (a single PCK archive in the [[UNITS]] folder). 
 
TFTD has less palettes stored in this file then UFO and instead re-writes them as required on the fly (or uses hard coded versions from the executable).

=Color Indexes=

==UFO==

[[image:1_GeoScapePal.Png|center|frame|1. GeoScape World View.]]
[[image:2_UnknownPal.Png|center|frame|2. Base Palette.]]
[[image:3_GraphPal.Png|center|frame|3. Graph Views.]]
[[image:4_ResearchPal.Png|center|frame|4. Research Displays.]]
[[image:5_BattleScapePal.Png|center|frame|5. Tactical Palette.]]
==TFTD==

[[image:TFTD_Pal1.png|center|frame|1. GeoScape World View.]]
[[image:TFTD_Pal2.png|center|frame|2. Unknown.]]
[[image:TFTD_Pal3.png|center|frame|3. Graph Views.]]

=TFTD Tactical Palettes=

Like UFO, TFTD has a basic set of sprites for use in the battlescape which it shades according to the time of day. Unlike the original however TFTD has underwater missions of three different depths, as well as land missions - For each depth level a different palette is used. The tactical palettes are stored in D0...D3.LBM files. 
 
[[image:TFTD_Tact1.png|center|frame|1. Land & Inventory Displays.]]
[[image:TFTD_Tact2.png|center|frame|2. Shallow Water.]]
[[image:TFTD_Tact3.png|center|frame|3. Medium Depths.]]
[[image:TFTD_Tact4.png|center|frame|4. Deep Sea.]]

=BACKPALS.DAT=

This file contains palettes used to draw [[BACK01.SCR-BACK17.SCR|background images]]. These small 16 color palettes replace the second-to-final 16 entries of the primary palettes in game. They are used to display the background images of bordered windows as well as the background of the load game screens, and the terror site announcement window. They are stored using the same 3 byte RGB format as the primary palettes. This file contains eight, 16 color palettes. 128 colors in total. 384 bytes in all.

[[image:BackPals.Png|center|frame|Palettes used for background images.]]
[[image:TFTD_BackPals.Png|center|frame|Version used by TFTD.]]

[[Category:Game Files]]

User talk:Bomb Bloke:Firing Accuracy

2011-12-08T16:20:06Z

Kyrub: /* Rated Accuracy Vs Angle Range */

{{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)
::: I found this in the code. It uses some sort of '''"divergence factor"''' (I am unsure of its real fonction).

::::[[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) Succesful. '''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)

: 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]]

User talk:Bomb Bloke:Firing Accuracy

2011-12-08T16:17:54Z

Kyrub:

{{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)
::: I found this in the code. It uses some sort of '''"divergence factor"''' (I am unsure of its real fonction). [[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) Succesful. '''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)

: 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]]

Talk:Known Bugs

2011-05-11T09:30:49Z

Kyrub: /* Bugs vs Exploits */

= Classification etc =

== Bugs vs Exploits ==

Could someone comment please on the distinction between a bug and an exploit, and where to put each one? I would guess that a bug is something that undesirable and an exploit "might be" desirable, if you want to cheat. But what about exploits that happen by accident, or bugs that need to be forced to happen?

I was going to add the Research Rollover bug to the Exploits sections, but they seem to all be under construction. What's the agreed approach?

[[User:Spike|Spike]] 04:16, 15 March 2008 (PDT)

* i think that an exploit is somthing you can trigger and gain an advantage from. a bug may or may not have a known trigger, and does not give an advantage if it does.
: All exploits are bugs, either in implementation or design. When using a bug to gain advantages that bug is used as an exploit (you are exploiting the bug). [[User:FrederikHertzum|FrederikHertzum]] 13:39, 10 May 2011 (EDT)

:: IMHO, Laser Pistols Gifts to train reactions is an exploit, but it does not involve any bugs. It merely exploits the fact that laser pistols will not penetrate the front armor of Flying Suits. [[User:Jasonred|Jasonred]] 16:31, 10 May 2011 (EDT)

::: I guess the point is to differentiate if it's a bug that's being exploited to your advantage, or it it's something confined within the game mechanics that you are exploiting to your advantage (even if using it as intended). -[[User:NKF|NKF]] 02:31, 11 May 2011 (EDT)

:::: Another definition: An exploit is
::::: a) a move allowed by game interface
::::: b) that sidesteps another part of the game mechanics
::::: c) and creates inadequate advantage for the moving player in the process.
::::: An exploit is not a bug, but it can be connected with a bug, if the latter allows a move mentioned in a). Most obvious exploits render whole parts of game mechanics obsolete (see b) above), because they are always more advantageous. In games that feature equal terms for AI and the player, an exploit can be discerned simply by the fact that AI does not use it (sadly this is not true in X-COM). Clear exploit in X-COM: Transfer soldiers = no monthly payment. Suspect exploits: grenade layout. Most probably not an exploit: Sniping (although the inequality with AI is suspect). Clearly not an exploit: dropping weapons to prevent Psi mass murder (this one is made exploitable by the AI unable to pick up weapons, but is not an exploit per se).--[[User:Kyrub|kyrub]] 05:30, 11 May 2011 (EDT)

== Bugs vs Limits ==

''(Discussion continued from [[Talk:Known Bugs#Soldier Recruiting Bugs Tested|Soldier Recruiting Bugs Tested]])''

The "Soldier Recruiting Limit" is not a bug, it is a limitation of the game. Therefore, this should be removed from the page. If we want it somewhere else (like a new page such as [[Game Limitations]]), that would be appropriate. --[[User:Zombie|Zombie]] 01:42, 9 November 2008 (CST)

::Not sure that's necessarily the best idea, Zombie, since many of the entries on the Known Bugs article(as well as some entries on the Exploits pages) are limitations of the game engine. On just a brief glance through, the following caught my eye as engine limitations: Manufacturing limit, Storage limit, Purchase limit, 80-item limit, Proximity Grenade limit, Large units not waking up from stun, Interception last shot bug, Alien UFL radar blitz-through bug(Passing through the detection range of a radar before the detection check comes up), Free manufacturing, free wages, UFO Redux, point-scoring with Ctrl-C, permanent MC of chryssalids, Zombie-MC resurrection of agents, alien inventory exploits, anything involved with bad collision detection, extinguishing fire with a Smoke Grenade, and even your personal favorite, denying the aliens access to their own spawn points. So in conclusion, maybe it should just be left as it is; conversely, all of these entries could be kept where they are and also on a Game Limitations page, or we could leave the headers there and link them over to the appropriate topics on Game Limitations. What do you think? [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:21, 9 November 2008 (CST)

: I agree with AQ (great list of examples by the way - and the Smoke/Fire limit would be another). Many, if not most, of the bugs are "Limitations" but they are logically inconsistent and not what a player would expect to happen: they are imposed by (at best) memory limitations or (at worst) design/programming oversights. I think the easiest thing to do would be to change the title of the page to Known Bugs and Limitations, or put an explanatory note at the beginning of the section to explain that "Bugs" is taken to included "Limitations". [[User:Spike|Spike]] 13:16, 9 November 2008 (CST)

By the strictest sense of meaning, a "bug" is a mistake or error on the programmers part. Limitations imposed by design or memory are not the same creature as the people involved were consciously aware of the decision. I suppose that to the normal player, any type of behavior which is unexpected/unwanted is automatically dumped in the bug category because to them there is no difference. To those of us who study the game files however, the two are unequivalent. Programming oversights, yes, those are bugs.

Some of those limitations AQ mentions are (to me at least) bugs: free manufacturing, free wages, permanent MC of Cryssies (or actually any alien for that matter), Zombie resurrections and collision detection. Large aliens not waking up from stun is again, a bug. The programmers obviously had some issues when dealing with large units in general and never quite got it right. They made some progress in TFTD by trying to fix mind controlling each section of a large unit, but royally screwed it up by selecting the next 3 entries in UNITPOS.DAT no matter what they pointed to.

Perhaps it's just my background in logic which makes me want to push for a separate category for limitations. Then again, as long as everything is listed somewhere I'm happy. --[[User:Zombie|Zombie]] 22:06, 9 November 2008 (CST)

: Actually, taking a look through the page as a whole there are various other Limits described, and the distinction between Bugs and Limits is made quite rigorously throughout - not just in the Soldier Limits and Bugs section, where the Soldier Recruiting Limit is referred to as a Limit whereas other bugs (such as paying salaries for soldiers you can't recruit) are referred to as Bugs. So we maybe just need to rename the pages "Bugs and Limits" and add an explanatory note on the distinction. From a user point of view, rather than a programmer point of view, a bug is an unexpected (inconsistent or illogical) behaviour, so for that reason I think it makes sense to keep them on the same page but try to ensure they are all correctly classified as Bug or Limit.

: By the way, it could be hard to absolutely distinguish Bugs from Limits as I suspect there are going to be some grey areas where you would have to second-guess the intentions and decisions of the coders to know for sure if something was a designed-in Limit, or just an oversight (Bug). [[User:Spike|Spike]] 06:50, 10 November 2008 (CST)

::If we distinguish in this manner, I suggest the definition of "Limit" should be, "Something imposed by the game files or engine as a limitation, most likely in context to the capabilites of the then-current personal computer." More succinctly, anything that was done to allow the game to run acceptably on what was then a PC. This would include both the Soldier and 80-Item limits, the spawn limit(40 units per side), Smoke/Fire limit, and some of the others listed. (The Purchase limit was probably more of a convienence for the programmers than anything, but it is clearly an intended feature.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:11, 10 November 2008 (CST)

: I would add to this that sometimes a Limit may be imposed as a game design / gameplay decision, rather than in order to conserve a constrained resource in the platform (=PC). Also, I would suggest that ''intended'' Limits are Limits, but ''unintended'' consequences of Limits are Bugs. Obviously, making this distinction involves some guesswork. But I would guess that while the limit on total smoke/fire hexes was an intended Limit (to conserve PC resources), the ability to put out fires with smoke grenades and disperse smoke with IC rounds is probably an unintended consequence of the Limit, and so should probably be considered a Bug. Similarly, Base Defence spawn points are probably an intended limit, but the ability to flood spawn points is an unintended consequence of this, and thus a Bug (and an Exploit). (Spawn points should have been shared out 50/50, not humans-first). [[User:Spike|Spike]] 12:07, 11 November 2008 (CST)

::The limit on Soldier and Interception craft were probably more of a limit imposed because they capped the file and figured that X-COM wouldn't ever need more than 40 interception craft or 250 soldiers. (And I've never needed that many, case in point.)

::As for spawns, its actually difficult to take advantage of it in any reasonably established base. X-COM can spawn up to 40 soldiers in a base defense mission(tanks count as 4 soldiers), as a limit of LOC.DAT. Aliens have the same limit. So in order to take advantage of the bug, the base needs 40 or less spawns total. The Access Lift has 8 spawn points, General Stores(weapon-handling) has 11, Living Quarters has 8 more. This is 27 Spawns just getting soldiers in a base and armed. (Although the General Stores can be cut out if you perform the bug properly). Large Radar and HWD have 6 spawns(Small Radar has 2), and Hangar has 15. So overall, the "Spawn prevention" can be hard to take advantage of with all but the smallest bases. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:48, 11 November 2008 (CST)

Just to clarify, X-COM interception craft are not capped at 40 ships. LOC.DAT has a cap of 50 "things" on the geoscape screen at a time. This is shared between X-COM bases, X-COM ships, alien bases, seen or unseen UFO's, terror sites, crash sites, landing sites and waypoints. In a perfect game world with little alien activity and normally constructed bases, the max number of X-COM craft possible is 44: 5 bases with 8 hangars each plus one base with 4 hangars (or any combination thereof). If you illegally modify your base layout with an editor to get rid of the access lift, the max can be increased to 45 ships (9 hangars in 5 bases). Once clogged, all alien activity will cease.

The base defense limit of 40 units exists because of UNITPOS.DAT which has a cap of 80 entries total (tanks occupy 4 entries in this file). Auto-win missions in a base defense mission by clogging all the spawn points with X-COM units isn't as tough as it sounds, especially if your base is small or doesn't contain hangars. The main thing is getting your full quota of 40 units to spawn (meaning you should try not to have any tanks as they count as 4 units but only occupy one spawn point). This limits the base size to something like 5-6 modules depending on what you build. Still, even having more than 6 modules isn't bad as it forces aliens to spawn intermingled between your troops. With 40 armed guys staring in every direction, you can get positions of all the aliens in the first round and possibly even kill them all (depends on weapons and alien race of course). --[[User:Zombie|Zombie]] 20:12, 11 November 2008 (CST)

: I would say that Limits are the CAUSE of bugs... also, I feel that fire/smoke limit can be called a bug, because a player normally has no way to tell this, other than observation. Whereas the game DIRECTLY and CLEARLY informs you whenever you hit the 80 item or 250 soldier limits, which is more fair. [[User:Jasonred|Jasonred]] 15:22, 23 March 2009 (EDT)

= Specific Bug Discussions =

== Misc Technical Bug ? ==

''(The context of this discussion seems to have been lost)''

This is a technical bug that doesn't happen to everyone and one this article wasn't really meant to chronical - but we won't turn away helping a fellow player if it can't be helped. It's just that there are so many random crash points in this game that it would take far too long to find them all or come up with solutions for them.

Certainly, the transfer crash can happen to some players, but it's not one that can be reproduced easily. It's just like the random crash that some players get when they research a floater medic. It crashes the game for some of us, but others don't seem to notice it at all.

It really depends on your hardware and OS setup, whether or not your copy of the game is damaged or your savegame is damaged, etc.

Does it happen in all games or just this one savegame?

- [[User:NKF|NKF]]

-----

== "Invisible Muton" bug ==

Upon shooting repeatedly a Muton, it sometimes plays its "death" animation without sound (as if falling unconscious) and it is no longer displayed in the screen, while remaining visible to my soldiers (I can center the screen and the cursor appears yellow over them). Under this state, they cannot be targeted by Stun Rods. They may play their death animation anytime they get shot, until they truly die, when they emit their characteristic sound and leave a corpse (along with any items carried).

I'm quite fond of laser weapons, maybe this happens more often with those.

Also, though I remember experiencing this quite often fighting Mutons, it may happen to any other high health race.--[[User:Trotsky|Trotsky]] 02:59, 2 July 2006 (PDT)

-----

Never seen that one myself. Another "unpatched game" thing maybe?

There's a (very rare) bug that allows your soldiers to live if they become stunned by an explosion that happens to kill them. Sometimes the game will register their death, and THEN register that they've been stunned. In every case I've seen this happen, however, the unit will have such a low amount of health that a single fatal wound will render it dead (again) on the next turn. I have a vague memory that other players may have been able to get a medkit to the scene on time...

I dunno if that's related to your issue at all (I doubt it, but... meh). I'd advise using a Mind Probe on the alien the next time it happens so you can check the aliens stun/health levels.

- [[User:Bomb_Bloke|Bomb Bloke]]

----

I'm pretty sure I've seen this with Mutons. Possibly Chrysallids as well, another high health, high armor creature. They were still readily killed by shooting the place they are. Good thought on the MP, BB

---[[User:MikeTheRed|MikeTheRed]] 08:51, 2 July 2006 (PDT)

----

I've been known to have a dying muton(in fire) to spin around and then switch to the female civilian death animation. With the scream and everything. Even got a civilian death registered at the end of the mission. And this didn't just happen once, but on another separate occasion.

Hmm. shape-shifting reptilians in the game! LOL! Happens alot [[User:EsTeR|EsTeR]]

Unusually enough, I once had a sectopod die and then drop a tank corpse. I was using the Lightning at the time for my troop carrier, so you can imagine my surprise.

Then there was one occasion where a floater dropped a snakeman corpse. Let's not even get into the sort of things the aliens like to stuff themselves with.

Your invisible alien bug is quite common, although there appears to be many causes for it. I think one involves a full object table when it comes to invisible aliens in bases. But it can also happen in ordinary missions as well. I'm guessing the game may have tried to do something in the wrong order, and sprite information for the unit may have been lost or corrupted along the way.

Having had an experience where all the chryssalids become invisible in one base defence mission was quite a shocker. I fixed this by saving the game, quitting and then restarting the game. If you ever get an invisible alien again, try this and see if it helps. If it doesn't, well, just keep a careful watch on your map and any alerts that pop up as you play.

There's a similar but less severe bug where a dead alien will still leave its centre-on-unit alert button, but this goes away shortly after you move or turn.

- [[User:NKF|NKF]]

----

That last bug happens when exploding Cyberdiscs kill nearby Sectoids, doesn't it?--[[User:Trotsky|Trotsky]] 23:56, 2 July 2006 (PDT)

----

This is a pretty easy one. I guess this bug occured on UFO recovery on a battleship, an alien base assault or a base defense mission? As soon as there are too many items on the map, the game saves some item slots for the equipment to be displayed (since it is more valuable and more important to research). This would also make stun weapons lethal if the stunned aliens would vanish. therefore the game has a failsafe if an alien is stunned (or badly wounded and becoming uncontious). The downed alien's stun level is set exactly on its left health points therefore resurrecting it instantly. This cycle is broken when the alien is finally killed. This means if you want to stun an alien in such a situation you have to destroy some items first.

- by tequilachef (April 4th 2007)

== Vanishing snakemen ==

I've known snakemen to become invisible when standing on a hay bale. On the first occassion I had a poor tank getting shot while spending numerous turns looking for it. On the second occasion I had an alien under Psi-control, left it on the hay bale, and couldn't find it next turn. - Egor

---

This is not limited to snakemen. Hay bale block visibility quite much when a unit is standing on it. Two possible solutions:
- Destroy the hay before entering
- Shoot at the hay. If it is destroyed any unit on it will become visible (as long as no other bales are blocking the line of sight). You might also hit the enemy directly.

I Dnt know if the aliens are affected by this diminished sight, too. My guess would be no.

- By tequilachef (April 4th, 2007)

== Blaster Bomb Bug ==

I'm currently playing through X-com UFO Defense, I have the collectors edition version. I'm in the process of trying to catch a live alien commander and the blaster bomb bug is making this very difficult. If i remember correctly a commander is always in the command center of the the alien bases. The problem is anytime i get close there is always a dude with a blaster launcher up there that tries to kill my troops. When they try to fire it down at me the bug kicks in and they blow up the whole command room and all the aliens in it because they can't figure out how to get the blaster bomb down the grav lift thing in there. This is making it very dificult to actually catch a live commander. Anyone have any ideas for tactics or anything to breach that room without the aliens trying to fire a blaster launcher up there? - eL Hector

: I can suggest two possible solutions. The first is to wait outside the command room for the alien to move closer to you. If it comes out of the room or if you know it has moved down the lift, you then burst in and stand right next to it to stop it from firing the blaster. This is risky because there could very well be a heavy plasma toting alien in there. The other is to use a small launcher and launch it up at the ceiling near where you think the alien with the blaster is standing. -[[User:NKF|NKF]]

== Disappearing Ammunition ==

I have observed that problem with X-COM 1.2, modded with XCOMUTIL. My stun bombs and heavy rocket missiles, along with clips for the auto cannon went missing.
[[User:Vagabond|Vagabond]]

------

Just run a test using my 1.4 DOS version with XComUtil but my stun bombs didn't disappear: 30 + 1 back in the base they came from, same number after I went tactical and I dusted-off immediately. Are you running XComUtil with Runxcom.bat or did you simply run Xcusetup?

[[User:Hobbes|Hobbes]] 22:12, 22 February 2007 (PST)

:Is it a case of hitting the 80-item limit?--[[User:Ethereal Cereal|Ethereal Cereal]] 12:28, 23 February 2007 (PST)

------
With runxcomw.bat, as everytime. Apologies, I retested and it seems like I was mistakened, but I could have sworn that I lost them dang stunbombs. Had to manufacture some. I will test some more, using four heavy weapons and seeing whether their ammunition disappears at all. Thanks. [[User:Vagabond|Vagabond]]

==MC at end = MIA?==

I am sure I have seen this again recently, where I won a mission with no casualties (I thought), but the last thing I killed was a Commander that had been chain MC'ing a psi-attack-magnet trooper, and that trooper was listed as MIA at the end (presumably because he was on the enemy side at the end of combat). Is this a bug, or is there another way to get MIA's on a completed mission that I might have missed?

Since then I have been waiting for the leaders to panic at the end before killing them (or waiting for a rare resist), so I can safely exit, but am I being overcautious?

--[[User:Sfnhltb|Sfnhltb]] 13:45, 27 February 2007 (PST)

If the trooper was mind controlled on the turn you killed the last alien it will be listed as MIA. No bug there :)

[[User:Hobbes|Hobbes]] 18:16, 1 March 2007 (PST)

Huh, why would that happen - your soldier should recover the very next round, why would he go MIA?

--[[User:Sfnhltb|Sfnhltb]] 18:20, 1 March 2007 (PST)

Doesn't make sense to me as well but that's how the game works.

[[User:Hobbes|Hobbes]] 15:05, 2 March 2007 (PST)

----

It seems that regaining control of units under enemy mind control works different for alien and human players. My guess: aliens under human MC are reverted to alien control AFTER THE ALIEN AND BEFORE THE HUMAN TURN while human units under alien control are reverted RIGHT AT THE BEGINNING OF THE HUMAN TURN. This explains three different phenomenons:

- The discussed MIA "bug" (he unit would be returned in the next human turn, but since it never starts it is lost. The mission is still won since no unit with a "genuine alien" marking is left)

- The fact that a mission is lost when the last human falls under MC while it is not won when this happens to the last standing alien (the aliens get their unit back before their turn starts and therefore have a unit left to pass the "anyone alive?" check, the humans would have no unit left to start a turn with. They WOULD have as soon as the turn starts, but no unit left before turn means bust)

- The fact that aliens still can see all an MCed human saw at the end of the human turn that follows the MC while this is not vice versa (The MCed human can give information to the alien side before reverted while an MCed alien is reverted too early). The result is that aliens can control a human indefinitely without having any alien seeing him until the MC is disrupted for one turn.

All confused? Then I did a good job! No seriously, this must be the explanation, I couldn't think of any other way.

- By tequilachef (April 4th, 2007)

: You're absolutely correct on the first two points. It's a sequence issue - you never get round to recovering the unit before the new turn starts, so you end without any units whatsoever. Makes senses too since the aliens would continue to continue to mind control that same unit over and over indefinitely.

: The third point however: The aliens don't need to know the location of the last MC'd unit. They know the location of all your troops whether they've seen them or not from the very start. They appear to give you a few turns of grace where they won't attack you outright (unless, from my observation, all your soldiers are incredibly weak). This is evident because all of the aliens will eventually make their way towards the nearest soldier even though their movement pattern may seem semi-random. Also, they know where you are because they can initiate psionic attacks without having seen any of your troops. They generally go after the weakest troops first.

: Just to add a semi-related point, but from the alien's perspective. If an MC'd alien unit is in the exits when you abort the mission, this alien is not recovered and in fact simply vanishes. Any equipment it was carrying is recovered, unknown artefacts or otherwise. You could possibly think of this as their version of MIA. However, the aliens differ ever so slightly in that if it's the last alien standing and under temporary mind control by the player, the mission doesn't end straight away. But I guess this is only because the player has everything under control, whereas in the other scenario, the Ai is in control.

: -[[User:NKF|NKF]]

== Crash Site in the atlantic ocean ==

That's right, my game generated a crash site on water. Here are the details:

- Crash Site a bit southeast of the USA (which was infiltrated a few days before by sectoids, resulting base had already been taken out), but certainly not on land.

- UFO: battleship, floater, alien harvest

- Geoscape: 8 X-Com Bases, 1 (known) Alien base, 2 other crash sites, 1 other (known) flying UFO (though almost worldwide decoder coverage), 3 X-Com Crafts out, 1 waypoint

- Date: January 2000

- Most Interesting: The Craft that downed the ship was a recently finished Firestorm (first human-alien hybrid craft I had built, I know this is lame for that date. Limited myself on 25 Scientists to improve the challenge) equipped with twin plasma. I had it built and equipped in Antarctica and then transferred to Europe. This base had no Elerium, a fact that enabled me to use the infinite fuel exploit which was in effect when downing the UFO. My craft was only slightly damaged when doing so. The battleship was the first target assigned to the craft, it came directly from my base.

- When shot down, the UFO was not targetted by any other craft.

- I had not lost or sold a single craft to that point.

- When sending a squad to the crash site the game didn't crash but generated a farm land ground combat terrain.

- I was not able to reproduce the bug from the savegame dated 2 hours before downing the UFO

Well guys, any intelligent guesses? I still have the savegames (before and after downing)! If you want to have a look, write here.

- By tequilachef (April 5th 2007)
----
: Well I'm sure you know about crash sites that are near land can sometimes actually be on water, so I'm going to assume that this site is well far away from any land mass. Could it be a weird entry in GEODATA\WORLD.DAT that has a land mass out in the ocean? Also are you sure the game didn't crash? Sometimes when it does it will load the previous mission (and usually 90% are at farm terrain). Are you sure it generated a new map and not load the last one?
:No real guesses but maybe some starting points to look at. I've probably stated some obvious situations you know about and have accounted for, but it never hurts to double check :D
- [[User:Pi Masta|Pi Masta]] 14:23, 5 April 2007 (PDT)

== Inconsistencies in MCing Cyberdiscs and Sectopods ==

I experienced, that when MCing one quadrant of a large terror unit any action it does only affects this quadrant (especially use of time units). That means, when TUs are up for one part, MC another one and continue firing. This however does not work out when moving the unit while it is not under complete control. The TUs used up by the resulting reaction fire from the rest of the unit is also deducted from the TUs "your" part has left (making it impossible for the controlled parts to return fire). This however only happens under reaction fire, not if "your" part fires on it's own. I don't know if this comes up when uncontrolled parts shoot by themselves in the alien turn, since this is hard to find out.

: That's because large units literally are made up of four separate units. They only share the same set of general stats (in unitref.dat). Unfortunately the 'under mind control flag' is unique to the four units, not the shared stats! So you in effect have multiple units under different control sharing the same stats. So if you move and it results in a reaction from the unit, it will spend the TUs you're using.
: Successful mind control automatically fills up the unit's TUs, so each mind controlled sector gets to move or attack again until there are no more sectors to mind control. Useful way of turning reapers into long range scouts!
: In TFTD, they attempted to fix this bug, but in fact made it much-much worse! The only way to mind control the unit properly is to control the upper left quadrant. Only! Any other quadrant will result in a partial (clockwise) control, and you may gain control of units other than that unit, or may even get into situations where you gain permanent 'partial control' of a large unit you haven't even sited. Wackiness all around!

:- [[User:NKF|NKF]]

== Facility Dismantle Bug ==

Boba: I've never experienced this bug myself in all my games in the Collectors Edition. It may very well vary from computer to computer.

-[[User:NKF|NKF]]
:I, however, have experienced it. I lost an entire month's worth of playtime because I couldn't solve it. [[User:Arrow Quivershaft|Arrow Quivershaft]]

::Anyone, any ideas on why it might vary from PC to PC? -[[User:MikeTheRed|MikeTheRed]]

:::I'd check other factors before blaming a given system. Assuming no mods are being used the most obvious is the order in which you initiated the construction of the modules. Then we've got which one was due to be completed first, and I'm sure there's a few other things to test out. Usually, a player won't cancel in-progress modules on a regular basis, so you wouldn't expect this bug to turn up often. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

:Easy way to reproduce: build 2 General Stores. Now delete the "second one" (see offset 16-39 in [[BASE.DAT]] for the order). Wait for the first one to complete. It'll crash immediately after the "end of construction" dialog. A fix is available [[User:Seb76#Bug_Fixes | here]]. [[User:Seb76|Seb76]] 15:52, 22 July 2008 (PDT)

== Manufacturing Limit Bug ==

Unfortunately, Mike, no you did not get it correct. It is the raw number of hours needed to complete the project, not the projected hours. I discussed this on the X-Com Forums a few months back at the following link: http://www.xcomufo.com/forums/index.php?showtopic=242027760&st=0&#entry164411

I did tests at the time in regard to the accuracy of the data given there, but I've lost the results. I'll quickly redo the tests in the next hour or so. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:00, 8 June 2007 (PDT)

:Tests complete. The breakpoints for every item were exactly where I predicted, regardless of number of engineers assigned. (I ran up a huge queue of items at my dedicated factory base on an old game, and then assigned whatever engineers would fit onto one project at a time, canceling projects as data was confirmed. This is only semi-random, but it serves our purposes.) I did run into a single issue, though. It appears that despite having 5 empty hangars at a (different!) base, the workshop there could not queue up more than 3 of any one craft at a time, thus making this bug impossible to replicate with the Firestorm or Lightning, as you must be producing more than three for the bug to occur. However, it still works with the Avenger. Later, I shall see about constructing a dedicated Hangar base with 7 hangars in order to attempt to replicate the bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:33, 8 June 2007 (PDT)

::Sounds great, Arrow. Why not post a simple example that shows how the problem works. As in, "with 1 Eng and 2 Avengers you might think X, but no, it's Y". And please delete my example. And it's a fine pleasure to meet you! Cool - [[User:MikeTheRed|MikeTheRed]]

:::When you say the usual resources are used by the "lost" resources, that includes cash, right? It sounds like if you're willing to foot the extra bill [[Buying/Selling/Transferring#Manufacturable_Prices|money/component-wise]], this could be used to build Avengers slightly faster then normal.

::: The usual time is 34000 hours. Double that and subtract 65535 and you're left with a paltry 2465 hours. Even a single workshop squad of 10 engineers will pull that off in a little over ten days. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

::::Sadly, this exploit doesn't work, because the high bit is stored SOMEWHERE. I lack a hex reader and have no code reading skills to speak of, so I'm a bit limited here. If you set up a Workshop as you described, the game would take all the time for 2 Avengers, all the resources for the same, but in the end only produce 1 Avenger. Meanwhile, I'll run more tests on the resources thing. I could swear it consumes the resources, but I'll double check.

:::::There is no need to store the high bits if the actual completion condition (assuming adequate money) is "number made is number ordered", which wouldn't reference the hours remaining at all. - [[User:Zaimoni|Zaimoni]] 01:49, 9 Oct 2007 (CDT)

::::Tests done; I was unable to replicate the 'disappearing item' trick,(Which I didn't test for last night) even with Avengers! It appears I was wrong; this still counts as a bug, though, because the wraparound is a problem.

::::Ironic that so much of this discussion centers around Avengers, because that's where I discovered this in the first place! [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:48, 9 June 2007 (PDT)

----

I'm revisiting XCOM and was working on [[Manufacturing Profitability]]... Arrow, can you (or anyone else) say a little bit more on the Known Bugs page about this [[Known_Bugs#Manufacturing_Limit_Bug]]? It's not clear to me exactly what the bug does, except that it understates hours. Is that all?... does it still take the (non-buggy) amount of time, still use all the same resources, still make the same number, etc.? It sounds like it could be a drastic bug - or is it only a very superficial one, a display bug for the hours? It sounds like you're leaning toward this latter.

Also on a semi-related note... I could swear I saw much more detailed info on the [[Known_Bugs#Facility_Maintenance_Costs]] issue... IIRC, the incorrect amount that's charged for maintenance, depends on exactly where a facility is in the base. IOW, different "rows" of the base cost different amounts. Could somebody provide a link there, and/or flesh the bug out better?

Thanks! - [[User:MikeTheRed|MikeTheRed]] 11:22, 8 October 2007 (PDT)

:I've actually seen the bug work both ways, but I've only been able to actually replicate the more superficial version of the bug. So the bug report up is about a superficial bug that drastically understates production time. If you wish to make this clearer, you have my blessings. As well, that 'different charging based on location' is dealt with here: http://ufopaedia.org/index.php?title=Talk:Base_Facilities ; however, the table has been broken with the Wikiupgrade, and I lack sufficient knowledge of HTML table code to fix it. But it should be of use to you. [[User:Arrow Quivershaft|Arrow Quivershaft]] 11:26, 8 October 2007 (PDT)

::Cool, I fixed [[Talk:Base Facilities]] but also re-organized and expanded [[Base Facilities]] so that it includes that bug in detail, as per Talk... this is an important issue that should be up front. I see that there's a separate [[Maintenance costs]] page, but I can't see having something so important (the maintenance bug explanation) all on its own page (which makes for a rather short page) rather than together with all the rest of the base facility info. If others agree (or don't care), I'll move anything remaining on Maintenance Costs to the Base Facilities page, then delete Maintenance Costs and re-route links. And if somebody does care, then please move my new section to Maintenance Costs, and move all the links, etc. Oh also I put in more words on your Manufacturing Limit Bug - how does it look? - [[User:MikeTheRed|MikeTheRed]] 16:37, 8 October 2007 (PDT)

:Looks pretty good, although it'll wrap fully; if you ask for 120000 hours, it won't be displaying 'almost no' time. The way I discovered it was when building two Avengers; I ordered two, paid for two, waited for two...and got one. But as said, haven't managed to repeat it, so until I do, we'll leave it like that. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:00, 8 October 2007 (PDT)

::I just revised and put in your specific example, because it's certainly possible some of us die-hard players will order up more than 1 Avenger at a time - and it's guaranteed it'd be a pain if 1 of them disappeared, laugh. I wasn't sure how concrete you were on that example but now I hear you say, you are sure it happened at least once. - [[User:MikeTheRed|MikeTheRed]] 18:33, 8 October 2007 (PDT)

:I have a question concerning the manufacturing "bug" which eats a craft in production due to wrap-over of the byte. Arrow (or whoever did the test), did you have a large quantity of craft already built at your bases? If so, I think this bug has more to deal with clogging up [[CRAFT.DAT]]. See, that file has a limit of 50 entries. Each craft takes up one record and each base you have built also consumes one spot. 8 bases allows 42 craft to be housed, while 6 bases allow 44. If you try to buy or manufacture craft once the file is full, nothing shows up in the game even if you have hangar space available. --[[User:Zombie|Zombie]] 19:00, 8 October 2007 (PDT)

::Huh, I never knew that. I don't see it listed on the Bugs page... I'll stick it in there. I've never approached that number, but some folks might. - [[User:MikeTheRed|MikeTheRed]] 19:07, 8 October 2007 (PDT)

:I was able to continue building other Avengers after that project, and they appeared correctly, so I do not believe that is the issue. In any event, I have a very bad case of 'archivism' and probably still have the save game and the CRAFT.DAT file around on my system; in fact, I think I was playing it a few days ago. I can see if I can find it and upload it; it created a 'hole' in the Avenger fleet numbers, where Avenger's x and x+2 were built, but x+1 was not. I'll look for it tonight and tomorrow and upload it to the wiki if I find it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:10, 8 October 2007 (PDT) EDIT: I found the file; I have 28 Avengers and 1 Skyranger in my employ. All Avenger numbers EXCEPT #2(Avenger-2) are accounted for, and I have not sacked or lost any Avengers. So this is where the hole and 'eaten' Avenger is. If anyone wants the CRAFT.DAT file from this game, I'd be happy to forward it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:20, 8 October 2007 (PDT)

::Sure, send it my way and I'll take a look at it. (Might as well send me the whole saved game as I may want to look at the other files too). I have tried to recreate this bug by manufacturing 1, 2 and 3 Avengers at a clip but all of them always show up. Don't know what else I could do to get this problem to crop up. --[[User:Zombie|Zombie]] 21:32, 8 October 2007 (PDT)

:File emailed. On the side, I've tried the same thing, and never been able to repeat the bug. It's been months since the first discovery, so I can't recall whether it was the first or the second Avenger that didn't appear. So maybe it was just a fluke. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:57, 8 October 2007 (PDT)

== Unconscious Enemy in Equipment Screen ==

The following happened to me repeatedly over the last few days.

In the last tactical Mission a live alien has been captured. When now beginning an UFO crash recovery mission this type of alien (same race and rank) appears in the equipment screen before the mission starts, meaning I can give it to any of my soldiers.
If I do so I can store the alien in the skyranger for the duration of the mission and, if it gains consciousness, kill or stun it at the end of it. A pile of equipment without a corpse will be in the UFO, indicating that the stunned alien is not some kind of duplicate but instead has been taken from the aliens of this mission. This is supported by the fact that in those missions the maximum number of crew members has not been surpassed.
If I do not do so the Alien will be placed in the crashed UFO. Whether it is unconscious or not I do not know, but the fact that it is completely disarmed when encountered in the battle suggests that it is.

So far it seems the following is necessary for the bug to occur:
# An alien has to be captured alive in the last tactical combat
# It has to be of the same race and rank as one of the aliens in the new tactical combat

So far this only worked...:
# If the new tactical combat was an UFO crash recovery of a medium scout.
# For floaters and mutons
# For soldiers and navigators
# If the alien in the last mission was stunned by normal weapon fire (although I do not think this is important) and not picked up (again, not likely to be important) or destroyed (which would mean it has to be actually captured)

It seems NOT to depend on the following:
# The type of the last mission (were, so far: Ground assault battleship, crash recovery large scout, base defense)
# Which squad or vessel was involved capturing the alien
# Where it is locked up
# If it has been transferred since capture or not

Would be interesting to know:
# What happens if the alien in the inventory screen is the only survivor
# If the alien in the invenory screen is one of the aliens randomly killed in the crash or not (it is likely to be one of the killed aliens, so far the equipment piles were always within the UFO)
# If this is not limited on crashed medium scouts: Does this work with terror units? What about large ones?

Maybe this is related to the proximity grenade bug (transfer of item properties to next tactical combat).

Additionally, in one of those mission a part of the terrain was not generated correctly. It was in farm terrain (The house on the right square, or north east square, in [[Image:Terrain-cult.gif|this pic]]). The outer wall right to the right window of the southern wall (1st Floor) was missing. Directly outside of the hole was a floor tile. I could walk a soldier through the wall, but he fell right through the tile. Dunno if this has to do with the stunned alien bug.

Version is collectors edition (the one from abandonia.com).

----------------

When a mission starts, the GeoScape engine generates the unit and object tables (in MissDat's [[OBPOSREF.DAT]], [[UNIPOS.DAT]], and [[UNIREF.DAT]]) before "shutting down". The Tactical engine then generates the maps, places the aliens on it, and blows up the UFO (if need be). Whether or not map generation and the subsequent events happen before you equip your soldiers I don't yet know.

The test would be to check the aforementioned files to see if they contain an unconcious alien, and/or the body.

Note that you can't see the bodies of large units on the ground (they count as four seperate objects covering four seperate tiles, so allowing the user to pick one up would essentially let you rip them apart).

- [[User:Bomb Bloke|Bomb Bloke]] 06:35, 5 August 2007 (PDT)

----------------

I honestly have no idea of how all those files work. But I still have a savegame in battlescape that is in one of those missions. So if anyone wants to have a look at those files...

I forgot to mention: I reloaded a geoscape savegame shortly before the battle to recreate the bug, but it seems that reloading in geoscape before the buggy battle eliminates the bug. I guess his should narrow down the possible reasons...

--------

Next time it happens, backup the aforementioned files before you start another mission. I'm afraid a savegame wouldn't be of much help.

- [[User:Bomb Bloke|Bomb Bloke]] 00:54, 7 August 2007 (PDT)

== Soldiers moved to outside of combat screen ==

Hi, I've got a DOS version of UFO:EU, and I've encountered a bug in the tactical combat. Sometimes (rarely) a X-COM soldier changes its location on the map on player's turn start and is placed on outside of the map, one tile north from the (north) border of the field. AFAIR the unit is then selectable (you get the flashing highlight when cursor is above), but is stuck outside of the field. Has anybody encountered this bug? It seems to happen randomly, but more frequently during the terror missions and on early turns (so maybe it's caused by high number of player/alien/civilian units?). --[[User:Maquina|Maquina]] 08:16, 3 September 2007 (PDT)

:I've never encountered this bug in CE of UFO. Presuming AFAIR means "As Far As I Recall," what exactly was the soldier doing? Any equipment data, location, or stat info might help us pin it down. Were afflicted soldiers always carrying a specific equipment set or weapon? Where were they on the map before they got moved? Did they get bumped a few spaces, or teleported halfway across the Battlescape? Does it happen more often on a specific difficulty?(Your theory would suggest this would happen most commonly on Superhuman) Against a certain type of alien? Best of all, if you can recreate the situation in a game, save the game and then you could upload the save file to the forums or this wiki, and the rest of us could take a look for ourselves and the code divers could root around for the cause. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:03, 3 September 2007 (PDT)

:: I've had this happen to me several times in UFO and TFTD. I don't know if it's specific to the Dos version or if it can happen in the CE as well. Sometimes the soldier ends up beyond the boundary of the map right at the start of the mission, at other times it happens after you load a game. This game is glitchy, which is the source for so many of its bugs, so your soldier's coordinates are probably getting corrupted to the point where they are -1 on either the X or Y axis of the maps's normal boundaries. For me it's commonly along the top edge of the map. I don't ever recall it happening mid-mission, only at the start or after a load. I cannot faithfully say whether it happened with or without XComutil, but that could be one of the possibly many causes for this. - [[User:NKF|NKF]]

:: I don't play UFO often, so I rely on just several campaigns played. This happens rarely (I've encountered this bug twice in my last campaign with ~80 missions played), but if you haven't seen this happen then it probably doesn't show up in the CE edition. In my experience the soldier is moved always beyond the north/top map border. I think (but I'm not sure) that this affects the first soldier from the team more commonly than others (or maybe even exclusevily?). The equipment/armor carried is probably not relevant, since the units moved this way don't have any special stuff, and this bug shows up on different stages of the gameplay (ie. sometimes when you have ordinary rifles, sometimes when all your units got heavy plasmas and power suits). --[[User:Maquina|Maquina]] 04:12, 4 September 2007 (PDT)

'''MY ramblings have been moved to my discussion page''' [[User:EsTeR|EsTeR]]

==Great Circle Route==

Should we have the Great Circle Route bug noted on this page at all? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 6 October 2007 (PDT)

: what is the great circle route? [[User:Jasonred|Jasonred]] 07:56, 31 March 2009 (EDT)

:: Pick two points on a globe, then hold a thread or string taut at those two points. That practically minimizes the length of the thread/string on the globe. You're now looking at a great circle arc (or route), the shortest distance between two points on a globe. -- [[User:Zaimoni|Zaimoni]] 11:15 March 2009 (CDT)

: Just as a line is the shortest distance between 2 points on a flat plane, a great circle is the shortest distance between 2 points on the surface of a sphere. The bug, by the way, is that aircraft in the game ''don't'' follow this shortest, "great circle" route. [[User:Spike|Spike]] 12:38, 31 March 2009 (EDT)

:: What a grand sounding name, for something so simple, lol. ... I thought you were talking about when you tell your soldiers to go from point A to point B, and for some reason they figure that Zone A and Zone B are really far apart, despite actually being side by side. (I shot a hole through a wall, clicked to walk to the other side, and my idiot soldier walked one big circle... to use the door! And got ambushed and killed by an alien. ... dum dum DUMB DUMB.)
:: Even the more modern games have problems with their pathfinding algorythms. Admittedly, games like Baldur's Gate had to do it in realtime.
:: On a semi-related note, I remember this guy called E-man, he was chasing a guided laser beam that was going to kill his girl, around the world, but he couldn't outrun it since he couldn't break the speed of light, only equal it by changing into a Laser himself. So... inspiration! He turned into a very powerful laser, and made a shortcut THROUGH THE EARTH... the straight line beats the great circle route, lol.
:: Thanks for the reply guys [[User:Jasonred|Jasonred]] 15:56, 31 March 2009 (EDT)

==Bug not listed: Missing soldiers during base defense==

I encountered an interesting bug concerning base defense missions:
My base got attacked while about 30 soldiers and 10 HWPs were present. The usual equipment assignment screen was skipped and the mission started instantly with only the HWPs spawned at the map. Not even a single soldier bothered to show up... *sigh*
Although this turned out to be in my favor (you should have seen the puzzled Ethereals trying to panic my tanks) I´d like to avoid this bug if possible. I was able to reproduce this bug several times and with different bases.
Can anyone explain this bug and/or tell me how to avoid it?

Game version: Collectors edition. - [[User:NewJoker|NewJoker]]

-----

Well, ideally, we need to know what your base's construction was to be sure of this, but I think the most likely circumstance is that the HWPs took up all the spawn points. HWPs have maximum priority for spawning(followed by Soldiers, and then Aliens), so if you have enough of them garrisoning a base, it's entirely possible that soldiers and aliens won't spawn. However, this doesn't explain why the soldiers didn't start stealing the Alien spawn points...in any event, you might want to take the save game file, zip it up, and get ready to email it. I'm sure [[User:Zombie|Zombie]] would be quite interested. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:28, 13 November 2007 (PST)

-----

It's not the spawn points, it's a [[UNITPOS.DAT]] limitation. A maximum of forty records (out of the total of eighty) are allocated for your units, and tanks (which take up four records each) get first pick. Having ten tanks means there's no room left for anything else.

Ditch one HWP and you should see four units take it's place. - [[User:Bomb Bloke|Bomb Bloke]] 16:42, 13 November 2007 (PST)

-----

I´ll try with a decreasing number of tanks and report the results. As I wrote above having only HWPs isn´t too bad dependent on what enemy is attacking. [[User:NewJoker|NewJoker]]

----

This should be mentioned in the [[ExploitsE#Base Defence Mission Spawning Issues]] section. The Bugs/Exploits really need to be sorted and consolidated. - [[User:NinthRank|NinthRank]] 16:57, 13 November 2007 (PST)

-----

The limitation to 40 records seems to be the case; each tank I dumped got replaced by four soldiers.
So this can be used to effectively manage unit combination. Thanks for the quick replies! [[User:NewJoker|NewJoker]]

==Bug not listed: Ufo Gold (Windows Vers. abandonia.com) crashing when plasma defense is finished==

I recordnized this bug a few times now. (with hacked AND unhacked game)
If i place a plasma defense in 7 bases at the same Time and they are finished at the same Time, the game crashes sometimes.
In hacked game, it seems to crash even more when Alien containment is finished, plasma defense, shield defense...etc.
couldnt find it here...greetz

: I somehow doubt the sourcing is the issue. [You may want to fund the next XCOM series game with a Take2 re-release of UFO :)] More generally: the game only reports the construction of a given type of facility once, no matter how many bases it completes at simultaneously. I've only tested this in vivo with three-of-a-kind at once across six bases, however. It does seem reasonable that some sort of counter of undisplayed completions would "overflow" (attaining crash). -- [[User:Zaimoni|Zaimoni]] 10:05, Feb. 28 2008 CST

::I've encountered this bug myself with General Stores, actually, not just Plasma Defense(which I never build). EDIT: Some quick tests seem to show that there's a chance the game will crash any time two base facilities are done at the same time, regardless of whether they're in the same base or not or if they're the same facility.(although it seems to happen MUCH more in the event they're in different bases.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:13, 28 February 2008 (PST)

== Soldier Recruiting Bugs Tested ==

Just to note that I have positively tested and replicated the bugs listed under the new(ish) section [[Known Bugs#Soldier Recruiting Bugs|Soldier Recruiting Bugs]]. [[User:Spike|Spike]] 18:08, 19 March 2008 (PDT)

==Floater Medic Bug==

I have not thus far encountered the Floater Medic Bug; in fact, Floater Medics are often used to fill up my Rogue Gallery with interrogations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:50, 24 April 2008 (PDT)

Strange, it would always occur in my version. I don't remember where I got it from, but I
know it was a download from the internet. Using the XCom Hack v2.5, I viewed the alien in
the Alien Containment edit. I now have Type (race):____, and a Rank: Soldier for the
Floater Medic. It might just be corruption, but I do not have the resources to look into
it. [[User:Muton commander|Muton commander]] 19:24, 12 May 2008 (Pacific Time Zone)

I've never encountered it either. [[User:Magic9mushroom|Magic9mushroom]] 07:47, 23 July 2009 (EDT)

==Strength Overflow==

During one of my games with TFTD I noticed a really annoying thing happen during battles.
As my troops rose up the 'stat.' ladder they got better and better (as you'd expect), until they hit about 50 strentgh and completely lost the ability to throw anything.
Even trying to throw something tiny like a grenade or flare into the adjacent tile resulted in the 'Out of Range' message being displayed.

Anyone come across this before?
This was in TFTD CE.
[[User:Tifi|Tifi]] 07:55, 27 April 2008 (PDT)

:This is fairly well documented. The pathfinding algorithm for throwing objects will balk if anything is in the way of the throw and refuse to allow you to throw. What's happening is that your soldiers have become so strong that their throws are intercepting the 'ceiling' of the Battlescape(the top of L3), and as such the game thinks that the throw is blocked(because in order for the throw to complete, the object would have to be tossed up to the nonexistant L4). There's two ways around this:

:The Normal Way: Try shorter throws, throwing from lower heights, or throwing while kneeling. Beyond that, possibly get some new troops.

:The Sneaky Way: Manually edit the Strength scores of your soldiers in [[SOLDIER.DAT]] so that they're back to a usable strength level. If you set "Initial Strength" (offset 46 decimal or 2E hex) to 0 and "Strength Improvement" (offset 57 decimal or 39 hex) to a value of 50, you can permanently lock the soldiers at 50 strength. (You can lock them higher than that if you so choose, but not lower.

:Other than this, there's no workarounds I can think of offhand. [[User:Arrow Quivershaft|Arrow Quivershaft]] 08:10, 27 April 2008 (PDT)

:: There's normally no problem with the max level of 70 in open settings. However TFTD has a lot of low ceilings such as in the shipping lane missions and colonies, and the lower ceilings impairs your throwing quite a bit. In addition to shorter throws/kneeling, try moving out from under any overhangs if there is one just above you. - [[User:NKF|NKF]] 12:33, 27 April 2008 (PDT)

== Bug not listed: Sticking your head through the ceiling ==
This is something I just discovered: When you step on a small object inside of a building your soldier sticks his/her head through the ceiling and can see what's upstairs. You can even see the soldiers head coming out of the floor and that soldiers can shoot aliens upstairs. When I did this the alien I saw/shot was facing the other way, but I guess you could get shot if the alien was facing you. [[User:RedNifre|RedNifre]] 17:34, 11 May 2008 (PDT)

:That's not listed under "Bugs" because it's covered under "Exploits", right here: [[Exploiting_Collison_Detection#See_Through_A_Ceiling]] [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:26, 11 May 2008 (PDT)

:: I don't know if it was ever covered anywhere, but there's this neat trick that might sound similar to the walk-through-'wall object'-wall trick except that it involves your unit climbing slopes. They'll appear as though they've gone up a level, but are actually not on that level. They only visually appear to be there, but are really still on the bottom level.

:: It happens a lot when walking up the desert or forest slopes. I think the trick involves standing on ground level, and then ordering the unit to 'move' into the hill rather than setting the waypoint while on level 1. The soldier will move up the slope and perhaps stop on the slope or even reach the top of the slope, but will still appear when you're only viewing the ground map layer. The soldier is really still on the ground level, but will have elevation offset.

:: One really interesting way of using this trick is in the mountain region. If you can find a cliff face and a low hill nearby, you can literally have your soldier scale the cliff by standing the soldier on the hill, and then walking towards the cliff. It's ridiculous, but your soldier never quite reaches the top of the cliff tiles, so ends up walking up a slope.

:: On a side note, standing at the top of the ramp of the Skyranger is the same as standing on ground level - you're only offset a bit. This means that smoke on level 1 and the sides of the Skyranger will not provide protection when you're at the top of the ramp.

:: On another related note in relation: In TFTD (doesn't happen a lot in UFO), you might find it difficult to toss grenades onto underwater slopes. To remedy this, raise the level up by one. It might look like you're tossing at air(and you are), but it'll get the grenade where you want it. Odd, but true. I must remember to put this in the grenade explanation section. -[[User:NKF|NKF]] 23:11, 11 May 2008 (PDT)

== Base Defence bug that causes a crash? ==

Does anyone know about a bug in a base defence mission that causes the game to crash? The game keeps crashing on the 4th or 5th alien turn.

:I've encountered that myself, but it should be noted that overall, X-COM is not the most stable game and is prone to crashing often at anytime. The differences between the hardware it was designed for and the hardware we're running it on cannot be helping matters at all; it's really a small miracle it even runs without an emulator in the first place(I've got games from 1999 that will bluescreen my machine instantly). As such, I'm not sure it's worth noting as a bug, since it's a 'game feature'(albeit a detrimental one). In any case, what're you doing letting the aliens attack you anyways? ;) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:33, 18 July 2008 (PDT)

== Sources for a DOS4GW transplant ==

I was specifically thinking of the LucasArts Dark Forces demo, but I half-recall the actual source I used when testing that ~1999 was Id's DOOM. -- [[User:Zaimoni|Zaimoni]] 16:03, 7 August 2008 (CDT)

== Phantom Carried Casualty ==

You are carrying an unconscious soldier in one hand, and the soldier dies of his/her wounds. The dead soldier remains visible on the "left hand / right hand object" battlescape display, but is no longer visible in the inventory display. The problem can be fixed by moving another object into the same hand.

I've seen this bug with UFO Extender by [[User:Seb76|Seb76]] - possibly might be something to do with his manipulation of the inventory screen, rather than a general bug. I believe I've also seen this with other objects that were being carried in the hands, disappearing from the Inventory screen, but I'm not sure. I don't think it's an item limit bug, as XcomUtil shows 40 item slots free. [[User:Spike|Spike]] 08:58, 21 September 2008 (PDT)

== Civilians As Enemies to MC'd Aliens ==

I ran across this issue a few times and just wondered if you guys experienced this. I MC'd a part of a Reaper (I always do the lower left for large aliens) on a Terror Site, then moved it a few squares. It suddenly stopped dead in it's tracks and then the alien spotted indicator increased by 1. When I clicked on the indicator to see where the enemy unit was, it brought me to L2 of the large apartment complex. However, nothing was there. When I sent a Flying-Suited soldier up there to peek in the window (eeek! A peeping tom!) he saw a female civilian standing there. This type of problem has happened numerous times to me so it's not a once-off thing. Maybe it's a LOS issue? Or maybe an alien indicator problem? Or a combination of the two? Don't know, but I'm curious if you guys have seen it. --[[User:Zombie|Zombie]] 23:40, 19 December 2008 (CST)

:There are a lot of major issues with MC'ing 4 square aliens. One of them being that you could accidentally MC an alien far off in the corner of the map, IIRC? Anyhow, maybe you should have tried MC'ing all 4 squares of the reaper and see if that changed things. -[[User:Jasonred|Jasonred]]

The long-range MC of other aliens when Mind-Controlling large aliens is only present in Terror From The Deep, due to a workaround to try and resolve the earlier bugs(and exploits) associated with controlling one square of a large unit at the time. In TFTD, successfully MC'ing part of a Large unit will also grant you control of the next three units in UNITPOS.DAT, in order. If you didn't MC the upper left portion of the large unit(the first UNITPOS entry for any large unit), you can potentially wind up in control of other aliens. So this doesn't apply to UFO. As for Zombie's issue, never seen it. And finally...Jasonred, on Talk pages, please indent your statement with colons so it differentiates from other people's comments, and sign your posts with 4 ~'s, like I will now do. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==Elerium Base Bug==

Jasonred: This bug has long since been known about. Elerium units on the Battlescape can be picked up by shooting away the power source; this one item counts as 50 units, and as such ANY elerium item spawned on any Battlescape counts as 50 Elerium. This issue with your own Elerium spawning as collectable loot in a Base Defense mission only occurs in older DOS versions, and is at the whim of the 80 item limit. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:55, 18 February 2009 (CST)

:Base defense does not seem to follow the 80 item limit in that DOS version. There are a lot of bugs that have long been known about. However this one was not included in the ufopedia for some reason.
:Also, the main thing about this bug is that it does not potentially double your elerium stores. It potentially multiplies them 50 times.
:... First time this happened to me, I was pretty flabbergasted. Here I was being conservative with my limited Elerium, refraining from blowing up UFOs when possible, when I perform a base defense and gain 3000 Elerium from it. Holy spit. -[[User:Jasonred|Jasonred]]

Alright, my error. Thanks for clarifying. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==HWP Fusion Bomb and SWS PWT Displacer Ammo Manufacturing Cost Bug==

At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:55, 15 November 2008 (CST)

:Hmm, in that case maybe it should be treated as a generic game engine issue and not a TFTD specific issue - but I still think it's a design error. Can you think of any logical reason why the SWS/HWP version of the ammo should be more expensive (in cost and in materials) than both the craft ammo and the (more powerful) personal ammo? It makes no logical sense. Hence I think it's a design error. Nothing can be inferred from the fact it's unchanged from XCOM-EU, that doesn't imply any deliberate decision. It could just be the replication of an original error in XCOM-EU. [[User:Spike|Spike]] 11:17, 15 November 2008 (CST)

:: I can think of a logical reason to justify this: X-Com doesn't understand the technology as well as the aliens do (which is obvious, given the length of time each side has known the tech). Handheld Blaster/Blaster Bombs are just a copy of the alien design and therefor relatively cheap and efficient, but that can't be mounted on a turret. So X-Com has to make a new design, and they obviously didn't do that good a job as the aliens would have done. This explains Tank/Plasma being weaker than Heavy Plasma too. (Why is FBL Craft ammo cheaper than the tank ammo though? Maybe X-Com gave up on/simplified the guidance system and made it just a "dumb" cannon shell/torpedo instead which doesn't have multiple waypoints? Or maybe they just did a better job there?). [[User:Cesium|Cesium]] 04:07, 25 November 2009 (EST)

:Whilst we discuss it, I'll park my original text in here:

* ''Displacer/PWT ammo cost bug - at over $100,000 total cost per round, the ammunition for this SWS weapon is far more expensive to manufacture (both in money and rare materials) than the equivalent ammo for the Aquanaut-carried Disruptor Pulse Launcher, or the craft-based Pulse Wave Torpedo, despite being less powerful than either. This would seem to be a design mistake.''

See Also [[Talk:Displacer/PWT]]

:: I don't like the higher cost either, but I think it's a tradeoff of expense and quality for the convenience of portability. Sort of like an MP3 player to the gramophone... or maybe that's not a good comparison. -[[User:NKF|NKF]] 13:43, 15 November 2008 (CST)

A better comparison might be a desktop computer to a laptop. As a general rule, laptops are more expensive, but a similarly priced desktop gives you more power. Desktops are cheaper and offer power, laptops are more expensive and offer portability(though the gap is rapidly narrowing). [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:49, 15 November 2008 (CST)

:I think those are good analogies. But they don't apply in this case. To continue your analogies: We are paying mainframe prices for a clunky desktop that has only laptop processing power, and we're buying a mainframe for desktop prices. The vehicle version ("desktop") - is ''less'' portable and ''less'' powerful than the personal version (DPL = "laptop"), ''less'' capable than the craft version ("mainframe") - and costs ''more'' than either of the others in total cash and in materials. In particular, it makes no sense that the small missiles on the SWS use up ''more'' of both Zrbite and Aqua Plastics than the Craft version. Do we really think it's logical that a tactical battlefield round, less powerful than its man-carried equivalent, takes more explosive and structural material to produce than both the more powerful man-carried version and also more than the air-to-air round that has 60km range and can take down a major alien combat craft? There is a clearly perverse bang-per-buck here, on every measure. My sincere belief is that this was an original mistake in the XCOM-EU engine that got copied into TFTD as well. The craft round should have the higher base price, but the material requirements that are currently assigned to the SWS/HWP round. It's debatable whether the SWS/HWP rounds should be more expensive than the man-carried rounds. But what I don't think is debatable is that is not logical for the SWS/HWP rounds to be more expensive than the craft rounds. It's clearly a mistake. Even in game balance terms, the only thing the HWP/SWS rounds have going for them is conserving "80-Item Limit" space, which I severely doubt was ever a game design consideration since it's just an awkward programming compromise. Any advantage inherent in the HWP/SWS is already reflected in the very high platform cost - there is no need to inflate the ammo costs as well. The bottom line is that a round for a (mini-)tank does not cost more, does not use more materials, than the same type of round for a long range anti-aircraft weapon that has much greater damage capacity and penetrating capacity. [[User:Spike|Spike]] 14:35, 15 November 2008 (CST)

I'm going to add this to the bug list now. [[User:Spike|Spike]] 16:06, 25 February 2009 (CST)

:Still don't think this is a bug though. Just because it's more expensive to manufacture than the hand-held or craft-mounted ammo, it doesn't mean the stats are wrong. Perhaps the programmers wanted to balance the tactical portion of the game a little more by making the ammo cost more for tanks. It doesn't have to be logical to be intended. Now if you had proof which said that the ammo was supposed to cost less but the stats were wrong, then yes, I'd agree. So if you boil it all down it comes to a disparate logic issue, not a bug.--[[User:Zombie|Zombie]] 21:31, 25 February 2009 (CST)

::I have to side with Zombie here. While the ammo may be disproportionately expensive, by the definition used on the rest of the page for bug, it doesn't fit. All the other bugs are errors in program logic or function or routines that are unintentional problems with the game, most of which are not warned of ahead of time. The ammo for the tank costs exactly what is listed and operates entirely as intended, whereas the rest of the bugs are not intended game features. Even if the numbers were entered wrong, that would be a data entry error, not a program bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:28, 26 February 2009 (CST)

:If it was a data entry error, I'd consider that a type of bug... assuming we had proof of the goof so to speak. LOL. --[[User:Zombie|Zombie]] 00:49, 26 February 2009 (CST)

:: It feels too specific an entry to be a data entry error.

:: I'm reminded of the high explosive. I know, I know - it's not an exact parallel to the FBL issue. A High Explosive is practically two grenades. Double weight, double bulk. Slightly above two times the damage. However, it costs five times the price of a standard grenade. Even though you're paying more for not-as-much, I don't think that could be considered a bug. A rip off, yes, but not a bug.

:: Here's a thought: Think about the immediate benefits each of the two controversial ammo types give back to you. Aircraft ammo = activity points. Tank ammo = loot. Yes, I know that aircraft ammo also generate crash sites, but you still have the ground combat to contend with.

:: One other thought: With careful management of your ammo, you'll probably never spend any elerium on the handheld version's ammo. Could it be the handheld that's really at issue here rather than the others? In the end I feel that it doesn't really matter. -[[User:NKF|NKF]] 03:38, 26 February 2009 (CST)

: I'm with Zombie that a data entry error is a bug (we have other examples), but also agree some proof is probably needed. And I agree with NKF that in the scheme of things, it doesn't really matter much. I don't think the HE pack is a good comparison (though the HE pack should be heavier) as it's reasonable to pay disprortionately more to get additional power at the same tech level. The fusion weapons are a case of paying more to actually get ''less'' power. I am not bothered by the handheld vs vehicle balance, not least because the game generally makes handheld weapons better than their vehicle equivalents, so I can accept that as an across-the-board design decision.

: I can also see a game balance argument ''if'' we believe that Fusion Tank ammo is more of an overall game-winning weapon than craft Fusion Bombs. But I'm not sure I agree with that statement. And even if it's true, and there's a game balance argument (in which case it would apply equally to handheld Fusion launchers), it's still illogical. The less powerful, battlefield warhead should not cost massively more in exotic materials than the much more powerful air to air warhead that brings down Battleships. I agree though that just because it's illogical does not prove it's a bug (i.e. unintended). [[User:Spike|Spike]] 07:48, 26 February 2009 (CST)

Ok we more or less seem to be in agreement that this isn't a bug, but it is very confusing/illogical. Maybe we can shift the "bug" text from the article page and roll that into the [[Hovertank/Launcher]] and [[Displacer /P. W. T.]] pages now. Feel free to combine any text from the discussion above if necessary. --[[User:Zombie|Zombie]] 09:22, 26 February 2009 (CST)

: Unless we can ''prove'' it's a data entry error (unlikely), how about calling it an "Anomaly" instead of a bug? [[User:Spike|Spike]] 10:59, 26 February 2009 (CST)

Looks like plain old game imbalance to me.
The way I see it, Hovertank Plasma and Launcher were meant to be stronger. Much much stronger. Let's look at Tank Cannon, Launcher and Laser. The logic is that it's a tank mounted weapon, so the tank can carry a much larger and more powerful version of the same weapon, right?
It's pretty stupid that a Hovertank Plasma is weaker than the Heavy Plasma... you could just mount a Heavy Plasma on a Hovertank and get them exactly equal. In fact, I suspect that the hovertanks were ALSO meant to have more powerful weapons than the man-portable versions.
Unfortunatly, the game designers then realised that this made the hovertanks far too powerful. So... the programmers nerfed the power of the hovertank weapons. BUT they forgot to lower the ammo costs. [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 11:20, 26 February 2009 (CST)

: Well you are opening up a much larger issue there. The Fusion weapons are an anomaly, an inconsistency. But handheld weapons are more powerful than equivalent vehicle weapons across the board, consistently. So that looks like a deliberate design decision, not a mistake. [[User:Spike|Spike]] 17:33, 26 February 2009 (CST)

:: There are two exceptions to the rule: Tank/Cannon: 60AP vs. Heavy Cannon 56AP. Tank/Laser: 110 Laser vs. Heavy Laser: 85 Laser. The hovertank\plasma only differs by a measly 5 (an extra 0 - 10 damage, which means a lot vs. UFO inner hull armour). I guess the trend here was to moderate the area effect tank strengths. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

I'd have to agree with you there Spike. This wasn't a mistake, however odd it may seem. It was a deliberate attempt to try and balance the game. Below is a table I created ages ago for my (now defunct) strategy guide detailing the HWP's and what handheld weapon corresponds to it. When you stick them side-by-side, it really becomes apparent that the programmers were trying to base the HWP weapons off the handheld weapons somewhat. The only thing that doesn't follow a nice and distinct scheme is the damage. That's what is the clincher. --[[User:Zombie|Zombie]] 20:26, 26 February 2009 (CST)
 
<table {{StdCenterTable}} class="sortable">
<tr {{StdDescTable_Heading}}><th align="left" width="150">Tank Type</th><th width="70">DAM</th><th width="80">Snap</th><th width="90">Aimed</th><th width="90">Aimed</th><th width="80">Snap</th><th width="70">DAM</th><th align="right" width="140">Handheld</th></tr>
<tr><th align="left">Tank/Cannon</th><td>60</td><td>60%</td><td>90%</td><td>90%</td><td>60%</td><td>561</td><th align="right">Heavy Cannon</th></tr>
<tr><th align="left">Rocket Launcher</th><td>85</td><td>55%</td><td>115%</td><td>115%</td><td>55%</td><td>87.52</td><th align="right">Rocket Launcher</th></tr>
<tr><th align="left">Laser Cannon</th><td>110</td><td>50%</td><td>85%</td><td>84%</td><td>50%</td><td>85</td><th align="right">Heavy Laser</th></tr>
<tr><th align="left">Hovertank/Plasma</th><td>110</td><td>85%</td><td>100%</td><td>100%</td><td>86%</td><td>80</td><th align="right">Plasma Rifle</th></tr>
<tr><th align="left">Hovertank/Launch</th><td>140</td><td>--%</td><td>120%</td><td>120%</td><td>--%</td><td>200</td><th align="right">Blaster Launcher</th></tr>
</table>
1AP rounds. 
2Average between the Small and Large Rocket.

: Hold up! Tank rounds do 60AP. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

So what's wrong? The table says 60 for the Tank/Cannon and 56 for HC-AP. Those are correct, no? --[[User:Zombie|Zombie]] 23:41, 26 February 2009 (CST)

: Sorry, didn't realise it was two tables side by side (or rather mirrored). Eyes only noticed the left side of the table. -[[User:NKF|NKF]] 23:53, 26 February 2009 (CST)

:: If the Hovertank Launcher did 200 damage, or worse if the Hovertank Launcher did EVEN MORE damage than the Blaster Launcher... that would make them easily the most deadly things on the map. As it is, the hovertank launcher is already pretty overpowered, even with 140 power.

== DOS4GW - What the heck is it? ==

It's been ages since I had to remember this stuff, so those who remember clearer than I do, forgive me if my descriptions aren't accurate. Hopefully the general idea will come across.

Back in ye olde days of computere gamynge - and where there were more E's to go around, memory handling was a tricky beast to handle. Computer memory is divided into several different categories. Conventional, extended and I think expanded. I might be jumbling the terminologies for the last two a bit. Doesn't matter - memory was just cut up into small segments. The two most common memory types to PCs at the time were pretty small but were readily available. The third one - the most expandable (aka the chip with its massive 4 Megs of RAM you just spent your whole month's allowance on!), wasn't as easy to get at.

To get access to the higher memory that was available to the computer, special memory handlers had to be used. Drivers like HIMEM, emm386, etc were used.

DOS4GW is one such handler that lets the game access the computer's available expanded memory. Lots of games that came out at the time use this. Doom, Duke Nukem 3d, Syndicate, Ultima Underworld, X-Com UFO/TFTD, etc. LOTS of games. Any time you ran a game from the dos console and you saw the Dos4GW message flash by briefly it would be assisted by it (well, it stayed on the screen for ages back when processors were slower!).

It took the hassle out of memory handling and let the game access the available memory on the computer as one big flat block of memory to play with.

So what was meant in the article was to simply replace the dos4gw.exe with a more up-to-date version from another game. I think the way to tell its version was just in the message that it displayed. You can just run the dos4gw.exe file in a console window. It'll give an error, but the message it shows will indicate its version. UFO 1.4 uses Dos4gw 1.95, for example.

-[[User:NKF|NKF]] 01:22, 6 March 2009 (CST)
:DOS4GW also switched the processor from 16bit to 32bit mode. [[User:Seb76|Seb76]] 13:58, 6 March 2009 (CST)

== Clipping ==
I have a new bug. Its harmless. I have a savegame (EU CE - modified game) which has a sectoid within another sectoid. In the alien turn, one secturd walked off the roof and dropped down <s>onto</s> into another. (I guess there DNA is indentical afterall, so they 'become one' with the world). If you want the savegame (superhuman edited using UFOloader, UFO Mod v1, xcomed, Khor Chin WeapEdit v0.1) drop me a request on the my page somewhere. [[User:EsTeR|EsTeR]] 01:40, 18 September 2009 (EDT)

: Not something many would encounter, but definitely something that can happen. Units can occupy the same physical space, but the game cannot display them all. It'll only draw one of them. Actually saw this effect happen back in the early days of XComutil when it gained the ability to manually add new aliens into a battlescape. It did this by slotting them into the same spaces occupied by existing aliens. Then the fun would happen when you saw a couple of Mutons suddenly walk out of a sectoid. Not sure how the game determines who gets hurt when struck by a bullet. May very well depend on the order they are stored in the unitpos.dat file.

: There are a couple of ways you can replicate this in-game, but I can only provide theories on how you could do it. Such as shooting the ceiling above you and letting the unit drop through, or moving a tank off a ledge and getting its non-primary segments land directly on top of another unit. By the way, the rear end of tanks get stuck in walls if you attempt to move north or east off any ledges. -[[User:NKF|NKF]] 02:18, 18 September 2009 (EDT)

: Ok, so as long as others know about this, then all is good. I had never seen it and was doing alot of head scratching until I shot the alien.

== Berserk HWP crashes the game ==
In the article page it mentions that aliens which go berserk with their integrated weapons will crash the game. This is only true for Mind Controlled aliens (or units under X-COM control) - alien controlled units which go berserk do not crash the game. I tested an MC'd Celatid just now and it doesn't crash the game either, though it doesn't immediately go berserk - it waits another turn for some odd reason. Someone want to check this to verify my results? --[[User:Zombie|Zombie]] 20:31, 27 December 2009 (EST)

== 80-items limit on CE edition ==

I have the feeling that the 80-items limit does not apply to the CE edition and is instead a 110-items limit (at least during base defence). Can anyone confirm? [[User:Seb76|Seb76]] 16:24, 24 February 2010 (EST)

:I believe this limit was increased for TFTD. Maybe it was also increased for the CE edition of UFO, and only ever applied to the DOS edition of UFO?? [[User:Spike|Spike]] 20:03, 11 March 2010 (EST)

Talk:Known Bugs

2011-05-11T08:55:02Z

Kyrub: /* Bugs vs Exploits */

= Classification etc =

== Bugs vs Exploits ==

Could someone comment please on the distinction between a bug and an exploit, and where to put each one? I would guess that a bug is something that undesirable and an exploit "might be" desirable, if you want to cheat. But what about exploits that happen by accident, or bugs that need to be forced to happen?

I was going to add the Research Rollover bug to the Exploits sections, but they seem to all be under construction. What's the agreed approach?

[[User:Spike|Spike]] 04:16, 15 March 2008 (PDT)

* i think that an exploit is somthing you can trigger and gain an advantage from. a bug may or may not have a known trigger, and does not give an advantage if it does.
: All exploits are bugs, either in implementation or design. When using a bug to gain advantages that bug is used as an exploit (you are exploiting the bug). [[User:FrederikHertzum|FrederikHertzum]] 13:39, 10 May 2011 (EDT)

:: IMHO, Laser Pistols Gifts to train reactions is an exploit, but it does not involve any bugs. It merely exploits the fact that laser pistols will not penetrate the front armor of Flying Suits. [[User:Jasonred|Jasonred]] 16:31, 10 May 2011 (EDT)

::: I guess the point is to differentiate if it's a bug that's being exploited to your advantage, or it it's something confined within the game mechanics that you are exploiting to your advantage (even if using it as intended). -[[User:NKF|NKF]] 02:31, 11 May 2011 (EDT)

:::: Another definition: An exploit is
::::: a) a move allowed by game interface
::::: b) that sidesteps another part of the game mechanics
::::: c) and creates inadequate advantage for the moving player in the process.
::::: An exploit is not a bug, but it can be connected with a bug, if the latter allows a move mentioned in a). Most obvious exploits render whole parts of game mechanics obsolete (see b) above), because they are always more advantageous. In games that feature equal terms for AI and the player, an exploit can be discerned simply by the fact that AI does not use it (sadly this is not true in X-COM). Clear exploit in X-COM: Transfer soldiers = no monthly payment. Suspect exploits: grenade layout. Most probably not an exploit: Sniping (although the inequality with AI is suspect). Clearly not an exploit: dropping weapons to prevent Psi mass murder (this one is made exploitable by the AI unable to pick up weapons, but is not an exploit per se).

== Bugs vs Limits ==

''(Discussion continued from [[Talk:Known Bugs#Soldier Recruiting Bugs Tested|Soldier Recruiting Bugs Tested]])''

The "Soldier Recruiting Limit" is not a bug, it is a limitation of the game. Therefore, this should be removed from the page. If we want it somewhere else (like a new page such as [[Game Limitations]]), that would be appropriate. --[[User:Zombie|Zombie]] 01:42, 9 November 2008 (CST)

::Not sure that's necessarily the best idea, Zombie, since many of the entries on the Known Bugs article(as well as some entries on the Exploits pages) are limitations of the game engine. On just a brief glance through, the following caught my eye as engine limitations: Manufacturing limit, Storage limit, Purchase limit, 80-item limit, Proximity Grenade limit, Large units not waking up from stun, Interception last shot bug, Alien UFL radar blitz-through bug(Passing through the detection range of a radar before the detection check comes up), Free manufacturing, free wages, UFO Redux, point-scoring with Ctrl-C, permanent MC of chryssalids, Zombie-MC resurrection of agents, alien inventory exploits, anything involved with bad collision detection, extinguishing fire with a Smoke Grenade, and even your personal favorite, denying the aliens access to their own spawn points. So in conclusion, maybe it should just be left as it is; conversely, all of these entries could be kept where they are and also on a Game Limitations page, or we could leave the headers there and link them over to the appropriate topics on Game Limitations. What do you think? [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:21, 9 November 2008 (CST)

: I agree with AQ (great list of examples by the way - and the Smoke/Fire limit would be another). Many, if not most, of the bugs are "Limitations" but they are logically inconsistent and not what a player would expect to happen: they are imposed by (at best) memory limitations or (at worst) design/programming oversights. I think the easiest thing to do would be to change the title of the page to Known Bugs and Limitations, or put an explanatory note at the beginning of the section to explain that "Bugs" is taken to included "Limitations". [[User:Spike|Spike]] 13:16, 9 November 2008 (CST)

By the strictest sense of meaning, a "bug" is a mistake or error on the programmers part. Limitations imposed by design or memory are not the same creature as the people involved were consciously aware of the decision. I suppose that to the normal player, any type of behavior which is unexpected/unwanted is automatically dumped in the bug category because to them there is no difference. To those of us who study the game files however, the two are unequivalent. Programming oversights, yes, those are bugs.

Some of those limitations AQ mentions are (to me at least) bugs: free manufacturing, free wages, permanent MC of Cryssies (or actually any alien for that matter), Zombie resurrections and collision detection. Large aliens not waking up from stun is again, a bug. The programmers obviously had some issues when dealing with large units in general and never quite got it right. They made some progress in TFTD by trying to fix mind controlling each section of a large unit, but royally screwed it up by selecting the next 3 entries in UNITPOS.DAT no matter what they pointed to.

Perhaps it's just my background in logic which makes me want to push for a separate category for limitations. Then again, as long as everything is listed somewhere I'm happy. --[[User:Zombie|Zombie]] 22:06, 9 November 2008 (CST)

: Actually, taking a look through the page as a whole there are various other Limits described, and the distinction between Bugs and Limits is made quite rigorously throughout - not just in the Soldier Limits and Bugs section, where the Soldier Recruiting Limit is referred to as a Limit whereas other bugs (such as paying salaries for soldiers you can't recruit) are referred to as Bugs. So we maybe just need to rename the pages "Bugs and Limits" and add an explanatory note on the distinction. From a user point of view, rather than a programmer point of view, a bug is an unexpected (inconsistent or illogical) behaviour, so for that reason I think it makes sense to keep them on the same page but try to ensure they are all correctly classified as Bug or Limit.

: By the way, it could be hard to absolutely distinguish Bugs from Limits as I suspect there are going to be some grey areas where you would have to second-guess the intentions and decisions of the coders to know for sure if something was a designed-in Limit, or just an oversight (Bug). [[User:Spike|Spike]] 06:50, 10 November 2008 (CST)

::If we distinguish in this manner, I suggest the definition of "Limit" should be, "Something imposed by the game files or engine as a limitation, most likely in context to the capabilites of the then-current personal computer." More succinctly, anything that was done to allow the game to run acceptably on what was then a PC. This would include both the Soldier and 80-Item limits, the spawn limit(40 units per side), Smoke/Fire limit, and some of the others listed. (The Purchase limit was probably more of a convienence for the programmers than anything, but it is clearly an intended feature.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:11, 10 November 2008 (CST)

: I would add to this that sometimes a Limit may be imposed as a game design / gameplay decision, rather than in order to conserve a constrained resource in the platform (=PC). Also, I would suggest that ''intended'' Limits are Limits, but ''unintended'' consequences of Limits are Bugs. Obviously, making this distinction involves some guesswork. But I would guess that while the limit on total smoke/fire hexes was an intended Limit (to conserve PC resources), the ability to put out fires with smoke grenades and disperse smoke with IC rounds is probably an unintended consequence of the Limit, and so should probably be considered a Bug. Similarly, Base Defence spawn points are probably an intended limit, but the ability to flood spawn points is an unintended consequence of this, and thus a Bug (and an Exploit). (Spawn points should have been shared out 50/50, not humans-first). [[User:Spike|Spike]] 12:07, 11 November 2008 (CST)

::The limit on Soldier and Interception craft were probably more of a limit imposed because they capped the file and figured that X-COM wouldn't ever need more than 40 interception craft or 250 soldiers. (And I've never needed that many, case in point.)

::As for spawns, its actually difficult to take advantage of it in any reasonably established base. X-COM can spawn up to 40 soldiers in a base defense mission(tanks count as 4 soldiers), as a limit of LOC.DAT. Aliens have the same limit. So in order to take advantage of the bug, the base needs 40 or less spawns total. The Access Lift has 8 spawn points, General Stores(weapon-handling) has 11, Living Quarters has 8 more. This is 27 Spawns just getting soldiers in a base and armed. (Although the General Stores can be cut out if you perform the bug properly). Large Radar and HWD have 6 spawns(Small Radar has 2), and Hangar has 15. So overall, the "Spawn prevention" can be hard to take advantage of with all but the smallest bases. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:48, 11 November 2008 (CST)

Just to clarify, X-COM interception craft are not capped at 40 ships. LOC.DAT has a cap of 50 "things" on the geoscape screen at a time. This is shared between X-COM bases, X-COM ships, alien bases, seen or unseen UFO's, terror sites, crash sites, landing sites and waypoints. In a perfect game world with little alien activity and normally constructed bases, the max number of X-COM craft possible is 44: 5 bases with 8 hangars each plus one base with 4 hangars (or any combination thereof). If you illegally modify your base layout with an editor to get rid of the access lift, the max can be increased to 45 ships (9 hangars in 5 bases). Once clogged, all alien activity will cease.

The base defense limit of 40 units exists because of UNITPOS.DAT which has a cap of 80 entries total (tanks occupy 4 entries in this file). Auto-win missions in a base defense mission by clogging all the spawn points with X-COM units isn't as tough as it sounds, especially if your base is small or doesn't contain hangars. The main thing is getting your full quota of 40 units to spawn (meaning you should try not to have any tanks as they count as 4 units but only occupy one spawn point). This limits the base size to something like 5-6 modules depending on what you build. Still, even having more than 6 modules isn't bad as it forces aliens to spawn intermingled between your troops. With 40 armed guys staring in every direction, you can get positions of all the aliens in the first round and possibly even kill them all (depends on weapons and alien race of course). --[[User:Zombie|Zombie]] 20:12, 11 November 2008 (CST)

: I would say that Limits are the CAUSE of bugs... also, I feel that fire/smoke limit can be called a bug, because a player normally has no way to tell this, other than observation. Whereas the game DIRECTLY and CLEARLY informs you whenever you hit the 80 item or 250 soldier limits, which is more fair. [[User:Jasonred|Jasonred]] 15:22, 23 March 2009 (EDT)

= Specific Bug Discussions =

== Misc Technical Bug ? ==

''(The context of this discussion seems to have been lost)''

This is a technical bug that doesn't happen to everyone and one this article wasn't really meant to chronical - but we won't turn away helping a fellow player if it can't be helped. It's just that there are so many random crash points in this game that it would take far too long to find them all or come up with solutions for them.

Certainly, the transfer crash can happen to some players, but it's not one that can be reproduced easily. It's just like the random crash that some players get when they research a floater medic. It crashes the game for some of us, but others don't seem to notice it at all.

It really depends on your hardware and OS setup, whether or not your copy of the game is damaged or your savegame is damaged, etc.

Does it happen in all games or just this one savegame?

- [[User:NKF|NKF]]

-----

== "Invisible Muton" bug ==

Upon shooting repeatedly a Muton, it sometimes plays its "death" animation without sound (as if falling unconscious) and it is no longer displayed in the screen, while remaining visible to my soldiers (I can center the screen and the cursor appears yellow over them). Under this state, they cannot be targeted by Stun Rods. They may play their death animation anytime they get shot, until they truly die, when they emit their characteristic sound and leave a corpse (along with any items carried).

I'm quite fond of laser weapons, maybe this happens more often with those.

Also, though I remember experiencing this quite often fighting Mutons, it may happen to any other high health race.--[[User:Trotsky|Trotsky]] 02:59, 2 July 2006 (PDT)

-----

Never seen that one myself. Another "unpatched game" thing maybe?

There's a (very rare) bug that allows your soldiers to live if they become stunned by an explosion that happens to kill them. Sometimes the game will register their death, and THEN register that they've been stunned. In every case I've seen this happen, however, the unit will have such a low amount of health that a single fatal wound will render it dead (again) on the next turn. I have a vague memory that other players may have been able to get a medkit to the scene on time...

I dunno if that's related to your issue at all (I doubt it, but... meh). I'd advise using a Mind Probe on the alien the next time it happens so you can check the aliens stun/health levels.

- [[User:Bomb_Bloke|Bomb Bloke]]

----

I'm pretty sure I've seen this with Mutons. Possibly Chrysallids as well, another high health, high armor creature. They were still readily killed by shooting the place they are. Good thought on the MP, BB

---[[User:MikeTheRed|MikeTheRed]] 08:51, 2 July 2006 (PDT)

----

I've been known to have a dying muton(in fire) to spin around and then switch to the female civilian death animation. With the scream and everything. Even got a civilian death registered at the end of the mission. And this didn't just happen once, but on another separate occasion.

Hmm. shape-shifting reptilians in the game! LOL! Happens alot [[User:EsTeR|EsTeR]]

Unusually enough, I once had a sectopod die and then drop a tank corpse. I was using the Lightning at the time for my troop carrier, so you can imagine my surprise.

Then there was one occasion where a floater dropped a snakeman corpse. Let's not even get into the sort of things the aliens like to stuff themselves with.

Your invisible alien bug is quite common, although there appears to be many causes for it. I think one involves a full object table when it comes to invisible aliens in bases. But it can also happen in ordinary missions as well. I'm guessing the game may have tried to do something in the wrong order, and sprite information for the unit may have been lost or corrupted along the way.

Having had an experience where all the chryssalids become invisible in one base defence mission was quite a shocker. I fixed this by saving the game, quitting and then restarting the game. If you ever get an invisible alien again, try this and see if it helps. If it doesn't, well, just keep a careful watch on your map and any alerts that pop up as you play.

There's a similar but less severe bug where a dead alien will still leave its centre-on-unit alert button, but this goes away shortly after you move or turn.

- [[User:NKF|NKF]]

----

That last bug happens when exploding Cyberdiscs kill nearby Sectoids, doesn't it?--[[User:Trotsky|Trotsky]] 23:56, 2 July 2006 (PDT)

----

This is a pretty easy one. I guess this bug occured on UFO recovery on a battleship, an alien base assault or a base defense mission? As soon as there are too many items on the map, the game saves some item slots for the equipment to be displayed (since it is more valuable and more important to research). This would also make stun weapons lethal if the stunned aliens would vanish. therefore the game has a failsafe if an alien is stunned (or badly wounded and becoming uncontious). The downed alien's stun level is set exactly on its left health points therefore resurrecting it instantly. This cycle is broken when the alien is finally killed. This means if you want to stun an alien in such a situation you have to destroy some items first.

- by tequilachef (April 4th 2007)

== Vanishing snakemen ==

I've known snakemen to become invisible when standing on a hay bale. On the first occassion I had a poor tank getting shot while spending numerous turns looking for it. On the second occasion I had an alien under Psi-control, left it on the hay bale, and couldn't find it next turn. - Egor

---

This is not limited to snakemen. Hay bale block visibility quite much when a unit is standing on it. Two possible solutions:
- Destroy the hay before entering
- Shoot at the hay. If it is destroyed any unit on it will become visible (as long as no other bales are blocking the line of sight). You might also hit the enemy directly.

I Dnt know if the aliens are affected by this diminished sight, too. My guess would be no.

- By tequilachef (April 4th, 2007)

== Blaster Bomb Bug ==

I'm currently playing through X-com UFO Defense, I have the collectors edition version. I'm in the process of trying to catch a live alien commander and the blaster bomb bug is making this very difficult. If i remember correctly a commander is always in the command center of the the alien bases. The problem is anytime i get close there is always a dude with a blaster launcher up there that tries to kill my troops. When they try to fire it down at me the bug kicks in and they blow up the whole command room and all the aliens in it because they can't figure out how to get the blaster bomb down the grav lift thing in there. This is making it very dificult to actually catch a live commander. Anyone have any ideas for tactics or anything to breach that room without the aliens trying to fire a blaster launcher up there? - eL Hector

: I can suggest two possible solutions. The first is to wait outside the command room for the alien to move closer to you. If it comes out of the room or if you know it has moved down the lift, you then burst in and stand right next to it to stop it from firing the blaster. This is risky because there could very well be a heavy plasma toting alien in there. The other is to use a small launcher and launch it up at the ceiling near where you think the alien with the blaster is standing. -[[User:NKF|NKF]]

== Disappearing Ammunition ==

I have observed that problem with X-COM 1.2, modded with XCOMUTIL. My stun bombs and heavy rocket missiles, along with clips for the auto cannon went missing.
[[User:Vagabond|Vagabond]]

------

Just run a test using my 1.4 DOS version with XComUtil but my stun bombs didn't disappear: 30 + 1 back in the base they came from, same number after I went tactical and I dusted-off immediately. Are you running XComUtil with Runxcom.bat or did you simply run Xcusetup?

[[User:Hobbes|Hobbes]] 22:12, 22 February 2007 (PST)

:Is it a case of hitting the 80-item limit?--[[User:Ethereal Cereal|Ethereal Cereal]] 12:28, 23 February 2007 (PST)

------
With runxcomw.bat, as everytime. Apologies, I retested and it seems like I was mistakened, but I could have sworn that I lost them dang stunbombs. Had to manufacture some. I will test some more, using four heavy weapons and seeing whether their ammunition disappears at all. Thanks. [[User:Vagabond|Vagabond]]

==MC at end = MIA?==

I am sure I have seen this again recently, where I won a mission with no casualties (I thought), but the last thing I killed was a Commander that had been chain MC'ing a psi-attack-magnet trooper, and that trooper was listed as MIA at the end (presumably because he was on the enemy side at the end of combat). Is this a bug, or is there another way to get MIA's on a completed mission that I might have missed?

Since then I have been waiting for the leaders to panic at the end before killing them (or waiting for a rare resist), so I can safely exit, but am I being overcautious?

--[[User:Sfnhltb|Sfnhltb]] 13:45, 27 February 2007 (PST)

If the trooper was mind controlled on the turn you killed the last alien it will be listed as MIA. No bug there :)

[[User:Hobbes|Hobbes]] 18:16, 1 March 2007 (PST)

Huh, why would that happen - your soldier should recover the very next round, why would he go MIA?

--[[User:Sfnhltb|Sfnhltb]] 18:20, 1 March 2007 (PST)

Doesn't make sense to me as well but that's how the game works.

[[User:Hobbes|Hobbes]] 15:05, 2 March 2007 (PST)

----

It seems that regaining control of units under enemy mind control works different for alien and human players. My guess: aliens under human MC are reverted to alien control AFTER THE ALIEN AND BEFORE THE HUMAN TURN while human units under alien control are reverted RIGHT AT THE BEGINNING OF THE HUMAN TURN. This explains three different phenomenons:

- The discussed MIA "bug" (he unit would be returned in the next human turn, but since it never starts it is lost. The mission is still won since no unit with a "genuine alien" marking is left)

- The fact that a mission is lost when the last human falls under MC while it is not won when this happens to the last standing alien (the aliens get their unit back before their turn starts and therefore have a unit left to pass the "anyone alive?" check, the humans would have no unit left to start a turn with. They WOULD have as soon as the turn starts, but no unit left before turn means bust)

- The fact that aliens still can see all an MCed human saw at the end of the human turn that follows the MC while this is not vice versa (The MCed human can give information to the alien side before reverted while an MCed alien is reverted too early). The result is that aliens can control a human indefinitely without having any alien seeing him until the MC is disrupted for one turn.

All confused? Then I did a good job! No seriously, this must be the explanation, I couldn't think of any other way.

- By tequilachef (April 4th, 2007)

: You're absolutely correct on the first two points. It's a sequence issue - you never get round to recovering the unit before the new turn starts, so you end without any units whatsoever. Makes senses too since the aliens would continue to continue to mind control that same unit over and over indefinitely.

: The third point however: The aliens don't need to know the location of the last MC'd unit. They know the location of all your troops whether they've seen them or not from the very start. They appear to give you a few turns of grace where they won't attack you outright (unless, from my observation, all your soldiers are incredibly weak). This is evident because all of the aliens will eventually make their way towards the nearest soldier even though their movement pattern may seem semi-random. Also, they know where you are because they can initiate psionic attacks without having seen any of your troops. They generally go after the weakest troops first.

: Just to add a semi-related point, but from the alien's perspective. If an MC'd alien unit is in the exits when you abort the mission, this alien is not recovered and in fact simply vanishes. Any equipment it was carrying is recovered, unknown artefacts or otherwise. You could possibly think of this as their version of MIA. However, the aliens differ ever so slightly in that if it's the last alien standing and under temporary mind control by the player, the mission doesn't end straight away. But I guess this is only because the player has everything under control, whereas in the other scenario, the Ai is in control.

: -[[User:NKF|NKF]]

== Crash Site in the atlantic ocean ==

That's right, my game generated a crash site on water. Here are the details:

- Crash Site a bit southeast of the USA (which was infiltrated a few days before by sectoids, resulting base had already been taken out), but certainly not on land.

- UFO: battleship, floater, alien harvest

- Geoscape: 8 X-Com Bases, 1 (known) Alien base, 2 other crash sites, 1 other (known) flying UFO (though almost worldwide decoder coverage), 3 X-Com Crafts out, 1 waypoint

- Date: January 2000

- Most Interesting: The Craft that downed the ship was a recently finished Firestorm (first human-alien hybrid craft I had built, I know this is lame for that date. Limited myself on 25 Scientists to improve the challenge) equipped with twin plasma. I had it built and equipped in Antarctica and then transferred to Europe. This base had no Elerium, a fact that enabled me to use the infinite fuel exploit which was in effect when downing the UFO. My craft was only slightly damaged when doing so. The battleship was the first target assigned to the craft, it came directly from my base.

- When shot down, the UFO was not targetted by any other craft.

- I had not lost or sold a single craft to that point.

- When sending a squad to the crash site the game didn't crash but generated a farm land ground combat terrain.

- I was not able to reproduce the bug from the savegame dated 2 hours before downing the UFO

Well guys, any intelligent guesses? I still have the savegames (before and after downing)! If you want to have a look, write here.

- By tequilachef (April 5th 2007)
----
: Well I'm sure you know about crash sites that are near land can sometimes actually be on water, so I'm going to assume that this site is well far away from any land mass. Could it be a weird entry in GEODATA\WORLD.DAT that has a land mass out in the ocean? Also are you sure the game didn't crash? Sometimes when it does it will load the previous mission (and usually 90% are at farm terrain). Are you sure it generated a new map and not load the last one?
:No real guesses but maybe some starting points to look at. I've probably stated some obvious situations you know about and have accounted for, but it never hurts to double check :D
- [[User:Pi Masta|Pi Masta]] 14:23, 5 April 2007 (PDT)

== Inconsistencies in MCing Cyberdiscs and Sectopods ==

I experienced, that when MCing one quadrant of a large terror unit any action it does only affects this quadrant (especially use of time units). That means, when TUs are up for one part, MC another one and continue firing. This however does not work out when moving the unit while it is not under complete control. The TUs used up by the resulting reaction fire from the rest of the unit is also deducted from the TUs "your" part has left (making it impossible for the controlled parts to return fire). This however only happens under reaction fire, not if "your" part fires on it's own. I don't know if this comes up when uncontrolled parts shoot by themselves in the alien turn, since this is hard to find out.

: That's because large units literally are made up of four separate units. They only share the same set of general stats (in unitref.dat). Unfortunately the 'under mind control flag' is unique to the four units, not the shared stats! So you in effect have multiple units under different control sharing the same stats. So if you move and it results in a reaction from the unit, it will spend the TUs you're using.
: Successful mind control automatically fills up the unit's TUs, so each mind controlled sector gets to move or attack again until there are no more sectors to mind control. Useful way of turning reapers into long range scouts!
: In TFTD, they attempted to fix this bug, but in fact made it much-much worse! The only way to mind control the unit properly is to control the upper left quadrant. Only! Any other quadrant will result in a partial (clockwise) control, and you may gain control of units other than that unit, or may even get into situations where you gain permanent 'partial control' of a large unit you haven't even sited. Wackiness all around!

:- [[User:NKF|NKF]]

== Facility Dismantle Bug ==

Boba: I've never experienced this bug myself in all my games in the Collectors Edition. It may very well vary from computer to computer.

-[[User:NKF|NKF]]
:I, however, have experienced it. I lost an entire month's worth of playtime because I couldn't solve it. [[User:Arrow Quivershaft|Arrow Quivershaft]]

::Anyone, any ideas on why it might vary from PC to PC? -[[User:MikeTheRed|MikeTheRed]]

:::I'd check other factors before blaming a given system. Assuming no mods are being used the most obvious is the order in which you initiated the construction of the modules. Then we've got which one was due to be completed first, and I'm sure there's a few other things to test out. Usually, a player won't cancel in-progress modules on a regular basis, so you wouldn't expect this bug to turn up often. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

:Easy way to reproduce: build 2 General Stores. Now delete the "second one" (see offset 16-39 in [[BASE.DAT]] for the order). Wait for the first one to complete. It'll crash immediately after the "end of construction" dialog. A fix is available [[User:Seb76#Bug_Fixes | here]]. [[User:Seb76|Seb76]] 15:52, 22 July 2008 (PDT)

== Manufacturing Limit Bug ==

Unfortunately, Mike, no you did not get it correct. It is the raw number of hours needed to complete the project, not the projected hours. I discussed this on the X-Com Forums a few months back at the following link: http://www.xcomufo.com/forums/index.php?showtopic=242027760&st=0&#entry164411

I did tests at the time in regard to the accuracy of the data given there, but I've lost the results. I'll quickly redo the tests in the next hour or so. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:00, 8 June 2007 (PDT)

:Tests complete. The breakpoints for every item were exactly where I predicted, regardless of number of engineers assigned. (I ran up a huge queue of items at my dedicated factory base on an old game, and then assigned whatever engineers would fit onto one project at a time, canceling projects as data was confirmed. This is only semi-random, but it serves our purposes.) I did run into a single issue, though. It appears that despite having 5 empty hangars at a (different!) base, the workshop there could not queue up more than 3 of any one craft at a time, thus making this bug impossible to replicate with the Firestorm or Lightning, as you must be producing more than three for the bug to occur. However, it still works with the Avenger. Later, I shall see about constructing a dedicated Hangar base with 7 hangars in order to attempt to replicate the bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:33, 8 June 2007 (PDT)

::Sounds great, Arrow. Why not post a simple example that shows how the problem works. As in, "with 1 Eng and 2 Avengers you might think X, but no, it's Y". And please delete my example. And it's a fine pleasure to meet you! Cool - [[User:MikeTheRed|MikeTheRed]]

:::When you say the usual resources are used by the "lost" resources, that includes cash, right? It sounds like if you're willing to foot the extra bill [[Buying/Selling/Transferring#Manufacturable_Prices|money/component-wise]], this could be used to build Avengers slightly faster then normal.

::: The usual time is 34000 hours. Double that and subtract 65535 and you're left with a paltry 2465 hours. Even a single workshop squad of 10 engineers will pull that off in a little over ten days. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

::::Sadly, this exploit doesn't work, because the high bit is stored SOMEWHERE. I lack a hex reader and have no code reading skills to speak of, so I'm a bit limited here. If you set up a Workshop as you described, the game would take all the time for 2 Avengers, all the resources for the same, but in the end only produce 1 Avenger. Meanwhile, I'll run more tests on the resources thing. I could swear it consumes the resources, but I'll double check.

:::::There is no need to store the high bits if the actual completion condition (assuming adequate money) is "number made is number ordered", which wouldn't reference the hours remaining at all. - [[User:Zaimoni|Zaimoni]] 01:49, 9 Oct 2007 (CDT)

::::Tests done; I was unable to replicate the 'disappearing item' trick,(Which I didn't test for last night) even with Avengers! It appears I was wrong; this still counts as a bug, though, because the wraparound is a problem.

::::Ironic that so much of this discussion centers around Avengers, because that's where I discovered this in the first place! [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:48, 9 June 2007 (PDT)

----

I'm revisiting XCOM and was working on [[Manufacturing Profitability]]... Arrow, can you (or anyone else) say a little bit more on the Known Bugs page about this [[Known_Bugs#Manufacturing_Limit_Bug]]? It's not clear to me exactly what the bug does, except that it understates hours. Is that all?... does it still take the (non-buggy) amount of time, still use all the same resources, still make the same number, etc.? It sounds like it could be a drastic bug - or is it only a very superficial one, a display bug for the hours? It sounds like you're leaning toward this latter.

Also on a semi-related note... I could swear I saw much more detailed info on the [[Known_Bugs#Facility_Maintenance_Costs]] issue... IIRC, the incorrect amount that's charged for maintenance, depends on exactly where a facility is in the base. IOW, different "rows" of the base cost different amounts. Could somebody provide a link there, and/or flesh the bug out better?

Thanks! - [[User:MikeTheRed|MikeTheRed]] 11:22, 8 October 2007 (PDT)

:I've actually seen the bug work both ways, but I've only been able to actually replicate the more superficial version of the bug. So the bug report up is about a superficial bug that drastically understates production time. If you wish to make this clearer, you have my blessings. As well, that 'different charging based on location' is dealt with here: http://ufopaedia.org/index.php?title=Talk:Base_Facilities ; however, the table has been broken with the Wikiupgrade, and I lack sufficient knowledge of HTML table code to fix it. But it should be of use to you. [[User:Arrow Quivershaft|Arrow Quivershaft]] 11:26, 8 October 2007 (PDT)

::Cool, I fixed [[Talk:Base Facilities]] but also re-organized and expanded [[Base Facilities]] so that it includes that bug in detail, as per Talk... this is an important issue that should be up front. I see that there's a separate [[Maintenance costs]] page, but I can't see having something so important (the maintenance bug explanation) all on its own page (which makes for a rather short page) rather than together with all the rest of the base facility info. If others agree (or don't care), I'll move anything remaining on Maintenance Costs to the Base Facilities page, then delete Maintenance Costs and re-route links. And if somebody does care, then please move my new section to Maintenance Costs, and move all the links, etc. Oh also I put in more words on your Manufacturing Limit Bug - how does it look? - [[User:MikeTheRed|MikeTheRed]] 16:37, 8 October 2007 (PDT)

:Looks pretty good, although it'll wrap fully; if you ask for 120000 hours, it won't be displaying 'almost no' time. The way I discovered it was when building two Avengers; I ordered two, paid for two, waited for two...and got one. But as said, haven't managed to repeat it, so until I do, we'll leave it like that. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:00, 8 October 2007 (PDT)

::I just revised and put in your specific example, because it's certainly possible some of us die-hard players will order up more than 1 Avenger at a time - and it's guaranteed it'd be a pain if 1 of them disappeared, laugh. I wasn't sure how concrete you were on that example but now I hear you say, you are sure it happened at least once. - [[User:MikeTheRed|MikeTheRed]] 18:33, 8 October 2007 (PDT)

:I have a question concerning the manufacturing "bug" which eats a craft in production due to wrap-over of the byte. Arrow (or whoever did the test), did you have a large quantity of craft already built at your bases? If so, I think this bug has more to deal with clogging up [[CRAFT.DAT]]. See, that file has a limit of 50 entries. Each craft takes up one record and each base you have built also consumes one spot. 8 bases allows 42 craft to be housed, while 6 bases allow 44. If you try to buy or manufacture craft once the file is full, nothing shows up in the game even if you have hangar space available. --[[User:Zombie|Zombie]] 19:00, 8 October 2007 (PDT)

::Huh, I never knew that. I don't see it listed on the Bugs page... I'll stick it in there. I've never approached that number, but some folks might. - [[User:MikeTheRed|MikeTheRed]] 19:07, 8 October 2007 (PDT)

:I was able to continue building other Avengers after that project, and they appeared correctly, so I do not believe that is the issue. In any event, I have a very bad case of 'archivism' and probably still have the save game and the CRAFT.DAT file around on my system; in fact, I think I was playing it a few days ago. I can see if I can find it and upload it; it created a 'hole' in the Avenger fleet numbers, where Avenger's x and x+2 were built, but x+1 was not. I'll look for it tonight and tomorrow and upload it to the wiki if I find it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:10, 8 October 2007 (PDT) EDIT: I found the file; I have 28 Avengers and 1 Skyranger in my employ. All Avenger numbers EXCEPT #2(Avenger-2) are accounted for, and I have not sacked or lost any Avengers. So this is where the hole and 'eaten' Avenger is. If anyone wants the CRAFT.DAT file from this game, I'd be happy to forward it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:20, 8 October 2007 (PDT)

::Sure, send it my way and I'll take a look at it. (Might as well send me the whole saved game as I may want to look at the other files too). I have tried to recreate this bug by manufacturing 1, 2 and 3 Avengers at a clip but all of them always show up. Don't know what else I could do to get this problem to crop up. --[[User:Zombie|Zombie]] 21:32, 8 October 2007 (PDT)

:File emailed. On the side, I've tried the same thing, and never been able to repeat the bug. It's been months since the first discovery, so I can't recall whether it was the first or the second Avenger that didn't appear. So maybe it was just a fluke. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:57, 8 October 2007 (PDT)

== Unconscious Enemy in Equipment Screen ==

The following happened to me repeatedly over the last few days.

In the last tactical Mission a live alien has been captured. When now beginning an UFO crash recovery mission this type of alien (same race and rank) appears in the equipment screen before the mission starts, meaning I can give it to any of my soldiers.
If I do so I can store the alien in the skyranger for the duration of the mission and, if it gains consciousness, kill or stun it at the end of it. A pile of equipment without a corpse will be in the UFO, indicating that the stunned alien is not some kind of duplicate but instead has been taken from the aliens of this mission. This is supported by the fact that in those missions the maximum number of crew members has not been surpassed.
If I do not do so the Alien will be placed in the crashed UFO. Whether it is unconscious or not I do not know, but the fact that it is completely disarmed when encountered in the battle suggests that it is.

So far it seems the following is necessary for the bug to occur:
# An alien has to be captured alive in the last tactical combat
# It has to be of the same race and rank as one of the aliens in the new tactical combat

So far this only worked...:
# If the new tactical combat was an UFO crash recovery of a medium scout.
# For floaters and mutons
# For soldiers and navigators
# If the alien in the last mission was stunned by normal weapon fire (although I do not think this is important) and not picked up (again, not likely to be important) or destroyed (which would mean it has to be actually captured)

It seems NOT to depend on the following:
# The type of the last mission (were, so far: Ground assault battleship, crash recovery large scout, base defense)
# Which squad or vessel was involved capturing the alien
# Where it is locked up
# If it has been transferred since capture or not

Would be interesting to know:
# What happens if the alien in the inventory screen is the only survivor
# If the alien in the invenory screen is one of the aliens randomly killed in the crash or not (it is likely to be one of the killed aliens, so far the equipment piles were always within the UFO)
# If this is not limited on crashed medium scouts: Does this work with terror units? What about large ones?

Maybe this is related to the proximity grenade bug (transfer of item properties to next tactical combat).

Additionally, in one of those mission a part of the terrain was not generated correctly. It was in farm terrain (The house on the right square, or north east square, in [[Image:Terrain-cult.gif|this pic]]). The outer wall right to the right window of the southern wall (1st Floor) was missing. Directly outside of the hole was a floor tile. I could walk a soldier through the wall, but he fell right through the tile. Dunno if this has to do with the stunned alien bug.

Version is collectors edition (the one from abandonia.com).

----------------

When a mission starts, the GeoScape engine generates the unit and object tables (in MissDat's [[OBPOSREF.DAT]], [[UNIPOS.DAT]], and [[UNIREF.DAT]]) before "shutting down". The Tactical engine then generates the maps, places the aliens on it, and blows up the UFO (if need be). Whether or not map generation and the subsequent events happen before you equip your soldiers I don't yet know.

The test would be to check the aforementioned files to see if they contain an unconcious alien, and/or the body.

Note that you can't see the bodies of large units on the ground (they count as four seperate objects covering four seperate tiles, so allowing the user to pick one up would essentially let you rip them apart).

- [[User:Bomb Bloke|Bomb Bloke]] 06:35, 5 August 2007 (PDT)

----------------

I honestly have no idea of how all those files work. But I still have a savegame in battlescape that is in one of those missions. So if anyone wants to have a look at those files...

I forgot to mention: I reloaded a geoscape savegame shortly before the battle to recreate the bug, but it seems that reloading in geoscape before the buggy battle eliminates the bug. I guess his should narrow down the possible reasons...

--------

Next time it happens, backup the aforementioned files before you start another mission. I'm afraid a savegame wouldn't be of much help.

- [[User:Bomb Bloke|Bomb Bloke]] 00:54, 7 August 2007 (PDT)

== Soldiers moved to outside of combat screen ==

Hi, I've got a DOS version of UFO:EU, and I've encountered a bug in the tactical combat. Sometimes (rarely) a X-COM soldier changes its location on the map on player's turn start and is placed on outside of the map, one tile north from the (north) border of the field. AFAIR the unit is then selectable (you get the flashing highlight when cursor is above), but is stuck outside of the field. Has anybody encountered this bug? It seems to happen randomly, but more frequently during the terror missions and on early turns (so maybe it's caused by high number of player/alien/civilian units?). --[[User:Maquina|Maquina]] 08:16, 3 September 2007 (PDT)

:I've never encountered this bug in CE of UFO. Presuming AFAIR means "As Far As I Recall," what exactly was the soldier doing? Any equipment data, location, or stat info might help us pin it down. Were afflicted soldiers always carrying a specific equipment set or weapon? Where were they on the map before they got moved? Did they get bumped a few spaces, or teleported halfway across the Battlescape? Does it happen more often on a specific difficulty?(Your theory would suggest this would happen most commonly on Superhuman) Against a certain type of alien? Best of all, if you can recreate the situation in a game, save the game and then you could upload the save file to the forums or this wiki, and the rest of us could take a look for ourselves and the code divers could root around for the cause. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:03, 3 September 2007 (PDT)

:: I've had this happen to me several times in UFO and TFTD. I don't know if it's specific to the Dos version or if it can happen in the CE as well. Sometimes the soldier ends up beyond the boundary of the map right at the start of the mission, at other times it happens after you load a game. This game is glitchy, which is the source for so many of its bugs, so your soldier's coordinates are probably getting corrupted to the point where they are -1 on either the X or Y axis of the maps's normal boundaries. For me it's commonly along the top edge of the map. I don't ever recall it happening mid-mission, only at the start or after a load. I cannot faithfully say whether it happened with or without XComutil, but that could be one of the possibly many causes for this. - [[User:NKF|NKF]]

:: I don't play UFO often, so I rely on just several campaigns played. This happens rarely (I've encountered this bug twice in my last campaign with ~80 missions played), but if you haven't seen this happen then it probably doesn't show up in the CE edition. In my experience the soldier is moved always beyond the north/top map border. I think (but I'm not sure) that this affects the first soldier from the team more commonly than others (or maybe even exclusevily?). The equipment/armor carried is probably not relevant, since the units moved this way don't have any special stuff, and this bug shows up on different stages of the gameplay (ie. sometimes when you have ordinary rifles, sometimes when all your units got heavy plasmas and power suits). --[[User:Maquina|Maquina]] 04:12, 4 September 2007 (PDT)

'''MY ramblings have been moved to my discussion page''' [[User:EsTeR|EsTeR]]

==Great Circle Route==

Should we have the Great Circle Route bug noted on this page at all? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 6 October 2007 (PDT)

: what is the great circle route? [[User:Jasonred|Jasonred]] 07:56, 31 March 2009 (EDT)

:: Pick two points on a globe, then hold a thread or string taut at those two points. That practically minimizes the length of the thread/string on the globe. You're now looking at a great circle arc (or route), the shortest distance between two points on a globe. -- [[User:Zaimoni|Zaimoni]] 11:15 March 2009 (CDT)

: Just as a line is the shortest distance between 2 points on a flat plane, a great circle is the shortest distance between 2 points on the surface of a sphere. The bug, by the way, is that aircraft in the game ''don't'' follow this shortest, "great circle" route. [[User:Spike|Spike]] 12:38, 31 March 2009 (EDT)

:: What a grand sounding name, for something so simple, lol. ... I thought you were talking about when you tell your soldiers to go from point A to point B, and for some reason they figure that Zone A and Zone B are really far apart, despite actually being side by side. (I shot a hole through a wall, clicked to walk to the other side, and my idiot soldier walked one big circle... to use the door! And got ambushed and killed by an alien. ... dum dum DUMB DUMB.)
:: Even the more modern games have problems with their pathfinding algorythms. Admittedly, games like Baldur's Gate had to do it in realtime.
:: On a semi-related note, I remember this guy called E-man, he was chasing a guided laser beam that was going to kill his girl, around the world, but he couldn't outrun it since he couldn't break the speed of light, only equal it by changing into a Laser himself. So... inspiration! He turned into a very powerful laser, and made a shortcut THROUGH THE EARTH... the straight line beats the great circle route, lol.
:: Thanks for the reply guys [[User:Jasonred|Jasonred]] 15:56, 31 March 2009 (EDT)

==Bug not listed: Missing soldiers during base defense==

I encountered an interesting bug concerning base defense missions:
My base got attacked while about 30 soldiers and 10 HWPs were present. The usual equipment assignment screen was skipped and the mission started instantly with only the HWPs spawned at the map. Not even a single soldier bothered to show up... *sigh*
Although this turned out to be in my favor (you should have seen the puzzled Ethereals trying to panic my tanks) I´d like to avoid this bug if possible. I was able to reproduce this bug several times and with different bases.
Can anyone explain this bug and/or tell me how to avoid it?

Game version: Collectors edition. - [[User:NewJoker|NewJoker]]

-----

Well, ideally, we need to know what your base's construction was to be sure of this, but I think the most likely circumstance is that the HWPs took up all the spawn points. HWPs have maximum priority for spawning(followed by Soldiers, and then Aliens), so if you have enough of them garrisoning a base, it's entirely possible that soldiers and aliens won't spawn. However, this doesn't explain why the soldiers didn't start stealing the Alien spawn points...in any event, you might want to take the save game file, zip it up, and get ready to email it. I'm sure [[User:Zombie|Zombie]] would be quite interested. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:28, 13 November 2007 (PST)

-----

It's not the spawn points, it's a [[UNITPOS.DAT]] limitation. A maximum of forty records (out of the total of eighty) are allocated for your units, and tanks (which take up four records each) get first pick. Having ten tanks means there's no room left for anything else.

Ditch one HWP and you should see four units take it's place. - [[User:Bomb Bloke|Bomb Bloke]] 16:42, 13 November 2007 (PST)

-----

I´ll try with a decreasing number of tanks and report the results. As I wrote above having only HWPs isn´t too bad dependent on what enemy is attacking. [[User:NewJoker|NewJoker]]

----

This should be mentioned in the [[ExploitsE#Base Defence Mission Spawning Issues]] section. The Bugs/Exploits really need to be sorted and consolidated. - [[User:NinthRank|NinthRank]] 16:57, 13 November 2007 (PST)

-----

The limitation to 40 records seems to be the case; each tank I dumped got replaced by four soldiers.
So this can be used to effectively manage unit combination. Thanks for the quick replies! [[User:NewJoker|NewJoker]]

==Bug not listed: Ufo Gold (Windows Vers. abandonia.com) crashing when plasma defense is finished==

I recordnized this bug a few times now. (with hacked AND unhacked game)
If i place a plasma defense in 7 bases at the same Time and they are finished at the same Time, the game crashes sometimes.
In hacked game, it seems to crash even more when Alien containment is finished, plasma defense, shield defense...etc.
couldnt find it here...greetz

: I somehow doubt the sourcing is the issue. [You may want to fund the next XCOM series game with a Take2 re-release of UFO :)] More generally: the game only reports the construction of a given type of facility once, no matter how many bases it completes at simultaneously. I've only tested this in vivo with three-of-a-kind at once across six bases, however. It does seem reasonable that some sort of counter of undisplayed completions would "overflow" (attaining crash). -- [[User:Zaimoni|Zaimoni]] 10:05, Feb. 28 2008 CST

::I've encountered this bug myself with General Stores, actually, not just Plasma Defense(which I never build). EDIT: Some quick tests seem to show that there's a chance the game will crash any time two base facilities are done at the same time, regardless of whether they're in the same base or not or if they're the same facility.(although it seems to happen MUCH more in the event they're in different bases.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:13, 28 February 2008 (PST)

== Soldier Recruiting Bugs Tested ==

Just to note that I have positively tested and replicated the bugs listed under the new(ish) section [[Known Bugs#Soldier Recruiting Bugs|Soldier Recruiting Bugs]]. [[User:Spike|Spike]] 18:08, 19 March 2008 (PDT)

==Floater Medic Bug==

I have not thus far encountered the Floater Medic Bug; in fact, Floater Medics are often used to fill up my Rogue Gallery with interrogations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:50, 24 April 2008 (PDT)

Strange, it would always occur in my version. I don't remember where I got it from, but I
know it was a download from the internet. Using the XCom Hack v2.5, I viewed the alien in
the Alien Containment edit. I now have Type (race):____, and a Rank: Soldier for the
Floater Medic. It might just be corruption, but I do not have the resources to look into
it. [[User:Muton commander|Muton commander]] 19:24, 12 May 2008 (Pacific Time Zone)

I've never encountered it either. [[User:Magic9mushroom|Magic9mushroom]] 07:47, 23 July 2009 (EDT)

==Strength Overflow==

During one of my games with TFTD I noticed a really annoying thing happen during battles.
As my troops rose up the 'stat.' ladder they got better and better (as you'd expect), until they hit about 50 strentgh and completely lost the ability to throw anything.
Even trying to throw something tiny like a grenade or flare into the adjacent tile resulted in the 'Out of Range' message being displayed.

Anyone come across this before?
This was in TFTD CE.
[[User:Tifi|Tifi]] 07:55, 27 April 2008 (PDT)

:This is fairly well documented. The pathfinding algorithm for throwing objects will balk if anything is in the way of the throw and refuse to allow you to throw. What's happening is that your soldiers have become so strong that their throws are intercepting the 'ceiling' of the Battlescape(the top of L3), and as such the game thinks that the throw is blocked(because in order for the throw to complete, the object would have to be tossed up to the nonexistant L4). There's two ways around this:

:The Normal Way: Try shorter throws, throwing from lower heights, or throwing while kneeling. Beyond that, possibly get some new troops.

:The Sneaky Way: Manually edit the Strength scores of your soldiers in [[SOLDIER.DAT]] so that they're back to a usable strength level. If you set "Initial Strength" (offset 46 decimal or 2E hex) to 0 and "Strength Improvement" (offset 57 decimal or 39 hex) to a value of 50, you can permanently lock the soldiers at 50 strength. (You can lock them higher than that if you so choose, but not lower.

:Other than this, there's no workarounds I can think of offhand. [[User:Arrow Quivershaft|Arrow Quivershaft]] 08:10, 27 April 2008 (PDT)

:: There's normally no problem with the max level of 70 in open settings. However TFTD has a lot of low ceilings such as in the shipping lane missions and colonies, and the lower ceilings impairs your throwing quite a bit. In addition to shorter throws/kneeling, try moving out from under any overhangs if there is one just above you. - [[User:NKF|NKF]] 12:33, 27 April 2008 (PDT)

== Bug not listed: Sticking your head through the ceiling ==
This is something I just discovered: When you step on a small object inside of a building your soldier sticks his/her head through the ceiling and can see what's upstairs. You can even see the soldiers head coming out of the floor and that soldiers can shoot aliens upstairs. When I did this the alien I saw/shot was facing the other way, but I guess you could get shot if the alien was facing you. [[User:RedNifre|RedNifre]] 17:34, 11 May 2008 (PDT)

:That's not listed under "Bugs" because it's covered under "Exploits", right here: [[Exploiting_Collison_Detection#See_Through_A_Ceiling]] [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:26, 11 May 2008 (PDT)

:: I don't know if it was ever covered anywhere, but there's this neat trick that might sound similar to the walk-through-'wall object'-wall trick except that it involves your unit climbing slopes. They'll appear as though they've gone up a level, but are actually not on that level. They only visually appear to be there, but are really still on the bottom level.

:: It happens a lot when walking up the desert or forest slopes. I think the trick involves standing on ground level, and then ordering the unit to 'move' into the hill rather than setting the waypoint while on level 1. The soldier will move up the slope and perhaps stop on the slope or even reach the top of the slope, but will still appear when you're only viewing the ground map layer. The soldier is really still on the ground level, but will have elevation offset.

:: One really interesting way of using this trick is in the mountain region. If you can find a cliff face and a low hill nearby, you can literally have your soldier scale the cliff by standing the soldier on the hill, and then walking towards the cliff. It's ridiculous, but your soldier never quite reaches the top of the cliff tiles, so ends up walking up a slope.

:: On a side note, standing at the top of the ramp of the Skyranger is the same as standing on ground level - you're only offset a bit. This means that smoke on level 1 and the sides of the Skyranger will not provide protection when you're at the top of the ramp.

:: On another related note in relation: In TFTD (doesn't happen a lot in UFO), you might find it difficult to toss grenades onto underwater slopes. To remedy this, raise the level up by one. It might look like you're tossing at air(and you are), but it'll get the grenade where you want it. Odd, but true. I must remember to put this in the grenade explanation section. -[[User:NKF|NKF]] 23:11, 11 May 2008 (PDT)

== Base Defence bug that causes a crash? ==

Does anyone know about a bug in a base defence mission that causes the game to crash? The game keeps crashing on the 4th or 5th alien turn.

:I've encountered that myself, but it should be noted that overall, X-COM is not the most stable game and is prone to crashing often at anytime. The differences between the hardware it was designed for and the hardware we're running it on cannot be helping matters at all; it's really a small miracle it even runs without an emulator in the first place(I've got games from 1999 that will bluescreen my machine instantly). As such, I'm not sure it's worth noting as a bug, since it's a 'game feature'(albeit a detrimental one). In any case, what're you doing letting the aliens attack you anyways? ;) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:33, 18 July 2008 (PDT)

== Sources for a DOS4GW transplant ==

I was specifically thinking of the LucasArts Dark Forces demo, but I half-recall the actual source I used when testing that ~1999 was Id's DOOM. -- [[User:Zaimoni|Zaimoni]] 16:03, 7 August 2008 (CDT)

== Phantom Carried Casualty ==

You are carrying an unconscious soldier in one hand, and the soldier dies of his/her wounds. The dead soldier remains visible on the "left hand / right hand object" battlescape display, but is no longer visible in the inventory display. The problem can be fixed by moving another object into the same hand.

I've seen this bug with UFO Extender by [[User:Seb76|Seb76]] - possibly might be something to do with his manipulation of the inventory screen, rather than a general bug. I believe I've also seen this with other objects that were being carried in the hands, disappearing from the Inventory screen, but I'm not sure. I don't think it's an item limit bug, as XcomUtil shows 40 item slots free. [[User:Spike|Spike]] 08:58, 21 September 2008 (PDT)

== Civilians As Enemies to MC'd Aliens ==

I ran across this issue a few times and just wondered if you guys experienced this. I MC'd a part of a Reaper (I always do the lower left for large aliens) on a Terror Site, then moved it a few squares. It suddenly stopped dead in it's tracks and then the alien spotted indicator increased by 1. When I clicked on the indicator to see where the enemy unit was, it brought me to L2 of the large apartment complex. However, nothing was there. When I sent a Flying-Suited soldier up there to peek in the window (eeek! A peeping tom!) he saw a female civilian standing there. This type of problem has happened numerous times to me so it's not a once-off thing. Maybe it's a LOS issue? Or maybe an alien indicator problem? Or a combination of the two? Don't know, but I'm curious if you guys have seen it. --[[User:Zombie|Zombie]] 23:40, 19 December 2008 (CST)

:There are a lot of major issues with MC'ing 4 square aliens. One of them being that you could accidentally MC an alien far off in the corner of the map, IIRC? Anyhow, maybe you should have tried MC'ing all 4 squares of the reaper and see if that changed things. -[[User:Jasonred|Jasonred]]

The long-range MC of other aliens when Mind-Controlling large aliens is only present in Terror From The Deep, due to a workaround to try and resolve the earlier bugs(and exploits) associated with controlling one square of a large unit at the time. In TFTD, successfully MC'ing part of a Large unit will also grant you control of the next three units in UNITPOS.DAT, in order. If you didn't MC the upper left portion of the large unit(the first UNITPOS entry for any large unit), you can potentially wind up in control of other aliens. So this doesn't apply to UFO. As for Zombie's issue, never seen it. And finally...Jasonred, on Talk pages, please indent your statement with colons so it differentiates from other people's comments, and sign your posts with 4 ~'s, like I will now do. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==Elerium Base Bug==

Jasonred: This bug has long since been known about. Elerium units on the Battlescape can be picked up by shooting away the power source; this one item counts as 50 units, and as such ANY elerium item spawned on any Battlescape counts as 50 Elerium. This issue with your own Elerium spawning as collectable loot in a Base Defense mission only occurs in older DOS versions, and is at the whim of the 80 item limit. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:55, 18 February 2009 (CST)

:Base defense does not seem to follow the 80 item limit in that DOS version. There are a lot of bugs that have long been known about. However this one was not included in the ufopedia for some reason.
:Also, the main thing about this bug is that it does not potentially double your elerium stores. It potentially multiplies them 50 times.
:... First time this happened to me, I was pretty flabbergasted. Here I was being conservative with my limited Elerium, refraining from blowing up UFOs when possible, when I perform a base defense and gain 3000 Elerium from it. Holy spit. -[[User:Jasonred|Jasonred]]

Alright, my error. Thanks for clarifying. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==HWP Fusion Bomb and SWS PWT Displacer Ammo Manufacturing Cost Bug==

At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:55, 15 November 2008 (CST)

:Hmm, in that case maybe it should be treated as a generic game engine issue and not a TFTD specific issue - but I still think it's a design error. Can you think of any logical reason why the SWS/HWP version of the ammo should be more expensive (in cost and in materials) than both the craft ammo and the (more powerful) personal ammo? It makes no logical sense. Hence I think it's a design error. Nothing can be inferred from the fact it's unchanged from XCOM-EU, that doesn't imply any deliberate decision. It could just be the replication of an original error in XCOM-EU. [[User:Spike|Spike]] 11:17, 15 November 2008 (CST)

:: I can think of a logical reason to justify this: X-Com doesn't understand the technology as well as the aliens do (which is obvious, given the length of time each side has known the tech). Handheld Blaster/Blaster Bombs are just a copy of the alien design and therefor relatively cheap and efficient, but that can't be mounted on a turret. So X-Com has to make a new design, and they obviously didn't do that good a job as the aliens would have done. This explains Tank/Plasma being weaker than Heavy Plasma too. (Why is FBL Craft ammo cheaper than the tank ammo though? Maybe X-Com gave up on/simplified the guidance system and made it just a "dumb" cannon shell/torpedo instead which doesn't have multiple waypoints? Or maybe they just did a better job there?). [[User:Cesium|Cesium]] 04:07, 25 November 2009 (EST)

:Whilst we discuss it, I'll park my original text in here:

* ''Displacer/PWT ammo cost bug - at over $100,000 total cost per round, the ammunition for this SWS weapon is far more expensive to manufacture (both in money and rare materials) than the equivalent ammo for the Aquanaut-carried Disruptor Pulse Launcher, or the craft-based Pulse Wave Torpedo, despite being less powerful than either. This would seem to be a design mistake.''

See Also [[Talk:Displacer/PWT]]

:: I don't like the higher cost either, but I think it's a tradeoff of expense and quality for the convenience of portability. Sort of like an MP3 player to the gramophone... or maybe that's not a good comparison. -[[User:NKF|NKF]] 13:43, 15 November 2008 (CST)

A better comparison might be a desktop computer to a laptop. As a general rule, laptops are more expensive, but a similarly priced desktop gives you more power. Desktops are cheaper and offer power, laptops are more expensive and offer portability(though the gap is rapidly narrowing). [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:49, 15 November 2008 (CST)

:I think those are good analogies. But they don't apply in this case. To continue your analogies: We are paying mainframe prices for a clunky desktop that has only laptop processing power, and we're buying a mainframe for desktop prices. The vehicle version ("desktop") - is ''less'' portable and ''less'' powerful than the personal version (DPL = "laptop"), ''less'' capable than the craft version ("mainframe") - and costs ''more'' than either of the others in total cash and in materials. In particular, it makes no sense that the small missiles on the SWS use up ''more'' of both Zrbite and Aqua Plastics than the Craft version. Do we really think it's logical that a tactical battlefield round, less powerful than its man-carried equivalent, takes more explosive and structural material to produce than both the more powerful man-carried version and also more than the air-to-air round that has 60km range and can take down a major alien combat craft? There is a clearly perverse bang-per-buck here, on every measure. My sincere belief is that this was an original mistake in the XCOM-EU engine that got copied into TFTD as well. The craft round should have the higher base price, but the material requirements that are currently assigned to the SWS/HWP round. It's debatable whether the SWS/HWP rounds should be more expensive than the man-carried rounds. But what I don't think is debatable is that is not logical for the SWS/HWP rounds to be more expensive than the craft rounds. It's clearly a mistake. Even in game balance terms, the only thing the HWP/SWS rounds have going for them is conserving "80-Item Limit" space, which I severely doubt was ever a game design consideration since it's just an awkward programming compromise. Any advantage inherent in the HWP/SWS is already reflected in the very high platform cost - there is no need to inflate the ammo costs as well. The bottom line is that a round for a (mini-)tank does not cost more, does not use more materials, than the same type of round for a long range anti-aircraft weapon that has much greater damage capacity and penetrating capacity. [[User:Spike|Spike]] 14:35, 15 November 2008 (CST)

I'm going to add this to the bug list now. [[User:Spike|Spike]] 16:06, 25 February 2009 (CST)

:Still don't think this is a bug though. Just because it's more expensive to manufacture than the hand-held or craft-mounted ammo, it doesn't mean the stats are wrong. Perhaps the programmers wanted to balance the tactical portion of the game a little more by making the ammo cost more for tanks. It doesn't have to be logical to be intended. Now if you had proof which said that the ammo was supposed to cost less but the stats were wrong, then yes, I'd agree. So if you boil it all down it comes to a disparate logic issue, not a bug.--[[User:Zombie|Zombie]] 21:31, 25 February 2009 (CST)

::I have to side with Zombie here. While the ammo may be disproportionately expensive, by the definition used on the rest of the page for bug, it doesn't fit. All the other bugs are errors in program logic or function or routines that are unintentional problems with the game, most of which are not warned of ahead of time. The ammo for the tank costs exactly what is listed and operates entirely as intended, whereas the rest of the bugs are not intended game features. Even if the numbers were entered wrong, that would be a data entry error, not a program bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:28, 26 February 2009 (CST)

:If it was a data entry error, I'd consider that a type of bug... assuming we had proof of the goof so to speak. LOL. --[[User:Zombie|Zombie]] 00:49, 26 February 2009 (CST)

:: It feels too specific an entry to be a data entry error.

:: I'm reminded of the high explosive. I know, I know - it's not an exact parallel to the FBL issue. A High Explosive is practically two grenades. Double weight, double bulk. Slightly above two times the damage. However, it costs five times the price of a standard grenade. Even though you're paying more for not-as-much, I don't think that could be considered a bug. A rip off, yes, but not a bug.

:: Here's a thought: Think about the immediate benefits each of the two controversial ammo types give back to you. Aircraft ammo = activity points. Tank ammo = loot. Yes, I know that aircraft ammo also generate crash sites, but you still have the ground combat to contend with.

:: One other thought: With careful management of your ammo, you'll probably never spend any elerium on the handheld version's ammo. Could it be the handheld that's really at issue here rather than the others? In the end I feel that it doesn't really matter. -[[User:NKF|NKF]] 03:38, 26 February 2009 (CST)

: I'm with Zombie that a data entry error is a bug (we have other examples), but also agree some proof is probably needed. And I agree with NKF that in the scheme of things, it doesn't really matter much. I don't think the HE pack is a good comparison (though the HE pack should be heavier) as it's reasonable to pay disprortionately more to get additional power at the same tech level. The fusion weapons are a case of paying more to actually get ''less'' power. I am not bothered by the handheld vs vehicle balance, not least because the game generally makes handheld weapons better than their vehicle equivalents, so I can accept that as an across-the-board design decision.

: I can also see a game balance argument ''if'' we believe that Fusion Tank ammo is more of an overall game-winning weapon than craft Fusion Bombs. But I'm not sure I agree with that statement. And even if it's true, and there's a game balance argument (in which case it would apply equally to handheld Fusion launchers), it's still illogical. The less powerful, battlefield warhead should not cost massively more in exotic materials than the much more powerful air to air warhead that brings down Battleships. I agree though that just because it's illogical does not prove it's a bug (i.e. unintended). [[User:Spike|Spike]] 07:48, 26 February 2009 (CST)

Ok we more or less seem to be in agreement that this isn't a bug, but it is very confusing/illogical. Maybe we can shift the "bug" text from the article page and roll that into the [[Hovertank/Launcher]] and [[Displacer /P. W. T.]] pages now. Feel free to combine any text from the discussion above if necessary. --[[User:Zombie|Zombie]] 09:22, 26 February 2009 (CST)

: Unless we can ''prove'' it's a data entry error (unlikely), how about calling it an "Anomaly" instead of a bug? [[User:Spike|Spike]] 10:59, 26 February 2009 (CST)

Looks like plain old game imbalance to me.
The way I see it, Hovertank Plasma and Launcher were meant to be stronger. Much much stronger. Let's look at Tank Cannon, Launcher and Laser. The logic is that it's a tank mounted weapon, so the tank can carry a much larger and more powerful version of the same weapon, right?
It's pretty stupid that a Hovertank Plasma is weaker than the Heavy Plasma... you could just mount a Heavy Plasma on a Hovertank and get them exactly equal. In fact, I suspect that the hovertanks were ALSO meant to have more powerful weapons than the man-portable versions.
Unfortunatly, the game designers then realised that this made the hovertanks far too powerful. So... the programmers nerfed the power of the hovertank weapons. BUT they forgot to lower the ammo costs. [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 11:20, 26 February 2009 (CST)

: Well you are opening up a much larger issue there. The Fusion weapons are an anomaly, an inconsistency. But handheld weapons are more powerful than equivalent vehicle weapons across the board, consistently. So that looks like a deliberate design decision, not a mistake. [[User:Spike|Spike]] 17:33, 26 February 2009 (CST)

:: There are two exceptions to the rule: Tank/Cannon: 60AP vs. Heavy Cannon 56AP. Tank/Laser: 110 Laser vs. Heavy Laser: 85 Laser. The hovertank\plasma only differs by a measly 5 (an extra 0 - 10 damage, which means a lot vs. UFO inner hull armour). I guess the trend here was to moderate the area effect tank strengths. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

I'd have to agree with you there Spike. This wasn't a mistake, however odd it may seem. It was a deliberate attempt to try and balance the game. Below is a table I created ages ago for my (now defunct) strategy guide detailing the HWP's and what handheld weapon corresponds to it. When you stick them side-by-side, it really becomes apparent that the programmers were trying to base the HWP weapons off the handheld weapons somewhat. The only thing that doesn't follow a nice and distinct scheme is the damage. That's what is the clincher. --[[User:Zombie|Zombie]] 20:26, 26 February 2009 (CST)
 
<table {{StdCenterTable}} class="sortable">
<tr {{StdDescTable_Heading}}><th align="left" width="150">Tank Type</th><th width="70">DAM</th><th width="80">Snap</th><th width="90">Aimed</th><th width="90">Aimed</th><th width="80">Snap</th><th width="70">DAM</th><th align="right" width="140">Handheld</th></tr>
<tr><th align="left">Tank/Cannon</th><td>60</td><td>60%</td><td>90%</td><td>90%</td><td>60%</td><td>561</td><th align="right">Heavy Cannon</th></tr>
<tr><th align="left">Rocket Launcher</th><td>85</td><td>55%</td><td>115%</td><td>115%</td><td>55%</td><td>87.52</td><th align="right">Rocket Launcher</th></tr>
<tr><th align="left">Laser Cannon</th><td>110</td><td>50%</td><td>85%</td><td>84%</td><td>50%</td><td>85</td><th align="right">Heavy Laser</th></tr>
<tr><th align="left">Hovertank/Plasma</th><td>110</td><td>85%</td><td>100%</td><td>100%</td><td>86%</td><td>80</td><th align="right">Plasma Rifle</th></tr>
<tr><th align="left">Hovertank/Launch</th><td>140</td><td>--%</td><td>120%</td><td>120%</td><td>--%</td><td>200</td><th align="right">Blaster Launcher</th></tr>
</table>
1AP rounds. 
2Average between the Small and Large Rocket.

: Hold up! Tank rounds do 60AP. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

So what's wrong? The table says 60 for the Tank/Cannon and 56 for HC-AP. Those are correct, no? --[[User:Zombie|Zombie]] 23:41, 26 February 2009 (CST)

: Sorry, didn't realise it was two tables side by side (or rather mirrored). Eyes only noticed the left side of the table. -[[User:NKF|NKF]] 23:53, 26 February 2009 (CST)

:: If the Hovertank Launcher did 200 damage, or worse if the Hovertank Launcher did EVEN MORE damage than the Blaster Launcher... that would make them easily the most deadly things on the map. As it is, the hovertank launcher is already pretty overpowered, even with 140 power.

== DOS4GW - What the heck is it? ==

It's been ages since I had to remember this stuff, so those who remember clearer than I do, forgive me if my descriptions aren't accurate. Hopefully the general idea will come across.

Back in ye olde days of computere gamynge - and where there were more E's to go around, memory handling was a tricky beast to handle. Computer memory is divided into several different categories. Conventional, extended and I think expanded. I might be jumbling the terminologies for the last two a bit. Doesn't matter - memory was just cut up into small segments. The two most common memory types to PCs at the time were pretty small but were readily available. The third one - the most expandable (aka the chip with its massive 4 Megs of RAM you just spent your whole month's allowance on!), wasn't as easy to get at.

To get access to the higher memory that was available to the computer, special memory handlers had to be used. Drivers like HIMEM, emm386, etc were used.

DOS4GW is one such handler that lets the game access the computer's available expanded memory. Lots of games that came out at the time use this. Doom, Duke Nukem 3d, Syndicate, Ultima Underworld, X-Com UFO/TFTD, etc. LOTS of games. Any time you ran a game from the dos console and you saw the Dos4GW message flash by briefly it would be assisted by it (well, it stayed on the screen for ages back when processors were slower!).

It took the hassle out of memory handling and let the game access the available memory on the computer as one big flat block of memory to play with.

So what was meant in the article was to simply replace the dos4gw.exe with a more up-to-date version from another game. I think the way to tell its version was just in the message that it displayed. You can just run the dos4gw.exe file in a console window. It'll give an error, but the message it shows will indicate its version. UFO 1.4 uses Dos4gw 1.95, for example.

-[[User:NKF|NKF]] 01:22, 6 March 2009 (CST)
:DOS4GW also switched the processor from 16bit to 32bit mode. [[User:Seb76|Seb76]] 13:58, 6 March 2009 (CST)

== Clipping ==
I have a new bug. Its harmless. I have a savegame (EU CE - modified game) which has a sectoid within another sectoid. In the alien turn, one secturd walked off the roof and dropped down <s>onto</s> into another. (I guess there DNA is indentical afterall, so they 'become one' with the world). If you want the savegame (superhuman edited using UFOloader, UFO Mod v1, xcomed, Khor Chin WeapEdit v0.1) drop me a request on the my page somewhere. [[User:EsTeR|EsTeR]] 01:40, 18 September 2009 (EDT)

: Not something many would encounter, but definitely something that can happen. Units can occupy the same physical space, but the game cannot display them all. It'll only draw one of them. Actually saw this effect happen back in the early days of XComutil when it gained the ability to manually add new aliens into a battlescape. It did this by slotting them into the same spaces occupied by existing aliens. Then the fun would happen when you saw a couple of Mutons suddenly walk out of a sectoid. Not sure how the game determines who gets hurt when struck by a bullet. May very well depend on the order they are stored in the unitpos.dat file.

: There are a couple of ways you can replicate this in-game, but I can only provide theories on how you could do it. Such as shooting the ceiling above you and letting the unit drop through, or moving a tank off a ledge and getting its non-primary segments land directly on top of another unit. By the way, the rear end of tanks get stuck in walls if you attempt to move north or east off any ledges. -[[User:NKF|NKF]] 02:18, 18 September 2009 (EDT)

: Ok, so as long as others know about this, then all is good. I had never seen it and was doing alot of head scratching until I shot the alien.

== Berserk HWP crashes the game ==
In the article page it mentions that aliens which go berserk with their integrated weapons will crash the game. This is only true for Mind Controlled aliens (or units under X-COM control) - alien controlled units which go berserk do not crash the game. I tested an MC'd Celatid just now and it doesn't crash the game either, though it doesn't immediately go berserk - it waits another turn for some odd reason. Someone want to check this to verify my results? --[[User:Zombie|Zombie]] 20:31, 27 December 2009 (EST)

== 80-items limit on CE edition ==

I have the feeling that the 80-items limit does not apply to the CE edition and is instead a 110-items limit (at least during base defence). Can anyone confirm? [[User:Seb76|Seb76]] 16:24, 24 February 2010 (EST)

:I believe this limit was increased for TFTD. Maybe it was also increased for the CE edition of UFO, and only ever applied to the DOS edition of UFO?? [[User:Spike|Spike]] 20:03, 11 March 2010 (EST)

Talk:Game Editors

2011-05-11T08:12:45Z

Kyrub:

Hi, there are so many mods out there, I have been wondering which to install and in what order, to get my game modified?

I actually have 3 problems: 1. The scroll speed is far too fast, even when I set scroll speed to 1. What mods or methods should I use to make EU playable? (TFTD seems to work just fine for some reason)
2. I'd like to try avoiding the game crashing every now and then bug.
3. I would like to avoid the base disjoint bug. I can avoid this by using XcomUtils RunXcom.bat, but then the speed automatically goes too fast. Sigh. [[User:Jasonred|Jasonred]] 18:55, 10 May 2011 (EDT)

For 1. and 3. use Ufo Extender, open Ufo Extender.ini in editor and set Tactical Scroll=1 and
Base Disjoint=1 in the Bug fix section. You may find other bugfixes useful as well. For 2. there is no obvious help other than saving a lot. --[[User:Kyrub|kyrub]] 21:05, 10 May 2011 (EDT)

:Wowee. Thanks. I'll give it a shot, hopefully it doesn't conflict with Xcumutil or something. BTW, does anyone know whether the Steam version crashes? Or did they introduce the fix they found for TFTD?
:Edit: Darnit, just tried it out and UFO Extender seems to have garbled graphics during the intro, geoscape, etc etc. Sigh. And, yes, I did change Video Pitch=1.
:Edit: Weird. It appears that running the game without any loader at all seems to result in working graphics, but using Extender garbles the graphics. How strange...
:Edit: Also. xcomutil refuses to be compliant with ufo extender. huh. [[User:Jasonred|Jasonred]] 21:27, 10 May 2011 (EDT)

::Two possibilities: 1) you make a clean install, avoid Xcomutil totally and go for Extender only. It works like a treat. 2) (harder) You download the LATEST Xcomutil 9.7 version, because this can cooperate with Extender. You make a clean install. You copy Extender in the file. Then you run Xcomutil installer, there's a new question "Do you want to use Extender?", you reply Yes. Now, the garbled graphics may still appear, you have to switch it on in Extender or Xcomutil and switch it off in the other one (this worked for me). Personnally, I'd try using Extender's Video pitch=1, and no Xcomutil's loader (reply No on xcusetup). But I cannot recall which way, you'll find it through trial and error.--[[User:Kyrub|kyrub]] 04:10, 11 May 2011 (EDT)

Talk:Game Editors

2011-05-11T08:10:56Z

Kyrub:

Hi, there are so many mods out there, I have been wondering which to install and in what order, to get my game modified?

I actually have 3 problems: 1. The scroll speed is far too fast, even when I set scroll speed to 1. What mods or methods should I use to make EU playable? (TFTD seems to work just fine for some reason)
2. I'd like to try avoiding the game crashing every now and then bug.
3. I would like to avoid the base disjoint bug. I can avoid this by using XcomUtils RunXcom.bat, but then the speed automatically goes too fast. Sigh. [[User:Jasonred|Jasonred]] 18:55, 10 May 2011 (EDT)

For 1. and 3. use Ufo Extender, open Ufo Extender.ini in editor and set Tactical Scroll=1 and
Base Disjoint=1 in the Bug fix section. You may find other bugfixes useful as well. For 2. there is no obvious help other than saving a lot. --[[User:Kyrub|kyrub]] 21:05, 10 May 2011 (EDT)

:Wowee. Thanks. I'll give it a shot, hopefully it doesn't conflict with Xcumutil or something. BTW, does anyone know whether the Steam version crashes? Or did they introduce the fix they found for TFTD?
:Edit: Darnit, just tried it out and UFO Extender seems to have garbled graphics during the intro, geoscape, etc etc. Sigh. And, yes, I did change Video Pitch=1.
:Edit: Weird. It appears that running the game without any loader at all seems to result in working graphics, but using Extender garbles the graphics. How strange...
:Edit: Also. xcomutil refuses to be compliant with ufo extender. huh. [[User:Jasonred|Jasonred]] 21:27, 10 May 2011 (EDT)

::Two possibilities: 1) you make a clean install, avoid Xcomutil totally and go for Extender only. It works like a treat. 2) (harder) You download the LATEST Xcomutil 9.7 version, because this can cooperate with Extender. You make a clean install. You copy Extender in the file. Then you run Xcomutil installer, there's a new question "Do you want to use Extender?", you reply Yes. Now, the garbled graphics may still appear, you have to switch it on in Extender or Xcomutil and switch it off in the other one (this worked for me). I cannot recall which way, but you'll find it through trial and error.--[[User:Kyrub|kyrub]] 04:10, 11 May 2011 (EDT)

Talk:Game Editors

2011-05-11T01:05:22Z

Kyrub:

Talk:Time Units (TFTD)

2011-04-26T11:33:37Z

Kyrub: Underwater TU penalty for moving through fire

== Underwater TU penalty for moving through fire ==

If a unit moves through underwater tile, that was set on fire, it uses extra 2 TUs. --[[User:Kyrub|kyrub]] 07:33, 26 April 2011 (EDT)

Talk:Known Bugs (TFTD)

2011-04-26T11:19:37Z

Kyrub: /* Land missions reaction fire bug */

==More Unconscious Bugs==

OK maybe TFTD is just plain buggy. This may be related to the Mind Controlled units MIA bug. What I saw was:

* All human units are killed or stunned, but the game does not end, a Coelecanth keeps working (this is a bug right?). I ran the Coelecanth for at least 4 more turns, with all Aquanauts either dead or stunned.
* If I saved and restored this game with the Coelecanth, on the first restored turn I had no units. I could not use the Units menu, the Next Unit button, or the Centre on Unit button. Nothing. After letting the aliens move for one turn, I could see my Coelecanth again.
* If I aborted this mission with the Coelecanth in the ship, as expected it says "Submarine Lost" and the stunned crew - who had been placed aboard the Triton - do not make it back to base.
* However, one of the stunned crew members does make it back to base. The stunned crew were all psi weak but some were stunned whilst under alien mind control, others were not - they were just panicked. I'm not sure if the crew member who teleported back to base was mind controlled or just (morale) panicked. But I would guess he was panicked, since most of them were mind controlled.
* When this crew member gets back to base he is shown as being assigned to craft called "Weapon-1" (since the craft he was assigned to no longer exists). Since this craft doesn't exist, there is no way to unassign him from it. Even if I had a new Triton I doubt I would be able to assign him to it. Shame he wasn't injured!
* Like in a similar incident I saw before, the affected Aquanaut was the first in the list and also the most senior rank. So that ''might'' be a factor.
* In this underwater mission I saw that the Hallucinoid's melee attack definitely works, and is lethal against unarmoured Aquanauts. The melee attack is ineffective against a Coelecanth (with XComUtil improved tank armour I think). I saw no evidence of its ranged attack working, ever, despite many opportunities. It may be possible that (like the HJ Cannon on land), the Hallucinoid's ranged attack might be able to reaction-fire underwater. I didn't do enough to test this, I might try that later.
[[User:Spike|Spike]] 14:08, 8 August 2009 (EDT)

I got this situation:
Was on a ship attack mission (passenger ship). On the 2nd level, at the lift (big room with crates), one of my soldiers got MC'd while still standing on the lift. He shot a thermal shok bomb and became unconscious (while MC'd). He remained unconscious until I eliminated all aliens, waiting patiently on the lift. Now, the game didn't notify me about a dead or MIA agent, but he disappeared from my aquanauts list. Dunno what was the cause of this misbehaviour.
[[User:mingos|mingos]]

: I imagine it's the bug Zombie reported [[Exploiting_Mind_Control#Zombie.27s_Permanent_Control_of_Aliens_via_Stunning|here]] in reverse - your dude turned into an alien. He didn't count as MC'd (so no MIA message), and he didn't count as dead (so no DIA message either). That bug - and the others on the same page - really should be documented on the "master lists"... - [[User:Bomb Bloke|Bomb Bloke]] 02:45, 4 December 2009 (EST)

So... If I applied stimulant on him, he'd be hostile for one turn and then magically return to my team, I assume. Damn, all this stunned/revived/MC'd/un-MC'd and the mixtures thereof are really weird. Multiple bugs at play... [[User:mingos|mingos]]]

:Seb76's loader fixes all the mind control / unconscious bugs. These bugs have many different manifestations. [[User:Spike|Spike]] 14:05, 8 December 2009 (EST)

== Gill-men reported as Snakemen ==

I get these interesting bugs playing TFTD. A Gill-man corpse is described as a Snakeman corpse. And I get messages saying "Snakeman soldier has panicked", "Snakeman soldier has gone Berserk", when the Gillmen have morale failures. Now the game I'm running using XComUtil, and these Gill-men were created by using XComUtil REPlace command, changing them from Aquatoids and Tasoths. So this may be a fluke. Has anyone else ever noticed this? [[User:Spike|Spike]] 17:27, 8 August 2009 (EDT)

:It's due to XcomUtil. There isn't a string containing "Snakeman" (or any variant thereof) in ENGLISH.DAT, ENGLISH2.DAT or even the executable. --[[User:Zombie|Zombie]] 19:45, 8 August 2009 (EDT)

==Survey Ship v. Escort==
The Survey Ship and Escort are not interchanged on the battlescape. The sub that comes up matches the UFOpaedia entry and the picture that pops up during interception. [[User:Magic9mushroom|Magic9mushroom]] 04:31, 21 August 2009 (EDT)

: Not sure what you mean exactly. I would expect that during Interception it would look like an Escort, but when you shoot it down you see a small 1 room craft (Survey Ship) on the Battlescape map but the expected large crew and loadout from an Escort. And vice versa. Is this not what you see? [[User:Spike|Spike]] 16:17, 21 August 2009 (EDT)

No. When you shoot an Escort down the picture (although not the size of the blob) matches the design of what you term a Survey Ship, the 1 room craft. When you shoot down a Survey Ship the picture (though again, not the size of the blob) matches the larger, 3 room craft. Which is also confirmed by the UFOpaedia entries. The UFOpaedia entry for the Survey Ship looks like the larger craft and the UFOpaedia entry for the Escort looks like the smaller craft.

So the sub seen on the battlescape matches the sub picture seen during interception and the sub picture in the UFOpaedia. There's no switching in the Battlescape relative to the stuff seen in the interception window and UFOpaedia. It may be that the Survey Ship was intended to be the one-room craft (and indeed, this seems logical) but if that's the case, it's switched in all three. I checked and double-checked this. [[User:Magic9mushroom|Magic9mushroom]] 05:03, 22 August 2009 (EDT)

Ok this is interesting, you may have uncovered a general misunderstanding. It's been suggested before that maybe it's just the ''names'' that are switched.

I know you have double checked that you have never run XcomUtil or a map pack? Definitely a virgin install?

Do you still see a large crew on a small craft and a 1 man crew on the larger craft?

That the sonar blob size is wrong does suggest maybe a problem in the .exe rather than the map files.

[[User:Spike|Spike]] 05:47, 22 August 2009 (EDT)

:I don't even know how to use Xcomutil and have never downloaded it, so I can guarantee it's not been run on my Collector's Edition version.

: I see multiple aliens on the 1-room craft and 1 alien on the 3-room craft.

:I don't think the names are switched, since IIRC the Survey Ship still appears first and the Escort second in a mission. Besides, it'd have to be names ''and crew'' switched to make sense.

:The sonar blob size isn't wrong, it coincides with the reported size of the craft. Escorts are reported as Small while Survey Ships are reported as Very Small. The problem, however, is that that reported size doesn't agree with the actual size of the ships, although it does agree with their loadouts. [[User:Magic9mushroom|Magic9mushroom]] 05:57, 22 August 2009 (EDT)

:::Ok you have been very thorough on this. Let me try to summarise. The battlescape map, UFOpaedia picture and Interception window picture all agree in showing the Survey Ship as the larger of the two. The reported detection size, crew loadouts, spawn points, order of appearance, combat power, & sonar blob size all agree in showing the Escort as the larger. (We haven't looked at Mission types, a further clue.)

::: I think the most likely explanation is your earlier suggestion that all 3 "pictures" (map, intercept, UFOPaedia) were switched. Probably the last 2 are configured in the same place in the exe. As Zombie said, a miscommunication between different parts of the development team. Good investigative work! [[User:Spike|Spike]] 12:57, 22 August 2009 (EDT)

::::You two have convinced me that it is probably unintentional. I don't think it should be listed under bugs though, as it always happens and doesn't actually screw up the game or anything. It's a very odd state of affairs and one that should be listed on the pages for the ships though. I still think the Survey Ship and Escort pages should reflect what actually happens in-game, ie that we should have the bigger floor plans under Survey Ship and the smaller ones under Escort, along with listing the UFOpaedia pics as they're actually noted in-game. [[User:Magic9mushroom|Magic9mushroom]] 05:00, 23 August 2009 (EDT)

Magic9mushroom, your investigation has improved the understanding of this issue. It should definitely be flagged up on the wiki pages of both craft. And the other picture-swapping case, the supply ship, should also be flagged on the relevant wiki pages. I think both should be considered Bugs, as they are illogical / inconsistent and don't behave as a player would reasonably expect. It's not necessary that an issue is unpredictable, nor that it damage game play, to be called a bug. Most listed bugs are always repeatable, and quite a few arguably aid gameplay. So I think we should list these as bugs, add your additional findings, and update the craft wiki pages. I'm not sure if we should swap the pictures and descriptions on the wiki pages back to the unmodified state or not. I'm thinking it over. You're right that it's confusing to players who use the unmodified game. [[User:Spike|Spike]] 09:57, 23 August 2009 (EDT)

: I'll put my support for the motion that Wiki should present this information as per what players will find in an unmodified game. So if they see pictures of an apple in the Ufopaedia but find an Orange in the Battlescape instead, while the Ufopaedia Orange entry comes up with a Battlescape Apple, then let it be so, but also note that the objects have been unintentionally swapped either in one place or the other. There are plenty more inconsistencies in TFTD anyhow. -[[User:NKF|NKF]]

So then, if there are no further objections, I plan to do the following:

- Swap the listed UFOpaedia pics for the Escort and Survey Ship to match the ones found in the in-game UFOpaedia.

- Swap the listed floorplans to agree with what is actually found on the Battlescape

- Add a note to both articles that there's likely some sort of mixup.

Any objections? [[User:Magic9mushroom|Magic9mushroom]] 19:47, 25 August 2009 (EDT)

:Generally agreed but you could consider putting both images on each page, listing the unmodified one first, and saying "it looks like THIS but should probably look like THIS". [[User:Spike|Spike]] 07:45, 26 August 2009 (EDT)

I'll link each page to the other of course, so that seems a bit redundant. It's been over a day by my count so I'll do the switch. [[User:Magic9mushroom|Magic9mushroom]] 07:54, 26 August 2009 (EDT)

...and done! [[User:Magic9mushroom|Magic9mushroom]] 08:32, 26 August 2009 (EDT)

== disappearing corpses ==
I thought this one is quite well known but could not find it on the list(Remove this if I missed it somehow).
This annoying bug is regularly encountered in settings with large maps containing lots of aliens (ship lane terror missions, XCOM base assault, Alien base assault, Artefact sites). Since the item table gets too full at some point and alien corpses and I think stunned aliens as well are items they are simply disappearing when any more killed/stunned. Too bad if this happens to be your hard earned lobsterman commander...
The easiest way to reproduce it is to take leviathan load of aquanauts including a squad of strong MC troopers, bring a taser, drills and a medikit and assault an Alien base. At sea level use MC chains to put every alien under molecular control and and march them to your transport. ASAP stun one aquatoid soldier,revive it with the medikit and wall it in. Then cull the rest of the Alien garrison and stuff your pockets and backpacks with DPLs and ammo, Sonic pulsers, corpses and other weapons and ammo(unload ammo from weapons) until you can carry no more. Once you are done finish the off the last aquatoid and proceed to the second stage. There drop the stuff and play hunt the last alien(in order to get all the loot from the base) and soon you will encounter the bug.--[[User:Tauon|Tauon]] 15:13, 11 October 2010 (EDT)

== Multi-part map ammo loss ==

I believe this is XComutil related. It was intended to solve the problem of not recovering any loot on the first part of the mission.

It's actually worse than that. Plain vanilla TFTD loses everything on the first map that is not being carried by aquanauts. Including everything in the Triton floor area. So if you had a few spare Gas Cannons on standby at the sub for example, but left them when you proceeded to the second part, you'll lose them for good.

Partly to avoid this bug, and to allow you to collect any loot in the first map, XComutil returns this stuff back to base. Although, it seems that XComutil sometimes gets carried and removes all your carried ammo as well.

This is just a guess, but it might be related to ammo that the game placed in inventory at the start of the mission. If you haven't moved them or unloaded/reloaded the weapons, XComutil may be seeing them as not being owned by anyone. -[[User:NKF|NKF]] 04:02, 31 October 2010 (UTC)

:Thanks NKF I will investigate further. [[User:Spike|Spike]] 19:04, 31 October 2010 (UTC)

:Well this just gets weirder. In one test, I left everything as loaded by the equip phase. In that case, when I get to stage 2, every clip that was originally loaded, is in the equipment pile. I can live with that. Everything that was left in the stage 1 equipment pile is gone - I can live with that, too. Not clear if the stage 1 equipment pile has been teleported back to my base-of-origin. It's hard to tell, because automatic re-equip of guns and ammo after the mission is instant (hence the "Not enough equipment to fully re-equip troops" message).

:In the 2nd test, instead I manually reloaded every item. Every ammo unit that I had manually loaded into a gun during stage 1, was gone at the stage 2 equip phase. Even all the ammo that Aquanauts had been carrying as spares, was gone. The only ammo I had was one gauss pistol clip which I suspect I forgot to manually reload - so it was only there because of the behaviour observed in the preceding test (previous paragraph). And, the ammo had definitely not teleported back to base, because after I aborted the mission (at the stage 2 start area), my ammo stores back at base were depleted by pretty much the same amount as the missing ammo. So I think something's going badly wrong here.

:(Tests were done using XcomUtil 9.60, not XcomUtil 9.7 Beta.) [[User:Spike|Spike]] 20:41, 1 November 2010 (UTC)

:I tried installing XcomUtil 9.7 Beta, to test that version, but had some issues with my Steam TFTD installation. I'll try again tomorrow. [[User:Spike|Spike]] 21:54, 1 November 2010 (UTC)

:: Perhaps the older version of XComutil was just too eager with sending the loose items back home? Either way, don't forget to do a test in the plain vanilla copy of the game if you get a chance. My tests were based on a vanilla copy of the v2.0 dos version in Dosbox. Of course, your mileage certainly may vary.

::: OK I checked plain vanilla - full reinstall of Steam version (Dosbox, though reported by XcomUtil 9.7 as TFTDWin 1.0 version). Plain vanilla install, using the savegame from the XCU9.6 game, and a Turn 1 state (so XCU9.6 may have messed with things during the equip phase). The results are as expected - all carried equipment and loaded ammunition, including ammo counts, are preserved between stage 1 and stage 2. Equipment pile or other dropped items from stage 1 are not carried over to stage 2. Alien kills, corpses and artefacts from stage 1 are credited upon abort from stage 2. All civilians from both stages die upon abort. Mission was a cargo ship mission. [[User:Spike|Spike]] 20:38, 3 November 2010 (UTC)

::: I also checked XCU 9.7 Build 422, clean install on a clean install of TFTD (Steam). Good news, the bug is fixed. I can't reproduce any of the bad behaviour - no missing ammo, no missing equipment. Cool! [[User:Spike|Spike]] 20:45, 3 November 2010 (UTC)

::One thing that has come from this is that I'm never going to leave any excess items in the Triton on two-parters ever again. Well, unless it's every-day easy-to-get stuff like the Sonic Cannons. Just have to be mindful of the spare tazers and chem. flares. -[[User:NKF|NKF]] 07:11, 2 November 2010 (UTC)

== Land missions reaction fire bug ==

This is an expansion of a bug known as [http://www.ufopaedia.org/index.php?title=Known_Bugs_%28TFTD%29#X-COM_Equipment_Glitches "X-COM underwater-only weapons fire on land missions"]. The bug may actually be more serious than that and it may extend to all present units.

The game tries to check for land availability of a weapon in hand, but it wrongly tests the first OBPOS.dat item instead. If the first item stored in OBPOS is not allowed on land, no reaction fire is possible, during the whole mission, both for X-Com and for Alien side! If, however, the first item is allowed, all reaction fire is always possible, for both normal and underwater-only weapons.
Note: This has not been tested in game. I don't know how the first OBPOS.dat is selected. Maybe this effect occures very rarely, or never. The code leaves the possibility open. --[[User:Kyrub|kyrub]] 07:19, 26 April 2011 (EDT)

Talk:Known Bugs (TFTD)

2011-04-26T11:19:23Z

Kyrub: /* Land missions reaction fire bug */ new section

==More Unconscious Bugs==

OK maybe TFTD is just plain buggy. This may be related to the Mind Controlled units MIA bug. What I saw was:

* All human units are killed or stunned, but the game does not end, a Coelecanth keeps working (this is a bug right?). I ran the Coelecanth for at least 4 more turns, with all Aquanauts either dead or stunned.
* If I saved and restored this game with the Coelecanth, on the first restored turn I had no units. I could not use the Units menu, the Next Unit button, or the Centre on Unit button. Nothing. After letting the aliens move for one turn, I could see my Coelecanth again.
* If I aborted this mission with the Coelecanth in the ship, as expected it says "Submarine Lost" and the stunned crew - who had been placed aboard the Triton - do not make it back to base.
* However, one of the stunned crew members does make it back to base. The stunned crew were all psi weak but some were stunned whilst under alien mind control, others were not - they were just panicked. I'm not sure if the crew member who teleported back to base was mind controlled or just (morale) panicked. But I would guess he was panicked, since most of them were mind controlled.
* When this crew member gets back to base he is shown as being assigned to craft called "Weapon-1" (since the craft he was assigned to no longer exists). Since this craft doesn't exist, there is no way to unassign him from it. Even if I had a new Triton I doubt I would be able to assign him to it. Shame he wasn't injured!
* Like in a similar incident I saw before, the affected Aquanaut was the first in the list and also the most senior rank. So that ''might'' be a factor.
* In this underwater mission I saw that the Hallucinoid's melee attack definitely works, and is lethal against unarmoured Aquanauts. The melee attack is ineffective against a Coelecanth (with XComUtil improved tank armour I think). I saw no evidence of its ranged attack working, ever, despite many opportunities. It may be possible that (like the HJ Cannon on land), the Hallucinoid's ranged attack might be able to reaction-fire underwater. I didn't do enough to test this, I might try that later.
[[User:Spike|Spike]] 14:08, 8 August 2009 (EDT)

I got this situation:
Was on a ship attack mission (passenger ship). On the 2nd level, at the lift (big room with crates), one of my soldiers got MC'd while still standing on the lift. He shot a thermal shok bomb and became unconscious (while MC'd). He remained unconscious until I eliminated all aliens, waiting patiently on the lift. Now, the game didn't notify me about a dead or MIA agent, but he disappeared from my aquanauts list. Dunno what was the cause of this misbehaviour.
[[User:mingos|mingos]]

: I imagine it's the bug Zombie reported [[Exploiting_Mind_Control#Zombie.27s_Permanent_Control_of_Aliens_via_Stunning|here]] in reverse - your dude turned into an alien. He didn't count as MC'd (so no MIA message), and he didn't count as dead (so no DIA message either). That bug - and the others on the same page - really should be documented on the "master lists"... - [[User:Bomb Bloke|Bomb Bloke]] 02:45, 4 December 2009 (EST)

So... If I applied stimulant on him, he'd be hostile for one turn and then magically return to my team, I assume. Damn, all this stunned/revived/MC'd/un-MC'd and the mixtures thereof are really weird. Multiple bugs at play... [[User:mingos|mingos]]]

:Seb76's loader fixes all the mind control / unconscious bugs. These bugs have many different manifestations. [[User:Spike|Spike]] 14:05, 8 December 2009 (EST)

== Gill-men reported as Snakemen ==

I get these interesting bugs playing TFTD. A Gill-man corpse is described as a Snakeman corpse. And I get messages saying "Snakeman soldier has panicked", "Snakeman soldier has gone Berserk", when the Gillmen have morale failures. Now the game I'm running using XComUtil, and these Gill-men were created by using XComUtil REPlace command, changing them from Aquatoids and Tasoths. So this may be a fluke. Has anyone else ever noticed this? [[User:Spike|Spike]] 17:27, 8 August 2009 (EDT)

:It's due to XcomUtil. There isn't a string containing "Snakeman" (or any variant thereof) in ENGLISH.DAT, ENGLISH2.DAT or even the executable. --[[User:Zombie|Zombie]] 19:45, 8 August 2009 (EDT)

==Survey Ship v. Escort==
The Survey Ship and Escort are not interchanged on the battlescape. The sub that comes up matches the UFOpaedia entry and the picture that pops up during interception. [[User:Magic9mushroom|Magic9mushroom]] 04:31, 21 August 2009 (EDT)

: Not sure what you mean exactly. I would expect that during Interception it would look like an Escort, but when you shoot it down you see a small 1 room craft (Survey Ship) on the Battlescape map but the expected large crew and loadout from an Escort. And vice versa. Is this not what you see? [[User:Spike|Spike]] 16:17, 21 August 2009 (EDT)

No. When you shoot an Escort down the picture (although not the size of the blob) matches the design of what you term a Survey Ship, the 1 room craft. When you shoot down a Survey Ship the picture (though again, not the size of the blob) matches the larger, 3 room craft. Which is also confirmed by the UFOpaedia entries. The UFOpaedia entry for the Survey Ship looks like the larger craft and the UFOpaedia entry for the Escort looks like the smaller craft.

So the sub seen on the battlescape matches the sub picture seen during interception and the sub picture in the UFOpaedia. There's no switching in the Battlescape relative to the stuff seen in the interception window and UFOpaedia. It may be that the Survey Ship was intended to be the one-room craft (and indeed, this seems logical) but if that's the case, it's switched in all three. I checked and double-checked this. [[User:Magic9mushroom|Magic9mushroom]] 05:03, 22 August 2009 (EDT)

Ok this is interesting, you may have uncovered a general misunderstanding. It's been suggested before that maybe it's just the ''names'' that are switched.

I know you have double checked that you have never run XcomUtil or a map pack? Definitely a virgin install?

Do you still see a large crew on a small craft and a 1 man crew on the larger craft?

That the sonar blob size is wrong does suggest maybe a problem in the .exe rather than the map files.

[[User:Spike|Spike]] 05:47, 22 August 2009 (EDT)

:I don't even know how to use Xcomutil and have never downloaded it, so I can guarantee it's not been run on my Collector's Edition version.

: I see multiple aliens on the 1-room craft and 1 alien on the 3-room craft.

:I don't think the names are switched, since IIRC the Survey Ship still appears first and the Escort second in a mission. Besides, it'd have to be names ''and crew'' switched to make sense.

:The sonar blob size isn't wrong, it coincides with the reported size of the craft. Escorts are reported as Small while Survey Ships are reported as Very Small. The problem, however, is that that reported size doesn't agree with the actual size of the ships, although it does agree with their loadouts. [[User:Magic9mushroom|Magic9mushroom]] 05:57, 22 August 2009 (EDT)

:::Ok you have been very thorough on this. Let me try to summarise. The battlescape map, UFOpaedia picture and Interception window picture all agree in showing the Survey Ship as the larger of the two. The reported detection size, crew loadouts, spawn points, order of appearance, combat power, & sonar blob size all agree in showing the Escort as the larger. (We haven't looked at Mission types, a further clue.)

::: I think the most likely explanation is your earlier suggestion that all 3 "pictures" (map, intercept, UFOPaedia) were switched. Probably the last 2 are configured in the same place in the exe. As Zombie said, a miscommunication between different parts of the development team. Good investigative work! [[User:Spike|Spike]] 12:57, 22 August 2009 (EDT)

::::You two have convinced me that it is probably unintentional. I don't think it should be listed under bugs though, as it always happens and doesn't actually screw up the game or anything. It's a very odd state of affairs and one that should be listed on the pages for the ships though. I still think the Survey Ship and Escort pages should reflect what actually happens in-game, ie that we should have the bigger floor plans under Survey Ship and the smaller ones under Escort, along with listing the UFOpaedia pics as they're actually noted in-game. [[User:Magic9mushroom|Magic9mushroom]] 05:00, 23 August 2009 (EDT)

Magic9mushroom, your investigation has improved the understanding of this issue. It should definitely be flagged up on the wiki pages of both craft. And the other picture-swapping case, the supply ship, should also be flagged on the relevant wiki pages. I think both should be considered Bugs, as they are illogical / inconsistent and don't behave as a player would reasonably expect. It's not necessary that an issue is unpredictable, nor that it damage game play, to be called a bug. Most listed bugs are always repeatable, and quite a few arguably aid gameplay. So I think we should list these as bugs, add your additional findings, and update the craft wiki pages. I'm not sure if we should swap the pictures and descriptions on the wiki pages back to the unmodified state or not. I'm thinking it over. You're right that it's confusing to players who use the unmodified game. [[User:Spike|Spike]] 09:57, 23 August 2009 (EDT)

: I'll put my support for the motion that Wiki should present this information as per what players will find in an unmodified game. So if they see pictures of an apple in the Ufopaedia but find an Orange in the Battlescape instead, while the Ufopaedia Orange entry comes up with a Battlescape Apple, then let it be so, but also note that the objects have been unintentionally swapped either in one place or the other. There are plenty more inconsistencies in TFTD anyhow. -[[User:NKF|NKF]]

So then, if there are no further objections, I plan to do the following:

- Swap the listed UFOpaedia pics for the Escort and Survey Ship to match the ones found in the in-game UFOpaedia.

- Swap the listed floorplans to agree with what is actually found on the Battlescape

- Add a note to both articles that there's likely some sort of mixup.

Any objections? [[User:Magic9mushroom|Magic9mushroom]] 19:47, 25 August 2009 (EDT)

:Generally agreed but you could consider putting both images on each page, listing the unmodified one first, and saying "it looks like THIS but should probably look like THIS". [[User:Spike|Spike]] 07:45, 26 August 2009 (EDT)

I'll link each page to the other of course, so that seems a bit redundant. It's been over a day by my count so I'll do the switch. [[User:Magic9mushroom|Magic9mushroom]] 07:54, 26 August 2009 (EDT)

...and done! [[User:Magic9mushroom|Magic9mushroom]] 08:32, 26 August 2009 (EDT)

== disappearing corpses ==
I thought this one is quite well known but could not find it on the list(Remove this if I missed it somehow).
This annoying bug is regularly encountered in settings with large maps containing lots of aliens (ship lane terror missions, XCOM base assault, Alien base assault, Artefact sites). Since the item table gets too full at some point and alien corpses and I think stunned aliens as well are items they are simply disappearing when any more killed/stunned. Too bad if this happens to be your hard earned lobsterman commander...
The easiest way to reproduce it is to take leviathan load of aquanauts including a squad of strong MC troopers, bring a taser, drills and a medikit and assault an Alien base. At sea level use MC chains to put every alien under molecular control and and march them to your transport. ASAP stun one aquatoid soldier,revive it with the medikit and wall it in. Then cull the rest of the Alien garrison and stuff your pockets and backpacks with DPLs and ammo, Sonic pulsers, corpses and other weapons and ammo(unload ammo from weapons) until you can carry no more. Once you are done finish the off the last aquatoid and proceed to the second stage. There drop the stuff and play hunt the last alien(in order to get all the loot from the base) and soon you will encounter the bug.--[[User:Tauon|Tauon]] 15:13, 11 October 2010 (EDT)

== Multi-part map ammo loss ==

I believe this is XComutil related. It was intended to solve the problem of not recovering any loot on the first part of the mission.

It's actually worse than that. Plain vanilla TFTD loses everything on the first map that is not being carried by aquanauts. Including everything in the Triton floor area. So if you had a few spare Gas Cannons on standby at the sub for example, but left them when you proceeded to the second part, you'll lose them for good.

Partly to avoid this bug, and to allow you to collect any loot in the first map, XComutil returns this stuff back to base. Although, it seems that XComutil sometimes gets carried and removes all your carried ammo as well.

This is just a guess, but it might be related to ammo that the game placed in inventory at the start of the mission. If you haven't moved them or unloaded/reloaded the weapons, XComutil may be seeing them as not being owned by anyone. -[[User:NKF|NKF]] 04:02, 31 October 2010 (UTC)

:Thanks NKF I will investigate further. [[User:Spike|Spike]] 19:04, 31 October 2010 (UTC)

:Well this just gets weirder. In one test, I left everything as loaded by the equip phase. In that case, when I get to stage 2, every clip that was originally loaded, is in the equipment pile. I can live with that. Everything that was left in the stage 1 equipment pile is gone - I can live with that, too. Not clear if the stage 1 equipment pile has been teleported back to my base-of-origin. It's hard to tell, because automatic re-equip of guns and ammo after the mission is instant (hence the "Not enough equipment to fully re-equip troops" message).

:In the 2nd test, instead I manually reloaded every item. Every ammo unit that I had manually loaded into a gun during stage 1, was gone at the stage 2 equip phase. Even all the ammo that Aquanauts had been carrying as spares, was gone. The only ammo I had was one gauss pistol clip which I suspect I forgot to manually reload - so it was only there because of the behaviour observed in the preceding test (previous paragraph). And, the ammo had definitely not teleported back to base, because after I aborted the mission (at the stage 2 start area), my ammo stores back at base were depleted by pretty much the same amount as the missing ammo. So I think something's going badly wrong here.

:(Tests were done using XcomUtil 9.60, not XcomUtil 9.7 Beta.) [[User:Spike|Spike]] 20:41, 1 November 2010 (UTC)

:I tried installing XcomUtil 9.7 Beta, to test that version, but had some issues with my Steam TFTD installation. I'll try again tomorrow. [[User:Spike|Spike]] 21:54, 1 November 2010 (UTC)

:: Perhaps the older version of XComutil was just too eager with sending the loose items back home? Either way, don't forget to do a test in the plain vanilla copy of the game if you get a chance. My tests were based on a vanilla copy of the v2.0 dos version in Dosbox. Of course, your mileage certainly may vary.

::: OK I checked plain vanilla - full reinstall of Steam version (Dosbox, though reported by XcomUtil 9.7 as TFTDWin 1.0 version). Plain vanilla install, using the savegame from the XCU9.6 game, and a Turn 1 state (so XCU9.6 may have messed with things during the equip phase). The results are as expected - all carried equipment and loaded ammunition, including ammo counts, are preserved between stage 1 and stage 2. Equipment pile or other dropped items from stage 1 are not carried over to stage 2. Alien kills, corpses and artefacts from stage 1 are credited upon abort from stage 2. All civilians from both stages die upon abort. Mission was a cargo ship mission. [[User:Spike|Spike]] 20:38, 3 November 2010 (UTC)

::: I also checked XCU 9.7 Build 422, clean install on a clean install of TFTD (Steam). Good news, the bug is fixed. I can't reproduce any of the bad behaviour - no missing ammo, no missing equipment. Cool! [[User:Spike|Spike]] 20:45, 3 November 2010 (UTC)

::One thing that has come from this is that I'm never going to leave any excess items in the Triton on two-parters ever again. Well, unless it's every-day easy-to-get stuff like the Sonic Cannons. Just have to be mindful of the spare tazers and chem. flares. -[[User:NKF|NKF]] 07:11, 2 November 2010 (UTC)

== Land missions reaction fire bug ==

This is an expansion of a bug known as [http://www.ufopaedia.org/index.php?title=Known_Bugs_%28TFTD%29#X-COM_Equipment_Glitches "X-COM underwater-only weapons fire on land missions"]. The bug may actually be more serious than that and it may extend to all present units.

The game tries to check for land availability of a weapon in hand, but it wrongly tests the first OBPOS.dat item instead. If the first item stored in OBPOS is not allowed on land, no reaction fire is possible, during the whole mission, both for X-Com and for Alien side! If, however, the first item is allowed, all reaction fire is always possible, for both normal and underwater-only weapons.
Note: This has not been tested in game. I don't know how the first OBPOS.dat is selected. Maybe this effect occures very rarely, or never. The code leaves the possibility open.

CRAFT.DAT (TFTD)

2011-04-15T10:05:07Z

Kyrub: /* TFTD Structure */

==TFTD Structure==
There are 50 records each having 110 bytes long for a file size of 5,500 bytes. Unless otherwise noted, all values and offsets are in Hex; 2-byte values are signed little-endian integers.

* '''0''' - Craft Type, Possible Values are the same as [[GEODATA.DAT]]:
{| {{stdTable}}
! Human !! Alien
|-
| 0 - Triton || 5 - Survey Ship
|-
| 1 - Hammerhead || 6 - Escort
|-
| 2 - Leviathan || 7 - Cruiser
|-
| 3 - Barracuda || 8 - Heavy Cruiser
|-
| 4 - Manta || 9 - Hunter
|-
| || A - Battleship
|-
| || B - Dreadnought
|-
| || C - Fleet Supply Cruiser
|-
| colspan="2" align="center" | FF - Entry Not Used
|}

Offsets 1 and 5 refer to the weapon placed in the left and right slots respectively. (The Hammerhead does not have a center weapon type, only a left). Their possible values are listed here:
0 - Ajax Launcher
1 - D.U.P. Head Launcher
2 - Craft Gas Cannon
3 - P.W.T. Cannon
4 - Gauss Cannon
5 - Sonic Wave
FF - No Weapon
* '''1''' - Left Weapon Type
* '''2-3''' - Left Ammo Quantity ('''NOTE''': Ammo values normally do not exceed 100, but since the variable is stored as 2 bytes you can crank the total up to 32,767).
* '''4''' - Indicates what a craft is doing.
0 - At base
1 - Airborne
2 - USOs normally get this value, have no idea what it represents.
* '''5''' - Right Weapon Type
* '''6-3C''' - Items on sub.
6 - Coelacanth/G. Cannon
7 - Coelacanth/Aqua Jet
8 - Coelacanth/Gauss
9 - Displacer /Sonic
A - Displacer /P.W.T.
B - Dart Gun
C - Dart Clip
D - Jet Harpoon
E - Harpoon Clip
F - Gas Cannon
10 - GC-AP Bolts
11 - GC-HE Bolts
12 - GC-Phosphorous Bolts
13 - Hydro-Jet Cannon
14 - HJ-AP Ammo
15 - HJ-HE Ammo
16 - HJ-P Ammo
17 - Torpedo Launcher
18 - Small Torpedo
19 - Large Torpedo
1A - Phosphor Torpedo
1B - Gauss Pistol
1C - Gauss Rifle
1D - Heavy Gauss
1E - Magna-Blast Grenade
1F - Dye Grenade
20 - Particle Disturbance Grenade
21 - Magna-Pack Explosive
22 - Particle Disturbance Sensor
23 - Medi-Kit
24 - M.C. Disruptor
25 - Thermal Tazer
26 - Chemical Flare
27 - Vibro Blade
28 - Thermic Lance
29 - Heavy Thermic Lance
2A - ''(Unused)''
2B - ''(Unused)''
2C - ''(Unused)''
2D - Sonic Cannon
2E - Cannon Power Clip
2F - Sonic-Blasta Rifle
30 - Blasta Power Clip
31 - Sonic Pistol
32 - Pistol Power Clip
33 - Disruptor Pulse Launcher
34 - Disruptor Ammo
35 - Thermal Shok Launcher
36 - Thermal Shok Bomb
37 - Sonic Pulser
38 - ''(Unused)''
39 - M.C. Reader
3A - Gauss Pistol Clip
3B - Gauss Rifle Clip
3C - Heavy Gauss Clip
* '''3D''' - Unknown.
* '''3E-3F''' - Right Ammo Quantity ('''NOTE''': Ammo values normally do not exceed 100, but since the variable is stored as 2 bytes you can crank the total up to 32,767).
* '''40-41''' - Unknown.
* '''42-43''' - Damage, that is the amount it currently has taken. This value divided by the craft's damage capacity gives the percentage shown in-game.
* '''44-45''' - Depth of craft.
0 - Touched Down *
1 - Shallow
2 - Normal
3 - Deep
4 - Very Deep
('''*NOTE''': If craft is moving and you change it to this value the depth will correct itself automatically. Speed must also be edited to 0 for the change in depth to hold.)
* '''46-47''' - Speed of craft.
* '''48-49''' - Unknown - activity type?
* '''4A-4B''' - Unknown - goes to 0 when tracking a target but not attacking.
* '''4C-4D''' - Destination coordinates, horizontal.
* '''4E-4F''' - Destination coordinates, vertical.
* '''50-51''' - Fuel, amount remaining. This value divided by the crafts total fuel capacity gives the percentage shown in-game.
* '''52-53''' - Base Reference as an index to [[LOC.DAT]]
* '''54-55''' - Mission type craft is on.
0 - Alien Probe Mission
1 - Alien Interdiction
2 - Alien Resource Raid
3 - Alien Infiltration
4 - Alien Colony Expansion
5 - Alien Surface Attacks
6 - Floating Base Attack
7 - Colony Supply Missions
* '''56-57''' - Zone where mission is being carried out.
0 - North Atlantic
1 - South Atlantic
2 - North Pacific
3 - South Pacific
4 - Mediterranean
5 - South China Sea
6 - Indian Ocean
7 - Sea of Japan
8 - North Sea
9 - Caribbean
A - Antarctic
B - Arctic
C - Eurasia
D - North America
E - Africa
* '''58-59''' - Unknown.
* '''5A-5B''' - Unknown.
* '''5C-5D''' - Primary Alien Race found on craft.
0 - Aquatoid
1 - Gill Man
2 - Lobster Man
3 - Tasoth
4+ - Mixed
* '''5E-5F''' - USO Attack timer.
* '''60-61''' - USO Escape manuever timer.
* '''62-63''' - Craft status.
0 - Ready
1 - Out
2 - Repairs
3 - Refueling
4 - Re-arming
* '''64''' - Bit Flags.
40 - Show full Transmission Resolver data
* '''65-67''' - Unknown - possibly 64 is actually a 4-byte value.
* '''68-69''' - Touchdown depth (see entry at 44-45 for possible values).
* '''6A-6D''' - Unknown.

==See Also==
[[CRAFT.DAT]]

* [[Saved Game Files]]

[[Category:Game Files (TFTD)]]

CRAFT.DAT (TFTD)

2011-04-15T10:04:05Z

Kyrub: /* TFTD Structure */

==TFTD Structure==
There are 50 records each having 110 bytes long for a file size of 5,500 bytes. Unless otherwise noted, all values and offsets are in Hex; 2-byte values are signed little-endian integers.

* '''0''' - Craft Type, Possible Values are the same as [[GEODATA.DAT]]:
{| {{stdTable}}
! Human !! Alien
|-
| 0 - Triton || 5 - Survey Ship
|-
| 1 - Hammerhead || 6 - Escort
|-
| 2 - Leviathan || 7 - Cruiser
|-
| 3 - Barracuda || 8 - Heavy Cruiser
|-
| 4 - Manta || 9 - Hunter
|-
| || A - Battleship
|-
| || B - Dreadnought
|-
| || C - Fleet Supply Cruiser
|-
| colspan="2" align="center" | FF - Entry Not Used
|}

Offsets 1 and 5 refer to the weapon placed in the left and right slots respectively. (The Hammerhead does not have a center weapon type, only a left). Their possible values are listed here:
0 - Ajax Launcher
1 - D.U.P. Head Launcher
2 - Craft Gas Cannon
3 - P.W.T. Cannon
4 - Gauss Cannon
5 - Sonic Wave
FF - No Weapon
* '''1''' - Left Weapon Type
* '''2-3''' - Left Ammo Quantity ('''NOTE''': Ammo values normally do not exceed 100, but since the variable is stored as 2 bytes you can crank the total up to 32,767).
* '''4''' - Indicates what a craft is doing.
0 - At base
1 - Airborne
2 - USOs normally get this value, have no idea what it represents.
* '''5''' - Right Weapon Type
* '''6-3C''' - Items on sub.
6 - Coelacanth/G. Cannon
7 - Coelacanth/Aqua Jet
8 - Coelacanth/Gauss
9 - Displacer /Sonic
A - Displacer /P.W.T.
B - Dart Gun
C - Dart Clip
D - Jet Harpoon
E - Harpoon Clip
F - Gas Cannon
10 - GC-AP Bolts
11 - GC-HE Bolts
12 - GC-Phosphorous Bolts
13 - Hydro-Jet Cannon
14 - HJ-AP Ammo
15 - HJ-HE Ammo
16 - HJ-P Ammo
17 - Torpedo Launcher
18 - Small Torpedo
19 - Large Torpedo
1A - Phosphor Torpedo
1B - Gauss Pistol
1C - Gauss Rifle
1D - Heavy Gauss
1E - Magna-Blast Grenade
1F - Dye Grenade
20 - Particle Disturbance Grenade
21 - Magna-Pack Explosive
22 - Particle Disturbance Sensor
23 - Medi-Kit
24 - M.C. Disruptor
25 - Thermal Tazer
26 - Chemical Flare
27 - Vibro Blade
28 - Thermic Lance
29 - Heavy Thermic Lance
2A - ''(Unused)''
2B - ''(Unused)''
2C - ''(Unused)''
2D - Sonic Cannon
2E - Cannon Power Clip
2F - Sonic-Blasta Rifle
30 - Blasta Power Clip
31 - Sonic Pistol
32 - Pistol Power Clip
33 - Disruptor Pulse Launcher
34 - Disruptor Ammo
35 - Thermal Shok Launcher
36 - Thermal Shok Bomb
37 - Sonic Pulser
38 - ''(Unused)''
39 - M.C. Reader
3A - Gauss Pistol Clip
3B - Gauss Rifle Clip
3C - Heavy Gauss Clip
* '''3D''' - Unknown.
* '''3E-3F''' - Right Ammo Quantity ('''NOTE''': Ammo values normally do not exceed 100, but since the variable is stored as 2 bytes you can crank the total up to 32,767).
* '''40-41''' - Unknown.
* '''42-43''' - Damage, that is the amount it currently has taken. This value divided by the craft's damage capacity gives the percentage shown in-game.
* '''44-45''' - Depth of craft.
0 - Touched Down *
1 - Shallow
2 - Normal
3 - Deep
4 - Very Deep
('''*NOTE''': If craft is moving and you change it to this value the depth will correct itself automatically. Speed must also be edited to 0 for the change in depth to hold.)
* '''46-47''' - Speed of craft.
* '''48-49''' - Unknown - activity type?
* '''4A-4B''' - Unknown - goes to 0 when tracking a target but not attacking.
* '''4C-4D''' - Destination coordinates, horizontal.
* '''4E-4F''' - Destination coordinates, vertical.
* '''50-51''' - Fuel, amount remaining. This value divided by the crafts total fuel capacity gives the percentage shown in-game.
* '''52-53''' - Base Reference as an index to [[LOC.DAT]]
* '''54-55''' - Mission type craft is on.
0 - Alien Probe Mission
1 - Alien Interdiction
2 - Alien Resource Raid
3 - Alien Infiltration
4 - Alien Colony Expansion
5 - Alien Surface Attacks
6 - Floating Base Attack
7 - Colony Supply Missions
* '''56-57''' - Zone where mission is being carried out.
0 - North Atlantic
1 - South Atlantic
2 - North Pacific
3 - South Pacific
4 - Mediterranean
5 - South China Sea
6 - Indian Ocean
7 - Sea of Japan
8 - North Sea
9 - Caribbean
A - Antarctic
B - Arctic
C - Eurasia
D - North America
E - Africa
* '''58-59''' - Unknown.
* '''5A-5B''' - Unknown.
* '''5C-5D''' - Primary Alien Race found on craft.
0 - Aquatoid
1 - Gill Man
2 - Lobster Man
3 - Tasoth
4+ - Mixed
* '''5E-5F''' - USO attack timer.
* '''60-61''' - Unknown.
* '''62-63''' - Craft status.
0 - Ready
1 - Out
2 - Repairs
3 - Refueling
4 - Re-arming
* '''64''' - Bit Flags.
40 - Show full Transmission Resolver data
* '''65-67''' - Unknown - possibly 64 is actually a 4-byte value.
* '''68-69''' - Touchdown depth (see entry at 44-45 for possible values).
* '''6A-6D''' - Unknown.

==See Also==
[[CRAFT.DAT]]

* [[Saved Game Files]]

[[Category:Game Files (TFTD)]]

Talk:UNITREF.DAT

2011-04-13T10:03:34Z

Kyrub: /* Offset 0x4A (74) */

Anyone who has it - can we get listings of values for various aliens on the Unitref page, for some of the variables found in both Unitref and the Geoscape [[Talk:Overviews_of_Aliens|Alien stats]]? E.g. energy recharge (Unitref[35]), energy loss [45]... like what Danial did for Height. Some of it might go to NKF's redesigned [[Soldier]] page. I am trying to flesh out the Geoscape data so I know what everything is there (and can then extend it across difficulty levels). It has unlabelled fields with values, some of which I know must be these values... but there's no list for me to compare against. Thanks if you can help! ---[[User:MikeTheRed|MikeTheRed]] 19:37, 25 Nov 2005 (PST)

P.S. We probably should clean up this Discussion some time. I will if I find the time to make sure everything has made its way to wherever it should go.

----

== Offsets 0x02 - 0x09 ==

It's obvious from unit drawing functions (reversed ones) it's a PCK and TAB spritepack reference address (DWORD).

_pck = (int)unitref_addr->pck_ref;
_tab = (int)unitref_addr->tab_ref;
...
if ( (_WORD)handob != 255 )
xc_BF_Draw_Battlescape_shaded_Sprite((char)v18, (int)vf_handob_pck, (int)vf_handob_tab, v21, v23, shade);
xc_BF_Draw_Battlescape_shaded_Sprite(sprite_num1, _pck, _tab, y0, x0, shade);
--[[User:Volutar|Volutar]] 09:43, 20 February 2011 (EST)

:So you're saying these values point to where the PCK/TAB files used by the unit in concern have been loaded into RAM, similar to how [[UNITPOS.DAT|UnitPos[4-7]]] points to where the UnitRef record is? -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 17:56, 20 February 2011 (EST)
::Exactly. They are simple 32bit pointers to RAM location where exact unit PCK/TAB loaded (I don't know how they worked for DOS version - I guess the same way). You could notice the lowest bytes (2th and 6th) are aligned to 4, as for all memory locations. --[[User:Volutar|Volutar]] 01:13, 21 February 2011 (EST)

::: Since the saves are interchangeable between the Dos and Window versions, and since the Dos version uses the Dos4gw engine to handle the exapanded memory, it could very well be a 32-bit pointer.

::: Still, memory pointers? That would mean these values are used at run-time only and these are just dumps of whatever it was at the time the save was made. Since whatever memory allocation function they used back then (I'm guessing malloc() ) would be storing the graphics at different offsets each time the tactical engine boots up, these would have to be replaced anyway. -[[User:NKF|NKF]] 02:00, 21 February 2011 (EST)

.text:004178EC
cur_unitref_addr = vf_unitref_dat;
i1 = 80;
do
{
if ( cur_unitref_addr->unitType != -1 )
{
unittype_offset = 8 * cur_unitref_addr->unitType;
pck_addr = *(a_allocated_pck_array_dword_4ADE40 + unittype_offset);
tab_addr = *(a_allocated_tab_array_dword_4ADE44 + unittype_offset);
cur_unitref_addr->pck_ref_off02 = pck_addr;
cur_unitref_addr->tab_ref_off06 = tab_addr;
}
cur_unitref_addr = (cur_unitref_addr + 124);
--i1;
}
while ( i1 );

:::: This called each time after setting up or loading UnitRef table. So according this code you can wipe these bytes without any effect, since these values overriden each time.--[[User:Volutar|Volutar]] 03:13, 21 February 2011 (EST)

:::::The save games contain a lot of stuff that's only relevant at runtime, on the basis that it was easier just to write (and then later read) these arrays straight to/from disk then it was to reformat them each time (sorta like how the entirety of MISDATA.DAT gets saved/loaded despite most of it being irrelevant most of the time). I'd been suspecting these to be pointers ever since Seb found the one in UnitPos, but I had no idea ''what'' they were pointing at, and I doubt I'd've ever worked it out. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 07:11, 21 February 2011 (EST)

== Offsets 0x30 & 0x34 ==

I've chopped out the majority of this page as it is no longer required. I'm keeping the heights chart in case it is required - I've also changed the "H-F" field to "H+F", as this actually makes sense.
[49] [51] "Tall" [48] | [49] [48]
Class Ht. Flt H+F Wide | Ht. Wide Area
--------- --- --- ---- ---- | --- ---- ----
Sectoid 16 0 16 2 | 16 2 32 Area=Ht.*Wide
Celatid 12 6 18 3 | 12 3 36
Hovertank* 12 6 18 4 | 12 4 48
Silacoid 10 0 10 5 | 10 5 50
Snakeman 18 0 18 3 | 18 3 54
Zombie 18 0 18 3 | 18 3 54
Cyberdisc 15 2 17 4 | 15 4 60
Ethereal 20 0 20 3 | 20 3 60 ''All Hover/Tanks in their
Chryssalid 21 0 21 3 | 21 3 63 ''class assumed to be same
Civilian 21 2 23 3 | 21 3 63 ''altho not tested yet
Floater 21 2 23 3 | 21 3 63
Muton 21 0 21 3 | 21 3 63
Tank* 16 0 16 4 | 16 4 64
Soldier 22 0 22 3 | 22 3 66
Reaper 23 0 23 4 | 23 4 92
Sectopod 23 0 23 4 | 23 4 92

Anyway, unitref[48] and unitref[52] remain somewhat of a mystery. Thus far we've assumed them to be the unit's width. Today I tried tinkering with [48] to see of this was correct. As I cranked it up, I found no change in my accuracy, or as to how the Sectoid target blocked line of fire to the tiles behind it.

When it reached the value of 37, however, the alien disappeared! I could not view it regardless of distance. In fact, I could even fire right through the tile it was standing on with no obstruction. The only sign that the alien was still there was the fact that my unit could not stand on the same square.

I lowered [48] a bit and tried viewing the alien from different distances, and found that it appeared in the same way as it usually would, regardless of the value used. It's simply the case that going to 37 or above makes the alien invisible.

I also tweaked [52] a bit, but found that it seemed to have no similar effects, if any at all.

Although I haven't tested this any further as yet, it might be possible to use this effect in reverse - Create an 'invisible' X-Com unit, and use it to observe how aliens act when they think we're not looking.

- [[User:Bomb Bloke|Bomb Bloke]] 00:44, 31 July 2006 (PDT)

----

I have a strong belief that offset 48 is nothing else but the loftemps.dat entry used for collision checking with bullets. A first check is done against the unit height (taking into account floating height, terrain height, kneeling). If the check is OK, the loftemps entry is then used as a final check (effectively treating the unit as a cylinder). I'll try to decypher the code further. If others want to have a look, the code is around here:
.text:004116AE 8B 15 5C 28 4A 00 mov edx, pUnitPos
...
[[User:Seb76|Seb76]] 13:24, 10 April 2008 (PDT)

----

I'm inclined to agree with you, though I'm not much good at reading through executable code. :( I hit on the same idea on my [[User_talk:Bomb_Bloke|talk page]]... I've got some notes in there about how I think the firing system works, if you could find code to back it up I'd be a happy boy.

It's something of a long winded work-in-progress ramble, and I'm sure some parts are confusing and/or dead wrong, but with any luck you can make some sort of sense of it. :) - [[User:Bomb Bloke|Bomb Bloke]] 18:34, 11 April 2008 (PDT)

----

[[Image:Loftemps.png|thumb|right]]I mentionned it earlier but got no real feedback so I'm adding a new section for it ;)
It looks like it is the loftemps entry used for collision detection with bullets. The main page says that setting it to 37 make the shots go right through the guys. If you have a look at the entry, you'll see why... The interesting thing is that the big units do not have special entries (unitref is common for all 4 parts so it would not have been possible to do otherwise) so a shot should be able to go through them (between the 4 parts). However, for the shot to be almost horizontal (or vertical) and traveling at the frontier between tiles (to go between the 4 "collision" circles), the shot should come from far far away so it is not likely to happened. Also depending on how the visibility check is performed, it may explain why alien suddenly disappeared when messing with the value (see discussion upper in this page). I suspect it is done using some kind of raytracing between the center of the 2 tiles (between the current unit and the target); so if the loftemps entry for the target has a "hole" in its center, it may become invisible. [[User:Seb76|Seb76]] 07:00, 1 June 2008 (PDT)

----

I just edited unitref 048 and 052 of all my soldiers to 0 and the aliens never tried to shoot at me. When I edited 048 to 0 for all the Sectoids on a mission, my soldiers couldn't see them anymore (only takes effect the following round if edited in unitef.dat, but surprisingly aliens remain visible to you during their movement phase). Since loftemps 0 is an empty cell, the results make perfect sense. A value of 76 (both 48&52) makes aliens disappear too. I'm not sure what the threshold is for disappearing, but a 3x3 block (loftemps 1) is still enough to be seen. --[[User:Zombie|Zombie]] 15:08, 17 August 2008 (PDT)

----

Am I understanding correctly... for purposes of shots hitting, we're all "barrels" with a specific diameter (i.e. [[LOFTEMPS.DAT]] 2-5), height ([49]), and distance (float) off the ground ([51])? Right or wrong, it sounds like this is finally pretty sown up, excellent work. We could update the page's entries. I wonder why they repeated this value twice (i.e. [48] and [52] always the same)... maybe they once considered the possibility of a unit whose diameter can change from turn to turn? If so, some other heretofore unfathomable UNITREF bit or byte may have been intended to dictate whether they're currently using the diameter at [48] or [52]. -[[User:MikeTheRed|MikeTheRed]] 17:06, 17 August 2008 (PDT)

----

While I've no problem believing [48] is a LOF template reference, I hadn't added it to the main page because I wanted to be sure as to it's relationship with [52].

See, at present, all we know about [52] is that it's the same as [48]. We haven't seen any effects from changing it.

What I ''suspect'' is that one offset might be used for shots traveling along an angle parallel to the target, and one offset might be used for shots traveling perpendicular. This would basically allow units to be effectively oval shaped (or it would, if [48] and [52] weren't the same for all units).

Just one of those things that I never got around to finishing the testing on. Would be dead easy to check, though.

There's still a little more to be researched before the entirety of the firing system is understood (see my talk page for a rambling explanation as to what IS known), but that's pretty much the basics of it.

- [[User:Bomb Bloke|Bomb Bloke]] 19:51, 17 August 2008 (PDT)

----

BB and others, see my edits for [48]. Does it make sense? In particular, I estimated pixel width from that little LOFTEMPS .png by magnifying it a ton. Any and all comments or edits welcomed. It's interesting that the silacoid has the highest width, but a low cross-section - did anyone see the Star Trek TOS show with the very short, wide silicon aliens? -[[User:MikeTheRed|MikeTheRed]] 22:53, 23 August 2008 (PDT)

----

Yes, you got the LOF widths correct. Though as you mentioned, they're only accurate assuming you're firing head on at your targets (as the templates aren't perfect circles, their width varies from other angles).

I threw in the kneeling soldier stats and made a note concerning large units.

- [[User:Bomb Bloke|Bomb Bloke]] 22:21, 24 August 2008 (PDT)

== Offset 0x3C ==

I have a gut feeling it is related to the panic/berserk status of the unit... Any volunteer for testing? [[User:Seb76|Seb76]] 10:36, 22 March 2008 (PDT)

----

Made a save where all soldiers had no morale. Ended turn, most of them panicked etc. Saved the game but that offset still came up as 0. Might only be flagged at runtime.

- [[User:Bomb Bloke|Bomb Bloke]] 18:01, 26 May 2008 (PDT)

----

I checked and indeed the game sets and clears it in the same turn so it is always 0 in a savegame and hence there is no 'black box' way of confirming it. I can provide disassembly screenshots if you want proofs however ;) [[User:Seb76|Seb76]] 05:45, 28 May 2008 (PDT)
:Actually after some thinking, it _might_ be possible... If you set the value to 3 for all entries, everyone may go berserk, with 2 they should run in fear and 1, they'll just crap their pants in place... [[User:Seb76|Seb76]] 07:09, 28 May 2008 (PDT)

----

I tried it, and indeed my units did exactly that (at the start of their next turn - not that of the aliens).

- [[User:Bomb Bloke|Bomb Bloke]] 21:08, 28 May 2008 (PDT)

== Offset 0x4A (74) ==
It seems to be some kind of AI mode, which has 4 phases - 0,1,2 and 3. Code at .text:004016C0 (CE version) shows its range. --[[User:Volutar|Volutar]] 02:00, 21 February 2011 (EST)

----

While taking a browse through the [http://www.strategycore.co.uk/files/index.php?dlid=776 pre-release game executable], I found these strings listed together in a clump:

*Patrol
*Sniper
*Combat
*Escape
*Guard
*GoUfo
*Finding Route
*Set Patrol Point
*Moving
*Firing
*Evaluating Mode
*Final Facing
*Attack Attempt
*Find Fire Point
*Select Target
*Find Cover
*Partial Cover

It struck me that the first few could relate to AI modes. Some aliens are known to choose a route node and stick with it (gaurding), and when unarmed, they'll usually run away (escaping); aliens will patrol when they don't know the location of X-COM units, though this seems to halt when turn 20 passes. Presumably these activities can be mapped to the four values. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:20, 6 February 2011 (EST)

That's a great find, BBloke. I never looked at the demo exe. While the debug fonction was deleted in the release, it permits to locate the basic AI fonctions in the code. So we have: AI_patrol_mode (0x4A = 0) at 0x0407D60, AI_Sniper_mode (0x4A = 1) at 0x04081A0, AI_combat_mode (0x4A = 2) at 0x0408430, AI_escape_mode (0x4A = 3) at 0x04067F0 and even the AI_evaluation_mode at 0x0408430, which fills offset 0x4A when it is equal to something else. Other functions can be found as well with the debug info. Fantastic. Now we could try to make AI take cover from time to time, instead of making a stupidly exposed target.--[[User:Kyrub|Kyrub]] 06:02, 13 April 2011 (EDT)

== Offset 0x6F ==
This offset seems to be corresponding for runtime "Attacking" state, not final /0 for unit name. When 1 units drawn with weapon helded in fire position, when 0 - ordinary.--[[User:Volutar|Volutar]] 17:15, 26 February 2011 (EST)
:Well spotted. :) -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 00:43, 27 February 2011 (EST)

== Offset 0x70 (112) ==
It seems to be used in realtime only as "already acted" flag for civilian and alien units...--[[User:Volutar|Volutar]] 09:19, 27 March 2011 (EDT)

== Offset 0x71 ==
Hmm, the code checks this offset before applying stun damage... It looks more like an 'immune to stun damage' flag then. Strange... [[User:Seb76|Seb76]] 13:48, 7 April 2008 (PDT)

----

By memory, the only things that use this are X-Com HWPs (which shouldn't have stun applied). It does toggle inventory access as described though it wouldn't surprise me if it also toggled stun damage.

- [[User:Bomb Bloke|Bomb Bloke]] 05:46, 8 April 2008 (PDT)

:OK, I located the check and it is exactly what happens. BTW, if you want to try something, try to patch this with nops (0x90):
.text:00412A20 A8 40 test al, 40h
.text:00412A22 0F 85 00 02 00 00 jnz exit ; default
:It should enable inventory screen for memory controlled units (could not test since I have no save files with psy units...) [[User:Seb76|Seb76]] 11:37, 8 April 2008 (PDT)

:: So, to be clear, is this the location of the inventory screen check for mind controlled alien units? And here you are disabling the check by overwriting it with NOPS? Is there a nearby section of code that does the same check for tanks? I would like to be able to override this tank inventory check in order to play with [[User:Spike#Tank mods|Tank mods]]. It looks like NOPing the check logic is the right way to do it, since if instead I toggled the 0x71 flag for the tanks, they would than also become vulnerable to Stun? Though I also I think read somewhere that if you get to the inventory screen of a tank, the game crashes. It doesn't crash if you get to the inventory screen of an Alien large unit via the Alien Inventory or Alien Pets hacks (not sure which) in your UFOExtender. I was able to arm Reapers with dual Heavy Plasma or dual Blaster Launchers. (Unpleasant. They have 0% FA so they have to run up to you and spray with the Heavy Plasma. Not a problem with the Blaster Launcher.) [[User:Spike|Spike]] 13:59, 20 August 2009 (EDT)

== Offset 0x77 ==
This isn't field at all. It just ain't even initialized anywhere, so it's obviously a garbage field. I haven't found even one place where it be used...--[[User:Volutar|Volutar]] 06:52, 27 March 2011 (EDT)

== Offset 0xB ==
The value is used together as an offset to [[MCD|MCDData]] offset 39 (describing TUs required to cross a tile walking/flying/sliding) so it most likely represent the way the unit moves. Still needs testing. [[User:Seb76|Seb76]] 13:27, 23 May 2008 (PDT)

----

I took a look at it for Snakemen and Silacoids, it's still 0 (same as it is for everything else).

But that doesn't mean it remains at 0 when the game's running. Do you mean to say that the value here + 39 = the offset in the MCD array that says how many TUs were required to move past any given obstacles in the current map location?

(That is, you'd expect to see a 2 there for sliding units?)

- [[User:Bomb Bloke|Bomb Bloke]] 05:14, 25 May 2008 (PDT)

----

Yep, exactly like that. Also it checks if the value is 0xff and prevent movement in that case. I'll try a live check with a debugger when I encounter snakemen. Maybe it's a part of code that was implemented but not put into usage. [[User:Seb76|Seb76]] 05:20, 25 May 2008 (PDT)
:Did the check and the value is indeed zero even for snakemen... BTW, is the movement type really working? I mean has anybody ever checked that e.g. snakemen really use different TU amount for tiles where TU usage is not the same between crawling and walking? [[User:Seb76|Seb76]] 06:43, 25 May 2008 (PDT)

----

Truth be told I don't remember reading of anyone doing the tests, so I had a go myself.

I tried first with the Avenger ramp, stuck it up in the air and had soldiers walk/fly onto it. Made no effect to their TU usage.

Next I rigged a Snakeman mission in the arctic, stuck one of them in the middle of a pond. It wouldn't move on it's own, and I couldn't move it under mind control.

So then I set 0xB to 2 just for that unit, and hey presto! Suddenly it was able to move freely, either under my control or otherwise. That's certainly the movement type flag... It's just not set in practise.

Still, now I'm wondering if 2 really was for sliders... It doesn't make sense that "fliers" (which I guess was supposed to include the likes of CyberDiscs, which "hover" even when on the ground) wouldn't be able to cross water, yet Snakemen could. Perhaps it should be the other way around?

- [[User:Bomb Bloke|Bomb Bloke]] 19:22, 25 May 2008 (PDT)

----

Note that there are some tiles that have 0 MP cost for sliders. - [[User:Zaimoni|Zaimoni]] 22:28, 25 May 2008 (CDT)

: Yeah, I guess that puts the clincher on it. Only fliers would really be totally unhindered by ground rubble. I've tweaked the MCD details page accordingly. - [[User:Bomb Bloke|Bomb Bloke]] 05:25, 26 May 2008 (PDT)

----

Hehe, I knew it couldn't be anything else but movement type. Yet another entry for known bugs ;) I'll check if it's possible to reenable the feature. It'll depends if it's a bug or if it was voluntarily removed I guess... [[User:Seb76|Seb76]] 04:37, 26 May 2008 (PDT)
: Did a quick check and can confirm what is said in [[GEOSCAPE.EXE#Alien_Stats|Alien Stats]] page. Offset 0xB is filled with the 3rd "unknown" value of alien stats. It is set to 0 for all entries. Could not find any other place where it could possibly be set to another value. [[User:Seb76|Seb76]] 05:17, 26 May 2008 (PDT)

----

So it's just a matter of tweaking that for all relevant units, then. However, I reckon it was left unused intentionally - I doubt the map files really contain enough variety to make it worth including.

- [[User:Bomb Bloke|Bomb Bloke]] 05:25, 26 May 2008 (PDT)

----

Since TFTD was done later with the same engine, perhaps it makes use of this? However, given that a different team made it ([http://www.lasersquadnemesis.com/AboutUs.htm Terror from the Deep was developed by Microprose using code licensed by Mythos]), developers may not have known the feature was available... [[User:Seb76|Seb76]] 07:25, 28 May 2008 (PDT)

----

I took a quick check, and sure enough found a Hallucinoid (the big flying squid thing) set to 2.

- [[User:Bomb Bloke|Bomb Bloke]] 21:31, 28 May 2008 (PDT)

== Offset 0x47 ==

The only use I could find is that of updating [[SOURCEMP.DAT|mobile light sources]] (or something like that) when the unit dies/is rendered unconscious. Could not find anything else about this flag. [[User:Seb76|Seb76]] 05:24, 29 May 2008 (PDT)

:Good work there. As a general statement, can I say - I've been waiting for somebody to disassemble XCOM :) -[[User:MikeTheRed|MikeTheRed]] 21:18, 30 May 2008 (PDT)

I sat down to do some tests with this, but didn't bother too read to closely... I was selecting/moving units around when I probably shoulda been shooting at them.

Oh well. For the record:

Moving a unit causes a light check to be done on all your units. You may not see this light if one of your units is standing in a fog-of-war covered zone (say you just mind controlled an alien and haven't selected it yet).

Selecting a unit does a fog-of-war check concerning what it can see, but does not do a light check.

Whatever this offset is has no effect on the light produced by your units, or the aliens units. Your active guys ALWAYS fully illuminate their tile (even if this is 0) and the aliens provide no illumination at all. Will have to do some tests concerning what happens when you shoot them, but it seems odd: If a unit is dead I'd expect a full light check to be done, since the unit isn't "active" it won't produce light, so I don't see how this offset is helpful there... You can't just remove the light values for this one unit because you might interfere with other nearby light sources, so you really have to calculate them all from scratch.

But likewise it seems [[MCD|MCD[58/3A]]] is similar; a street lamp is set to 1, a normal lamp to 10, but they both provide maximum illumination.

Perhaps the programmers changed their mind about the lighting system at some point? Dunno.

- [[User:Bomb Bloke|Bomb Bloke]] 07:03, 20 June 2008 (PDT)

:Some of your note reminds me of what I wrote at [[Night_Missions#Personal_lighting]] ... does that help any? (probably not) -[[User:MikeTheRed|MikeTheRed]] 16:01, 20 June 2008 (PDT)

== On Fire Flag or Timer ? ==

Do we have any idea where a flag is set to show the unit is on fire? This is persistent between saved games so it must be stored in a file somewhere. Possibly UNITPOS.DAT? It could be a flag, but more likely is either a countdown timer for turns remaining on fire, (values 1-5?), or a "what turn do I stop being on fire" timer value (like a grenade timer).

I have uploaded a saved game file with a burning Aquatoid if anyone wants to take a look. I just don't have the right diff tools. Maybe with the Hex Workshop template... [[User:Spike|Spike]] 19:05, 10 March 2009 (CDT)

:Offset 114 in Unitref holds that data. --[[User:Zombie|Zombie]] 19:15, 10 March 2009 (CDT)

:: Sorry I did not read the article carefully enough. It's in there. [[User:Spike|Spike]] 19:16, 10 March 2009 (CDT)

114 / 72: If not 0, then unit is on fire, and will burn for this amount of turns.

== Floating Civilians ==

Civilians float 2 units off the ground, like Floaters and Cyberdisks. Soldiers don't. Should we consider this to be a bug? [[User:Spike|Spike]] 13:41, 20 August 2009 (EDT)

:Probably. I really doubt it's an intentional feature. --[[User:Zombie|Zombie]] 23:09, 20 August 2009 (EDT)

== Remembering morale vs health and pain killers ==

The game remembers whether a health loss has or has not been used to regain morale via pain killers. Presumably this is stored somewhere in UNITREF.DAT? [[User:Spike|Spike]] 10:30, 5 September 2009 (EDT)

== TFTD ==

It appears the name string starts at the same point in TFTD save points, which leads me to believe that the extra bytes are probably just appended at the end of the file, without much changing in the first 124 bytes per entry, anyone know what these extra 8 bytes might represent? - [[User:Hatfarm|Hatfarm]]

----

They are indeed appended. My battlescape editor deals with TFTD's UnitRef by just adjusting for the larger record size, and then ignoring the extra bytes completely - didn't need to do anything else to make it all match up. I've yet to actually look at some sample values in order to work out what they might be for.

Incidently, you can insert signatures into your postings using four tildes (<nowiki>~~~~</nowiki>). - [[User:Bomb Bloke|Bomb Bloke]] 21:48, 20 January 2010 (EST)

== TFTD's extra bytes ==

It appears that byte 126 is a bit flag array of some sort as I have mostly seen values of 1 and 0 for it, but others have appeared. I saved a single mission at several different times and each one had 0 or 1, but a terror mission save had some different values for this, Like 0x20 and 0x4F. I tried adjusting it and checking the saved game, but nothing seemed to change...

Byte 124 I've seen values of 0,4,6,7,0x0A and 0x0E. No idea what these mean, and changing them did not do anything for me.

They appear to only be for Soldiers as well, none of the aliens in any of my saved games have values for these.
[[User:Hatfarm|Hatfarm]] 15:16, 5 June 2010 (EDT)

----

124 may have something to do with the air-bubbles that trickle up from soldiers when they're underwater - an animation counter, similar to offset 8 of [[SMOKREF.DAT]], but with a higher range (0-15, probably). Granted, there's no real reason to keep track of bubbles when saving the game, but they have to be tracked somewhere at run-time, and this seems to be the logical place (the save files are just raw dumps of RAM anyway).

In theory, if you set this to the same value for all soldiers (say 5), on loading the game, they'd all have identical air bubbles over their heads. - [[User:Bomb Bloke|Bomb Bloke]] 22:26, 5 June 2010 (EDT)

----

You're right, I set them all to 5 and they were all in the same place bubble wise,. However, they don't all "rebubble" at the same time. Good call BB. [[User:Hatfarm|Hatfarm]] 02:16, 12 June 2010 (EDT)

----

I'd guess they "rebubble" randomly, though it may be a rather more elaborate setup - bubbles might appear more often for soldiers with lower stamina levels, maybe, to indicate they're out of breath.

Unfortunately, I can't think of anything else TFTD adds that would warrant using those extra bytes at the end of the file. - [[User:Bomb Bloke|Bomb Bloke]] 05:20, 12 June 2010 (EDT)

----

I'm guessing it's a 2 byte count at least, which would account for the 124 and 125 bytes. If I think of anything for the others, I'll let you know. [[User:Hatfarm|Hatfarm]] 01:07, 13 June 2010 (EDT)

Talk:UNITREF.DAT

2011-04-13T10:02:56Z

Kyrub: /* Offset 0x4A (74) */

Anyone who has it - can we get listings of values for various aliens on the Unitref page, for some of the variables found in both Unitref and the Geoscape [[Talk:Overviews_of_Aliens|Alien stats]]? E.g. energy recharge (Unitref[35]), energy loss [45]... like what Danial did for Height. Some of it might go to NKF's redesigned [[Soldier]] page. I am trying to flesh out the Geoscape data so I know what everything is there (and can then extend it across difficulty levels). It has unlabelled fields with values, some of which I know must be these values... but there's no list for me to compare against. Thanks if you can help! ---[[User:MikeTheRed|MikeTheRed]] 19:37, 25 Nov 2005 (PST)

P.S. We probably should clean up this Discussion some time. I will if I find the time to make sure everything has made its way to wherever it should go.

----

== Offsets 0x02 - 0x09 ==

It's obvious from unit drawing functions (reversed ones) it's a PCK and TAB spritepack reference address (DWORD).

_pck = (int)unitref_addr->pck_ref;
_tab = (int)unitref_addr->tab_ref;
...
if ( (_WORD)handob != 255 )
xc_BF_Draw_Battlescape_shaded_Sprite((char)v18, (int)vf_handob_pck, (int)vf_handob_tab, v21, v23, shade);
xc_BF_Draw_Battlescape_shaded_Sprite(sprite_num1, _pck, _tab, y0, x0, shade);
--[[User:Volutar|Volutar]] 09:43, 20 February 2011 (EST)

:So you're saying these values point to where the PCK/TAB files used by the unit in concern have been loaded into RAM, similar to how [[UNITPOS.DAT|UnitPos[4-7]]] points to where the UnitRef record is? -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 17:56, 20 February 2011 (EST)
::Exactly. They are simple 32bit pointers to RAM location where exact unit PCK/TAB loaded (I don't know how they worked for DOS version - I guess the same way). You could notice the lowest bytes (2th and 6th) are aligned to 4, as for all memory locations. --[[User:Volutar|Volutar]] 01:13, 21 February 2011 (EST)

::: Since the saves are interchangeable between the Dos and Window versions, and since the Dos version uses the Dos4gw engine to handle the exapanded memory, it could very well be a 32-bit pointer.

::: Still, memory pointers? That would mean these values are used at run-time only and these are just dumps of whatever it was at the time the save was made. Since whatever memory allocation function they used back then (I'm guessing malloc() ) would be storing the graphics at different offsets each time the tactical engine boots up, these would have to be replaced anyway. -[[User:NKF|NKF]] 02:00, 21 February 2011 (EST)

.text:004178EC
cur_unitref_addr = vf_unitref_dat;
i1 = 80;
do
{
if ( cur_unitref_addr->unitType != -1 )
{
unittype_offset = 8 * cur_unitref_addr->unitType;
pck_addr = *(a_allocated_pck_array_dword_4ADE40 + unittype_offset);
tab_addr = *(a_allocated_tab_array_dword_4ADE44 + unittype_offset);
cur_unitref_addr->pck_ref_off02 = pck_addr;
cur_unitref_addr->tab_ref_off06 = tab_addr;
}
cur_unitref_addr = (cur_unitref_addr + 124);
--i1;
}
while ( i1 );

:::: This called each time after setting up or loading UnitRef table. So according this code you can wipe these bytes without any effect, since these values overriden each time.--[[User:Volutar|Volutar]] 03:13, 21 February 2011 (EST)

:::::The save games contain a lot of stuff that's only relevant at runtime, on the basis that it was easier just to write (and then later read) these arrays straight to/from disk then it was to reformat them each time (sorta like how the entirety of MISDATA.DAT gets saved/loaded despite most of it being irrelevant most of the time). I'd been suspecting these to be pointers ever since Seb found the one in UnitPos, but I had no idea ''what'' they were pointing at, and I doubt I'd've ever worked it out. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 07:11, 21 February 2011 (EST)

== Offsets 0x30 & 0x34 ==

I've chopped out the majority of this page as it is no longer required. I'm keeping the heights chart in case it is required - I've also changed the "H-F" field to "H+F", as this actually makes sense.
[49] [51] "Tall" [48] | [49] [48]
Class Ht. Flt H+F Wide | Ht. Wide Area
--------- --- --- ---- ---- | --- ---- ----
Sectoid 16 0 16 2 | 16 2 32 Area=Ht.*Wide
Celatid 12 6 18 3 | 12 3 36
Hovertank* 12 6 18 4 | 12 4 48
Silacoid 10 0 10 5 | 10 5 50
Snakeman 18 0 18 3 | 18 3 54
Zombie 18 0 18 3 | 18 3 54
Cyberdisc 15 2 17 4 | 15 4 60
Ethereal 20 0 20 3 | 20 3 60 ''All Hover/Tanks in their
Chryssalid 21 0 21 3 | 21 3 63 ''class assumed to be same
Civilian 21 2 23 3 | 21 3 63 ''altho not tested yet
Floater 21 2 23 3 | 21 3 63
Muton 21 0 21 3 | 21 3 63
Tank* 16 0 16 4 | 16 4 64
Soldier 22 0 22 3 | 22 3 66
Reaper 23 0 23 4 | 23 4 92
Sectopod 23 0 23 4 | 23 4 92

Anyway, unitref[48] and unitref[52] remain somewhat of a mystery. Thus far we've assumed them to be the unit's width. Today I tried tinkering with [48] to see of this was correct. As I cranked it up, I found no change in my accuracy, or as to how the Sectoid target blocked line of fire to the tiles behind it.

When it reached the value of 37, however, the alien disappeared! I could not view it regardless of distance. In fact, I could even fire right through the tile it was standing on with no obstruction. The only sign that the alien was still there was the fact that my unit could not stand on the same square.

I lowered [48] a bit and tried viewing the alien from different distances, and found that it appeared in the same way as it usually would, regardless of the value used. It's simply the case that going to 37 or above makes the alien invisible.

I also tweaked [52] a bit, but found that it seemed to have no similar effects, if any at all.

Although I haven't tested this any further as yet, it might be possible to use this effect in reverse - Create an 'invisible' X-Com unit, and use it to observe how aliens act when they think we're not looking.

- [[User:Bomb Bloke|Bomb Bloke]] 00:44, 31 July 2006 (PDT)

----

I have a strong belief that offset 48 is nothing else but the loftemps.dat entry used for collision checking with bullets. A first check is done against the unit height (taking into account floating height, terrain height, kneeling). If the check is OK, the loftemps entry is then used as a final check (effectively treating the unit as a cylinder). I'll try to decypher the code further. If others want to have a look, the code is around here:
.text:004116AE 8B 15 5C 28 4A 00 mov edx, pUnitPos
...
[[User:Seb76|Seb76]] 13:24, 10 April 2008 (PDT)

----

I'm inclined to agree with you, though I'm not much good at reading through executable code. :( I hit on the same idea on my [[User_talk:Bomb_Bloke|talk page]]... I've got some notes in there about how I think the firing system works, if you could find code to back it up I'd be a happy boy.

It's something of a long winded work-in-progress ramble, and I'm sure some parts are confusing and/or dead wrong, but with any luck you can make some sort of sense of it. :) - [[User:Bomb Bloke|Bomb Bloke]] 18:34, 11 April 2008 (PDT)

----

[[Image:Loftemps.png|thumb|right]]I mentionned it earlier but got no real feedback so I'm adding a new section for it ;)
It looks like it is the loftemps entry used for collision detection with bullets. The main page says that setting it to 37 make the shots go right through the guys. If you have a look at the entry, you'll see why... The interesting thing is that the big units do not have special entries (unitref is common for all 4 parts so it would not have been possible to do otherwise) so a shot should be able to go through them (between the 4 parts). However, for the shot to be almost horizontal (or vertical) and traveling at the frontier between tiles (to go between the 4 "collision" circles), the shot should come from far far away so it is not likely to happened. Also depending on how the visibility check is performed, it may explain why alien suddenly disappeared when messing with the value (see discussion upper in this page). I suspect it is done using some kind of raytracing between the center of the 2 tiles (between the current unit and the target); so if the loftemps entry for the target has a "hole" in its center, it may become invisible. [[User:Seb76|Seb76]] 07:00, 1 June 2008 (PDT)

----

I just edited unitref 048 and 052 of all my soldiers to 0 and the aliens never tried to shoot at me. When I edited 048 to 0 for all the Sectoids on a mission, my soldiers couldn't see them anymore (only takes effect the following round if edited in unitef.dat, but surprisingly aliens remain visible to you during their movement phase). Since loftemps 0 is an empty cell, the results make perfect sense. A value of 76 (both 48&52) makes aliens disappear too. I'm not sure what the threshold is for disappearing, but a 3x3 block (loftemps 1) is still enough to be seen. --[[User:Zombie|Zombie]] 15:08, 17 August 2008 (PDT)

----

Am I understanding correctly... for purposes of shots hitting, we're all "barrels" with a specific diameter (i.e. [[LOFTEMPS.DAT]] 2-5), height ([49]), and distance (float) off the ground ([51])? Right or wrong, it sounds like this is finally pretty sown up, excellent work. We could update the page's entries. I wonder why they repeated this value twice (i.e. [48] and [52] always the same)... maybe they once considered the possibility of a unit whose diameter can change from turn to turn? If so, some other heretofore unfathomable UNITREF bit or byte may have been intended to dictate whether they're currently using the diameter at [48] or [52]. -[[User:MikeTheRed|MikeTheRed]] 17:06, 17 August 2008 (PDT)

----

While I've no problem believing [48] is a LOF template reference, I hadn't added it to the main page because I wanted to be sure as to it's relationship with [52].

See, at present, all we know about [52] is that it's the same as [48]. We haven't seen any effects from changing it.

What I ''suspect'' is that one offset might be used for shots traveling along an angle parallel to the target, and one offset might be used for shots traveling perpendicular. This would basically allow units to be effectively oval shaped (or it would, if [48] and [52] weren't the same for all units).

Just one of those things that I never got around to finishing the testing on. Would be dead easy to check, though.

There's still a little more to be researched before the entirety of the firing system is understood (see my talk page for a rambling explanation as to what IS known), but that's pretty much the basics of it.

- [[User:Bomb Bloke|Bomb Bloke]] 19:51, 17 August 2008 (PDT)

----

BB and others, see my edits for [48]. Does it make sense? In particular, I estimated pixel width from that little LOFTEMPS .png by magnifying it a ton. Any and all comments or edits welcomed. It's interesting that the silacoid has the highest width, but a low cross-section - did anyone see the Star Trek TOS show with the very short, wide silicon aliens? -[[User:MikeTheRed|MikeTheRed]] 22:53, 23 August 2008 (PDT)

----

Yes, you got the LOF widths correct. Though as you mentioned, they're only accurate assuming you're firing head on at your targets (as the templates aren't perfect circles, their width varies from other angles).

I threw in the kneeling soldier stats and made a note concerning large units.

- [[User:Bomb Bloke|Bomb Bloke]] 22:21, 24 August 2008 (PDT)

== Offset 0x3C ==

I have a gut feeling it is related to the panic/berserk status of the unit... Any volunteer for testing? [[User:Seb76|Seb76]] 10:36, 22 March 2008 (PDT)

----

Made a save where all soldiers had no morale. Ended turn, most of them panicked etc. Saved the game but that offset still came up as 0. Might only be flagged at runtime.

- [[User:Bomb Bloke|Bomb Bloke]] 18:01, 26 May 2008 (PDT)

----

I checked and indeed the game sets and clears it in the same turn so it is always 0 in a savegame and hence there is no 'black box' way of confirming it. I can provide disassembly screenshots if you want proofs however ;) [[User:Seb76|Seb76]] 05:45, 28 May 2008 (PDT)
:Actually after some thinking, it _might_ be possible... If you set the value to 3 for all entries, everyone may go berserk, with 2 they should run in fear and 1, they'll just crap their pants in place... [[User:Seb76|Seb76]] 07:09, 28 May 2008 (PDT)

----

I tried it, and indeed my units did exactly that (at the start of their next turn - not that of the aliens).

- [[User:Bomb Bloke|Bomb Bloke]] 21:08, 28 May 2008 (PDT)

== Offset 0x4A (74) ==
It seems to be some kind of AI mode, which has 4 phases - 0,1,2 and 3. Code at .text:004016C0 (CE version) shows its range. --[[User:Volutar|Volutar]] 02:00, 21 February 2011 (EST)

----

While taking a browse through the [http://www.strategycore.co.uk/files/index.php?dlid=776 pre-release game executable], I found these strings listed together in a clump:

*Patrol
*Sniper
*Combat
*Escape
*Guard
*GoUfo
*Finding Route
*Set Patrol Point
*Moving
*Firing
*Evaluating Mode
*Final Facing
*Attack Attempt
*Find Fire Point
*Select Target
*Find Cover
*Partial Cover

It struck me that the first few could relate to AI modes. Some aliens are known to choose a route node and stick with it (gaurding), and when unarmed, they'll usually run away (escaping); aliens will patrol when they don't know the location of X-COM units, though this seems to halt when turn 20 passes. Presumably these activities can be mapped to the four values. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:20, 6 February 2011 (EST)

That's a great find, BBloke. I never looked at the demo exe. While the debug fonction was deleted in the release, it permits to locate the basic AI fonctions in the code. So we have: AI_patrol_mode (0x4A = 0) at 0x0407D60, AI_Sniper_mode (0x4A = 1) at 0x04081A0, AI_combat_mode (0x4A = 2) at 0x0408430, AI_escape_mode (0x4A = 3) at 0x04067F0 and even the AI_evaluation_mode at 0x0408430, which fills offset 0x4A when it is equal to something else. Other functions can be found as well with the debug info. Fantastic. Now we could try to make AI take cover from time to time, instead of making a making a stupidly exposed target.--[[User:Kyrub|Kyrub]] 06:02, 13 April 2011 (EDT)

== Offset 0x6F ==
This offset seems to be corresponding for runtime "Attacking" state, not final /0 for unit name. When 1 units drawn with weapon helded in fire position, when 0 - ordinary.--[[User:Volutar|Volutar]] 17:15, 26 February 2011 (EST)
:Well spotted. :) -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 00:43, 27 February 2011 (EST)

== Offset 0x70 (112) ==
It seems to be used in realtime only as "already acted" flag for civilian and alien units...--[[User:Volutar|Volutar]] 09:19, 27 March 2011 (EDT)

== Offset 0x71 ==
Hmm, the code checks this offset before applying stun damage... It looks more like an 'immune to stun damage' flag then. Strange... [[User:Seb76|Seb76]] 13:48, 7 April 2008 (PDT)

----

By memory, the only things that use this are X-Com HWPs (which shouldn't have stun applied). It does toggle inventory access as described though it wouldn't surprise me if it also toggled stun damage.

- [[User:Bomb Bloke|Bomb Bloke]] 05:46, 8 April 2008 (PDT)

:OK, I located the check and it is exactly what happens. BTW, if you want to try something, try to patch this with nops (0x90):
.text:00412A20 A8 40 test al, 40h
.text:00412A22 0F 85 00 02 00 00 jnz exit ; default
:It should enable inventory screen for memory controlled units (could not test since I have no save files with psy units...) [[User:Seb76|Seb76]] 11:37, 8 April 2008 (PDT)

:: So, to be clear, is this the location of the inventory screen check for mind controlled alien units? And here you are disabling the check by overwriting it with NOPS? Is there a nearby section of code that does the same check for tanks? I would like to be able to override this tank inventory check in order to play with [[User:Spike#Tank mods|Tank mods]]. It looks like NOPing the check logic is the right way to do it, since if instead I toggled the 0x71 flag for the tanks, they would than also become vulnerable to Stun? Though I also I think read somewhere that if you get to the inventory screen of a tank, the game crashes. It doesn't crash if you get to the inventory screen of an Alien large unit via the Alien Inventory or Alien Pets hacks (not sure which) in your UFOExtender. I was able to arm Reapers with dual Heavy Plasma or dual Blaster Launchers. (Unpleasant. They have 0% FA so they have to run up to you and spray with the Heavy Plasma. Not a problem with the Blaster Launcher.) [[User:Spike|Spike]] 13:59, 20 August 2009 (EDT)

== Offset 0x77 ==
This isn't field at all. It just ain't even initialized anywhere, so it's obviously a garbage field. I haven't found even one place where it be used...--[[User:Volutar|Volutar]] 06:52, 27 March 2011 (EDT)

== Offset 0xB ==
The value is used together as an offset to [[MCD|MCDData]] offset 39 (describing TUs required to cross a tile walking/flying/sliding) so it most likely represent the way the unit moves. Still needs testing. [[User:Seb76|Seb76]] 13:27, 23 May 2008 (PDT)

----

I took a look at it for Snakemen and Silacoids, it's still 0 (same as it is for everything else).

But that doesn't mean it remains at 0 when the game's running. Do you mean to say that the value here + 39 = the offset in the MCD array that says how many TUs were required to move past any given obstacles in the current map location?

(That is, you'd expect to see a 2 there for sliding units?)

- [[User:Bomb Bloke|Bomb Bloke]] 05:14, 25 May 2008 (PDT)

----

Yep, exactly like that. Also it checks if the value is 0xff and prevent movement in that case. I'll try a live check with a debugger when I encounter snakemen. Maybe it's a part of code that was implemented but not put into usage. [[User:Seb76|Seb76]] 05:20, 25 May 2008 (PDT)
:Did the check and the value is indeed zero even for snakemen... BTW, is the movement type really working? I mean has anybody ever checked that e.g. snakemen really use different TU amount for tiles where TU usage is not the same between crawling and walking? [[User:Seb76|Seb76]] 06:43, 25 May 2008 (PDT)

----

Truth be told I don't remember reading of anyone doing the tests, so I had a go myself.

I tried first with the Avenger ramp, stuck it up in the air and had soldiers walk/fly onto it. Made no effect to their TU usage.

Next I rigged a Snakeman mission in the arctic, stuck one of them in the middle of a pond. It wouldn't move on it's own, and I couldn't move it under mind control.

So then I set 0xB to 2 just for that unit, and hey presto! Suddenly it was able to move freely, either under my control or otherwise. That's certainly the movement type flag... It's just not set in practise.

Still, now I'm wondering if 2 really was for sliders... It doesn't make sense that "fliers" (which I guess was supposed to include the likes of CyberDiscs, which "hover" even when on the ground) wouldn't be able to cross water, yet Snakemen could. Perhaps it should be the other way around?

- [[User:Bomb Bloke|Bomb Bloke]] 19:22, 25 May 2008 (PDT)

----

Note that there are some tiles that have 0 MP cost for sliders. - [[User:Zaimoni|Zaimoni]] 22:28, 25 May 2008 (CDT)

: Yeah, I guess that puts the clincher on it. Only fliers would really be totally unhindered by ground rubble. I've tweaked the MCD details page accordingly. - [[User:Bomb Bloke|Bomb Bloke]] 05:25, 26 May 2008 (PDT)

----

Hehe, I knew it couldn't be anything else but movement type. Yet another entry for known bugs ;) I'll check if it's possible to reenable the feature. It'll depends if it's a bug or if it was voluntarily removed I guess... [[User:Seb76|Seb76]] 04:37, 26 May 2008 (PDT)
: Did a quick check and can confirm what is said in [[GEOSCAPE.EXE#Alien_Stats|Alien Stats]] page. Offset 0xB is filled with the 3rd "unknown" value of alien stats. It is set to 0 for all entries. Could not find any other place where it could possibly be set to another value. [[User:Seb76|Seb76]] 05:17, 26 May 2008 (PDT)

----

So it's just a matter of tweaking that for all relevant units, then. However, I reckon it was left unused intentionally - I doubt the map files really contain enough variety to make it worth including.

- [[User:Bomb Bloke|Bomb Bloke]] 05:25, 26 May 2008 (PDT)

----

Since TFTD was done later with the same engine, perhaps it makes use of this? However, given that a different team made it ([http://www.lasersquadnemesis.com/AboutUs.htm Terror from the Deep was developed by Microprose using code licensed by Mythos]), developers may not have known the feature was available... [[User:Seb76|Seb76]] 07:25, 28 May 2008 (PDT)

----

I took a quick check, and sure enough found a Hallucinoid (the big flying squid thing) set to 2.

- [[User:Bomb Bloke|Bomb Bloke]] 21:31, 28 May 2008 (PDT)

== Offset 0x47 ==

The only use I could find is that of updating [[SOURCEMP.DAT|mobile light sources]] (or something like that) when the unit dies/is rendered unconscious. Could not find anything else about this flag. [[User:Seb76|Seb76]] 05:24, 29 May 2008 (PDT)

:Good work there. As a general statement, can I say - I've been waiting for somebody to disassemble XCOM :) -[[User:MikeTheRed|MikeTheRed]] 21:18, 30 May 2008 (PDT)

I sat down to do some tests with this, but didn't bother too read to closely... I was selecting/moving units around when I probably shoulda been shooting at them.

Oh well. For the record:

Moving a unit causes a light check to be done on all your units. You may not see this light if one of your units is standing in a fog-of-war covered zone (say you just mind controlled an alien and haven't selected it yet).

Selecting a unit does a fog-of-war check concerning what it can see, but does not do a light check.

Whatever this offset is has no effect on the light produced by your units, or the aliens units. Your active guys ALWAYS fully illuminate their tile (even if this is 0) and the aliens provide no illumination at all. Will have to do some tests concerning what happens when you shoot them, but it seems odd: If a unit is dead I'd expect a full light check to be done, since the unit isn't "active" it won't produce light, so I don't see how this offset is helpful there... You can't just remove the light values for this one unit because you might interfere with other nearby light sources, so you really have to calculate them all from scratch.

But likewise it seems [[MCD|MCD[58/3A]]] is similar; a street lamp is set to 1, a normal lamp to 10, but they both provide maximum illumination.

Perhaps the programmers changed their mind about the lighting system at some point? Dunno.

- [[User:Bomb Bloke|Bomb Bloke]] 07:03, 20 June 2008 (PDT)

:Some of your note reminds me of what I wrote at [[Night_Missions#Personal_lighting]] ... does that help any? (probably not) -[[User:MikeTheRed|MikeTheRed]] 16:01, 20 June 2008 (PDT)

== On Fire Flag or Timer ? ==

Do we have any idea where a flag is set to show the unit is on fire? This is persistent between saved games so it must be stored in a file somewhere. Possibly UNITPOS.DAT? It could be a flag, but more likely is either a countdown timer for turns remaining on fire, (values 1-5?), or a "what turn do I stop being on fire" timer value (like a grenade timer).

I have uploaded a saved game file with a burning Aquatoid if anyone wants to take a look. I just don't have the right diff tools. Maybe with the Hex Workshop template... [[User:Spike|Spike]] 19:05, 10 March 2009 (CDT)

:Offset 114 in Unitref holds that data. --[[User:Zombie|Zombie]] 19:15, 10 March 2009 (CDT)

:: Sorry I did not read the article carefully enough. It's in there. [[User:Spike|Spike]] 19:16, 10 March 2009 (CDT)

114 / 72: If not 0, then unit is on fire, and will burn for this amount of turns.

== Floating Civilians ==

Civilians float 2 units off the ground, like Floaters and Cyberdisks. Soldiers don't. Should we consider this to be a bug? [[User:Spike|Spike]] 13:41, 20 August 2009 (EDT)

:Probably. I really doubt it's an intentional feature. --[[User:Zombie|Zombie]] 23:09, 20 August 2009 (EDT)

== Remembering morale vs health and pain killers ==

The game remembers whether a health loss has or has not been used to regain morale via pain killers. Presumably this is stored somewhere in UNITREF.DAT? [[User:Spike|Spike]] 10:30, 5 September 2009 (EDT)

== TFTD ==

It appears the name string starts at the same point in TFTD save points, which leads me to believe that the extra bytes are probably just appended at the end of the file, without much changing in the first 124 bytes per entry, anyone know what these extra 8 bytes might represent? - [[User:Hatfarm|Hatfarm]]

----

They are indeed appended. My battlescape editor deals with TFTD's UnitRef by just adjusting for the larger record size, and then ignoring the extra bytes completely - didn't need to do anything else to make it all match up. I've yet to actually look at some sample values in order to work out what they might be for.

Incidently, you can insert signatures into your postings using four tildes (<nowiki>~~~~</nowiki>). - [[User:Bomb Bloke|Bomb Bloke]] 21:48, 20 January 2010 (EST)

== TFTD's extra bytes ==

It appears that byte 126 is a bit flag array of some sort as I have mostly seen values of 1 and 0 for it, but others have appeared. I saved a single mission at several different times and each one had 0 or 1, but a terror mission save had some different values for this, Like 0x20 and 0x4F. I tried adjusting it and checking the saved game, but nothing seemed to change...

Byte 124 I've seen values of 0,4,6,7,0x0A and 0x0E. No idea what these mean, and changing them did not do anything for me.

They appear to only be for Soldiers as well, none of the aliens in any of my saved games have values for these.
[[User:Hatfarm|Hatfarm]] 15:16, 5 June 2010 (EDT)

----

124 may have something to do with the air-bubbles that trickle up from soldiers when they're underwater - an animation counter, similar to offset 8 of [[SMOKREF.DAT]], but with a higher range (0-15, probably). Granted, there's no real reason to keep track of bubbles when saving the game, but they have to be tracked somewhere at run-time, and this seems to be the logical place (the save files are just raw dumps of RAM anyway).

In theory, if you set this to the same value for all soldiers (say 5), on loading the game, they'd all have identical air bubbles over their heads. - [[User:Bomb Bloke|Bomb Bloke]] 22:26, 5 June 2010 (EDT)

----

You're right, I set them all to 5 and they were all in the same place bubble wise,. However, they don't all "rebubble" at the same time. Good call BB. [[User:Hatfarm|Hatfarm]] 02:16, 12 June 2010 (EDT)

----

I'd guess they "rebubble" randomly, though it may be a rather more elaborate setup - bubbles might appear more often for soldiers with lower stamina levels, maybe, to indicate they're out of breath.

Unfortunately, I can't think of anything else TFTD adds that would warrant using those extra bytes at the end of the file. - [[User:Bomb Bloke|Bomb Bloke]] 05:20, 12 June 2010 (EDT)

----

I'm guessing it's a 2 byte count at least, which would account for the 124 and 125 bytes. If I think of anything for the others, I'll let you know. [[User:Hatfarm|Hatfarm]] 01:07, 13 June 2010 (EDT)

Talk:UNITREF.DAT

2011-04-13T10:02:22Z

Kyrub: /* Offset 0x4A (74) */

Anyone who has it - can we get listings of values for various aliens on the Unitref page, for some of the variables found in both Unitref and the Geoscape [[Talk:Overviews_of_Aliens|Alien stats]]? E.g. energy recharge (Unitref[35]), energy loss [45]... like what Danial did for Height. Some of it might go to NKF's redesigned [[Soldier]] page. I am trying to flesh out the Geoscape data so I know what everything is there (and can then extend it across difficulty levels). It has unlabelled fields with values, some of which I know must be these values... but there's no list for me to compare against. Thanks if you can help! ---[[User:MikeTheRed|MikeTheRed]] 19:37, 25 Nov 2005 (PST)

P.S. We probably should clean up this Discussion some time. I will if I find the time to make sure everything has made its way to wherever it should go.

----

== Offsets 0x02 - 0x09 ==

It's obvious from unit drawing functions (reversed ones) it's a PCK and TAB spritepack reference address (DWORD).

_pck = (int)unitref_addr->pck_ref;
_tab = (int)unitref_addr->tab_ref;
...
if ( (_WORD)handob != 255 )
xc_BF_Draw_Battlescape_shaded_Sprite((char)v18, (int)vf_handob_pck, (int)vf_handob_tab, v21, v23, shade);
xc_BF_Draw_Battlescape_shaded_Sprite(sprite_num1, _pck, _tab, y0, x0, shade);
--[[User:Volutar|Volutar]] 09:43, 20 February 2011 (EST)

:So you're saying these values point to where the PCK/TAB files used by the unit in concern have been loaded into RAM, similar to how [[UNITPOS.DAT|UnitPos[4-7]]] points to where the UnitRef record is? -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 17:56, 20 February 2011 (EST)
::Exactly. They are simple 32bit pointers to RAM location where exact unit PCK/TAB loaded (I don't know how they worked for DOS version - I guess the same way). You could notice the lowest bytes (2th and 6th) are aligned to 4, as for all memory locations. --[[User:Volutar|Volutar]] 01:13, 21 February 2011 (EST)

::: Since the saves are interchangeable between the Dos and Window versions, and since the Dos version uses the Dos4gw engine to handle the exapanded memory, it could very well be a 32-bit pointer.

::: Still, memory pointers? That would mean these values are used at run-time only and these are just dumps of whatever it was at the time the save was made. Since whatever memory allocation function they used back then (I'm guessing malloc() ) would be storing the graphics at different offsets each time the tactical engine boots up, these would have to be replaced anyway. -[[User:NKF|NKF]] 02:00, 21 February 2011 (EST)

.text:004178EC
cur_unitref_addr = vf_unitref_dat;
i1 = 80;
do
{
if ( cur_unitref_addr->unitType != -1 )
{
unittype_offset = 8 * cur_unitref_addr->unitType;
pck_addr = *(a_allocated_pck_array_dword_4ADE40 + unittype_offset);
tab_addr = *(a_allocated_tab_array_dword_4ADE44 + unittype_offset);
cur_unitref_addr->pck_ref_off02 = pck_addr;
cur_unitref_addr->tab_ref_off06 = tab_addr;
}
cur_unitref_addr = (cur_unitref_addr + 124);
--i1;
}
while ( i1 );

:::: This called each time after setting up or loading UnitRef table. So according this code you can wipe these bytes without any effect, since these values overriden each time.--[[User:Volutar|Volutar]] 03:13, 21 February 2011 (EST)

:::::The save games contain a lot of stuff that's only relevant at runtime, on the basis that it was easier just to write (and then later read) these arrays straight to/from disk then it was to reformat them each time (sorta like how the entirety of MISDATA.DAT gets saved/loaded despite most of it being irrelevant most of the time). I'd been suspecting these to be pointers ever since Seb found the one in UnitPos, but I had no idea ''what'' they were pointing at, and I doubt I'd've ever worked it out. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 07:11, 21 February 2011 (EST)

== Offsets 0x30 & 0x34 ==

I've chopped out the majority of this page as it is no longer required. I'm keeping the heights chart in case it is required - I've also changed the "H-F" field to "H+F", as this actually makes sense.
[49] [51] "Tall" [48] | [49] [48]
Class Ht. Flt H+F Wide | Ht. Wide Area
--------- --- --- ---- ---- | --- ---- ----
Sectoid 16 0 16 2 | 16 2 32 Area=Ht.*Wide
Celatid 12 6 18 3 | 12 3 36
Hovertank* 12 6 18 4 | 12 4 48
Silacoid 10 0 10 5 | 10 5 50
Snakeman 18 0 18 3 | 18 3 54
Zombie 18 0 18 3 | 18 3 54
Cyberdisc 15 2 17 4 | 15 4 60
Ethereal 20 0 20 3 | 20 3 60 ''All Hover/Tanks in their
Chryssalid 21 0 21 3 | 21 3 63 ''class assumed to be same
Civilian 21 2 23 3 | 21 3 63 ''altho not tested yet
Floater 21 2 23 3 | 21 3 63
Muton 21 0 21 3 | 21 3 63
Tank* 16 0 16 4 | 16 4 64
Soldier 22 0 22 3 | 22 3 66
Reaper 23 0 23 4 | 23 4 92
Sectopod 23 0 23 4 | 23 4 92

Anyway, unitref[48] and unitref[52] remain somewhat of a mystery. Thus far we've assumed them to be the unit's width. Today I tried tinkering with [48] to see of this was correct. As I cranked it up, I found no change in my accuracy, or as to how the Sectoid target blocked line of fire to the tiles behind it.

When it reached the value of 37, however, the alien disappeared! I could not view it regardless of distance. In fact, I could even fire right through the tile it was standing on with no obstruction. The only sign that the alien was still there was the fact that my unit could not stand on the same square.

I lowered [48] a bit and tried viewing the alien from different distances, and found that it appeared in the same way as it usually would, regardless of the value used. It's simply the case that going to 37 or above makes the alien invisible.

I also tweaked [52] a bit, but found that it seemed to have no similar effects, if any at all.

Although I haven't tested this any further as yet, it might be possible to use this effect in reverse - Create an 'invisible' X-Com unit, and use it to observe how aliens act when they think we're not looking.

- [[User:Bomb Bloke|Bomb Bloke]] 00:44, 31 July 2006 (PDT)

----

I have a strong belief that offset 48 is nothing else but the loftemps.dat entry used for collision checking with bullets. A first check is done against the unit height (taking into account floating height, terrain height, kneeling). If the check is OK, the loftemps entry is then used as a final check (effectively treating the unit as a cylinder). I'll try to decypher the code further. If others want to have a look, the code is around here:
.text:004116AE 8B 15 5C 28 4A 00 mov edx, pUnitPos
...
[[User:Seb76|Seb76]] 13:24, 10 April 2008 (PDT)

----

I'm inclined to agree with you, though I'm not much good at reading through executable code. :( I hit on the same idea on my [[User_talk:Bomb_Bloke|talk page]]... I've got some notes in there about how I think the firing system works, if you could find code to back it up I'd be a happy boy.

It's something of a long winded work-in-progress ramble, and I'm sure some parts are confusing and/or dead wrong, but with any luck you can make some sort of sense of it. :) - [[User:Bomb Bloke|Bomb Bloke]] 18:34, 11 April 2008 (PDT)

----

[[Image:Loftemps.png|thumb|right]]I mentionned it earlier but got no real feedback so I'm adding a new section for it ;)
It looks like it is the loftemps entry used for collision detection with bullets. The main page says that setting it to 37 make the shots go right through the guys. If you have a look at the entry, you'll see why... The interesting thing is that the big units do not have special entries (unitref is common for all 4 parts so it would not have been possible to do otherwise) so a shot should be able to go through them (between the 4 parts). However, for the shot to be almost horizontal (or vertical) and traveling at the frontier between tiles (to go between the 4 "collision" circles), the shot should come from far far away so it is not likely to happened. Also depending on how the visibility check is performed, it may explain why alien suddenly disappeared when messing with the value (see discussion upper in this page). I suspect it is done using some kind of raytracing between the center of the 2 tiles (between the current unit and the target); so if the loftemps entry for the target has a "hole" in its center, it may become invisible. [[User:Seb76|Seb76]] 07:00, 1 June 2008 (PDT)

----

I just edited unitref 048 and 052 of all my soldiers to 0 and the aliens never tried to shoot at me. When I edited 048 to 0 for all the Sectoids on a mission, my soldiers couldn't see them anymore (only takes effect the following round if edited in unitef.dat, but surprisingly aliens remain visible to you during their movement phase). Since loftemps 0 is an empty cell, the results make perfect sense. A value of 76 (both 48&52) makes aliens disappear too. I'm not sure what the threshold is for disappearing, but a 3x3 block (loftemps 1) is still enough to be seen. --[[User:Zombie|Zombie]] 15:08, 17 August 2008 (PDT)

----

Am I understanding correctly... for purposes of shots hitting, we're all "barrels" with a specific diameter (i.e. [[LOFTEMPS.DAT]] 2-5), height ([49]), and distance (float) off the ground ([51])? Right or wrong, it sounds like this is finally pretty sown up, excellent work. We could update the page's entries. I wonder why they repeated this value twice (i.e. [48] and [52] always the same)... maybe they once considered the possibility of a unit whose diameter can change from turn to turn? If so, some other heretofore unfathomable UNITREF bit or byte may have been intended to dictate whether they're currently using the diameter at [48] or [52]. -[[User:MikeTheRed|MikeTheRed]] 17:06, 17 August 2008 (PDT)

----

While I've no problem believing [48] is a LOF template reference, I hadn't added it to the main page because I wanted to be sure as to it's relationship with [52].

See, at present, all we know about [52] is that it's the same as [48]. We haven't seen any effects from changing it.

What I ''suspect'' is that one offset might be used for shots traveling along an angle parallel to the target, and one offset might be used for shots traveling perpendicular. This would basically allow units to be effectively oval shaped (or it would, if [48] and [52] weren't the same for all units).

Just one of those things that I never got around to finishing the testing on. Would be dead easy to check, though.

There's still a little more to be researched before the entirety of the firing system is understood (see my talk page for a rambling explanation as to what IS known), but that's pretty much the basics of it.

- [[User:Bomb Bloke|Bomb Bloke]] 19:51, 17 August 2008 (PDT)

----

BB and others, see my edits for [48]. Does it make sense? In particular, I estimated pixel width from that little LOFTEMPS .png by magnifying it a ton. Any and all comments or edits welcomed. It's interesting that the silacoid has the highest width, but a low cross-section - did anyone see the Star Trek TOS show with the very short, wide silicon aliens? -[[User:MikeTheRed|MikeTheRed]] 22:53, 23 August 2008 (PDT)

----

Yes, you got the LOF widths correct. Though as you mentioned, they're only accurate assuming you're firing head on at your targets (as the templates aren't perfect circles, their width varies from other angles).

I threw in the kneeling soldier stats and made a note concerning large units.

- [[User:Bomb Bloke|Bomb Bloke]] 22:21, 24 August 2008 (PDT)

== Offset 0x3C ==

I have a gut feeling it is related to the panic/berserk status of the unit... Any volunteer for testing? [[User:Seb76|Seb76]] 10:36, 22 March 2008 (PDT)

----

Made a save where all soldiers had no morale. Ended turn, most of them panicked etc. Saved the game but that offset still came up as 0. Might only be flagged at runtime.

- [[User:Bomb Bloke|Bomb Bloke]] 18:01, 26 May 2008 (PDT)

----

I checked and indeed the game sets and clears it in the same turn so it is always 0 in a savegame and hence there is no 'black box' way of confirming it. I can provide disassembly screenshots if you want proofs however ;) [[User:Seb76|Seb76]] 05:45, 28 May 2008 (PDT)
:Actually after some thinking, it _might_ be possible... If you set the value to 3 for all entries, everyone may go berserk, with 2 they should run in fear and 1, they'll just crap their pants in place... [[User:Seb76|Seb76]] 07:09, 28 May 2008 (PDT)

----

I tried it, and indeed my units did exactly that (at the start of their next turn - not that of the aliens).

- [[User:Bomb Bloke|Bomb Bloke]] 21:08, 28 May 2008 (PDT)

== Offset 0x4A (74) ==
It seems to be some kind of AI mode, which has 4 phases - 0,1,2 and 3. Code at .text:004016C0 (CE version) shows its range. --[[User:Volutar|Volutar]] 02:00, 21 February 2011 (EST)

----

While taking a browse through the [http://www.strategycore.co.uk/files/index.php?dlid=776 pre-release game executable], I found these strings listed together in a clump:

*Patrol
*Sniper
*Combat
*Escape
*Guard
*GoUfo
*Finding Route
*Set Patrol Point
*Moving
*Firing
*Evaluating Mode
*Final Facing
*Attack Attempt
*Find Fire Point
*Select Target
*Find Cover
*Partial Cover

It struck me that the first few could relate to AI modes. Some aliens are known to choose a route node and stick with it (gaurding), and when unarmed, they'll usually run away (escaping); aliens will patrol when they don't know the location of X-COM units, though this seems to halt when turn 20 passes. Presumably these activities can be mapped to the four values. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:20, 6 February 2011 (EST)

That's a great find, BBloke. I never looked at the demo exe. While the debug fonction was deleted in the release, it permits to locate the basic AI fonctions in the code. So we have: AI_patrol_mode (0x4A = 0) at 0x0407D60, AI_Sniper_mode (0x4A = 1) at 0x04081A0, AI_combat_mode (0x4A = 2) at 0x0408430, AI_escape_mode (0x4A = 3) at 0x04067F0 and even the AI_evaluation_mode at 0x0408430, which fills offset 0x4A when it is equal to something else. Other functions can be found as well with the debug info. Fantastic. Now we could try to make AI take cover from time to time, instead of making a making a stupidly exposed target.

== Offset 0x6F ==
This offset seems to be corresponding for runtime "Attacking" state, not final /0 for unit name. When 1 units drawn with weapon helded in fire position, when 0 - ordinary.--[[User:Volutar|Volutar]] 17:15, 26 February 2011 (EST)
:Well spotted. :) -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 00:43, 27 February 2011 (EST)

== Offset 0x70 (112) ==
It seems to be used in realtime only as "already acted" flag for civilian and alien units...--[[User:Volutar|Volutar]] 09:19, 27 March 2011 (EDT)

== Offset 0x71 ==
Hmm, the code checks this offset before applying stun damage... It looks more like an 'immune to stun damage' flag then. Strange... [[User:Seb76|Seb76]] 13:48, 7 April 2008 (PDT)

----

By memory, the only things that use this are X-Com HWPs (which shouldn't have stun applied). It does toggle inventory access as described though it wouldn't surprise me if it also toggled stun damage.

- [[User:Bomb Bloke|Bomb Bloke]] 05:46, 8 April 2008 (PDT)

:OK, I located the check and it is exactly what happens. BTW, if you want to try something, try to patch this with nops (0x90):
.text:00412A20 A8 40 test al, 40h
.text:00412A22 0F 85 00 02 00 00 jnz exit ; default
:It should enable inventory screen for memory controlled units (could not test since I have no save files with psy units...) [[User:Seb76|Seb76]] 11:37, 8 April 2008 (PDT)

:: So, to be clear, is this the location of the inventory screen check for mind controlled alien units? And here you are disabling the check by overwriting it with NOPS? Is there a nearby section of code that does the same check for tanks? I would like to be able to override this tank inventory check in order to play with [[User:Spike#Tank mods|Tank mods]]. It looks like NOPing the check logic is the right way to do it, since if instead I toggled the 0x71 flag for the tanks, they would than also become vulnerable to Stun? Though I also I think read somewhere that if you get to the inventory screen of a tank, the game crashes. It doesn't crash if you get to the inventory screen of an Alien large unit via the Alien Inventory or Alien Pets hacks (not sure which) in your UFOExtender. I was able to arm Reapers with dual Heavy Plasma or dual Blaster Launchers. (Unpleasant. They have 0% FA so they have to run up to you and spray with the Heavy Plasma. Not a problem with the Blaster Launcher.) [[User:Spike|Spike]] 13:59, 20 August 2009 (EDT)

== Offset 0x77 ==
This isn't field at all. It just ain't even initialized anywhere, so it's obviously a garbage field. I haven't found even one place where it be used...--[[User:Volutar|Volutar]] 06:52, 27 March 2011 (EDT)

== Offset 0xB ==
The value is used together as an offset to [[MCD|MCDData]] offset 39 (describing TUs required to cross a tile walking/flying/sliding) so it most likely represent the way the unit moves. Still needs testing. [[User:Seb76|Seb76]] 13:27, 23 May 2008 (PDT)

----

I took a look at it for Snakemen and Silacoids, it's still 0 (same as it is for everything else).

But that doesn't mean it remains at 0 when the game's running. Do you mean to say that the value here + 39 = the offset in the MCD array that says how many TUs were required to move past any given obstacles in the current map location?

(That is, you'd expect to see a 2 there for sliding units?)

- [[User:Bomb Bloke|Bomb Bloke]] 05:14, 25 May 2008 (PDT)

----

Yep, exactly like that. Also it checks if the value is 0xff and prevent movement in that case. I'll try a live check with a debugger when I encounter snakemen. Maybe it's a part of code that was implemented but not put into usage. [[User:Seb76|Seb76]] 05:20, 25 May 2008 (PDT)
:Did the check and the value is indeed zero even for snakemen... BTW, is the movement type really working? I mean has anybody ever checked that e.g. snakemen really use different TU amount for tiles where TU usage is not the same between crawling and walking? [[User:Seb76|Seb76]] 06:43, 25 May 2008 (PDT)

----

Truth be told I don't remember reading of anyone doing the tests, so I had a go myself.

I tried first with the Avenger ramp, stuck it up in the air and had soldiers walk/fly onto it. Made no effect to their TU usage.

Next I rigged a Snakeman mission in the arctic, stuck one of them in the middle of a pond. It wouldn't move on it's own, and I couldn't move it under mind control.

So then I set 0xB to 2 just for that unit, and hey presto! Suddenly it was able to move freely, either under my control or otherwise. That's certainly the movement type flag... It's just not set in practise.

Still, now I'm wondering if 2 really was for sliders... It doesn't make sense that "fliers" (which I guess was supposed to include the likes of CyberDiscs, which "hover" even when on the ground) wouldn't be able to cross water, yet Snakemen could. Perhaps it should be the other way around?

- [[User:Bomb Bloke|Bomb Bloke]] 19:22, 25 May 2008 (PDT)

----

Note that there are some tiles that have 0 MP cost for sliders. - [[User:Zaimoni|Zaimoni]] 22:28, 25 May 2008 (CDT)

: Yeah, I guess that puts the clincher on it. Only fliers would really be totally unhindered by ground rubble. I've tweaked the MCD details page accordingly. - [[User:Bomb Bloke|Bomb Bloke]] 05:25, 26 May 2008 (PDT)

----

Hehe, I knew it couldn't be anything else but movement type. Yet another entry for known bugs ;) I'll check if it's possible to reenable the feature. It'll depends if it's a bug or if it was voluntarily removed I guess... [[User:Seb76|Seb76]] 04:37, 26 May 2008 (PDT)
: Did a quick check and can confirm what is said in [[GEOSCAPE.EXE#Alien_Stats|Alien Stats]] page. Offset 0xB is filled with the 3rd "unknown" value of alien stats. It is set to 0 for all entries. Could not find any other place where it could possibly be set to another value. [[User:Seb76|Seb76]] 05:17, 26 May 2008 (PDT)

----

So it's just a matter of tweaking that for all relevant units, then. However, I reckon it was left unused intentionally - I doubt the map files really contain enough variety to make it worth including.

- [[User:Bomb Bloke|Bomb Bloke]] 05:25, 26 May 2008 (PDT)

----

Since TFTD was done later with the same engine, perhaps it makes use of this? However, given that a different team made it ([http://www.lasersquadnemesis.com/AboutUs.htm Terror from the Deep was developed by Microprose using code licensed by Mythos]), developers may not have known the feature was available... [[User:Seb76|Seb76]] 07:25, 28 May 2008 (PDT)

----

I took a quick check, and sure enough found a Hallucinoid (the big flying squid thing) set to 2.

- [[User:Bomb Bloke|Bomb Bloke]] 21:31, 28 May 2008 (PDT)

== Offset 0x47 ==

The only use I could find is that of updating [[SOURCEMP.DAT|mobile light sources]] (or something like that) when the unit dies/is rendered unconscious. Could not find anything else about this flag. [[User:Seb76|Seb76]] 05:24, 29 May 2008 (PDT)

:Good work there. As a general statement, can I say - I've been waiting for somebody to disassemble XCOM :) -[[User:MikeTheRed|MikeTheRed]] 21:18, 30 May 2008 (PDT)

I sat down to do some tests with this, but didn't bother too read to closely... I was selecting/moving units around when I probably shoulda been shooting at them.

Oh well. For the record:

Moving a unit causes a light check to be done on all your units. You may not see this light if one of your units is standing in a fog-of-war covered zone (say you just mind controlled an alien and haven't selected it yet).

Selecting a unit does a fog-of-war check concerning what it can see, but does not do a light check.

Whatever this offset is has no effect on the light produced by your units, or the aliens units. Your active guys ALWAYS fully illuminate their tile (even if this is 0) and the aliens provide no illumination at all. Will have to do some tests concerning what happens when you shoot them, but it seems odd: If a unit is dead I'd expect a full light check to be done, since the unit isn't "active" it won't produce light, so I don't see how this offset is helpful there... You can't just remove the light values for this one unit because you might interfere with other nearby light sources, so you really have to calculate them all from scratch.

But likewise it seems [[MCD|MCD[58/3A]]] is similar; a street lamp is set to 1, a normal lamp to 10, but they both provide maximum illumination.

Perhaps the programmers changed their mind about the lighting system at some point? Dunno.

- [[User:Bomb Bloke|Bomb Bloke]] 07:03, 20 June 2008 (PDT)

:Some of your note reminds me of what I wrote at [[Night_Missions#Personal_lighting]] ... does that help any? (probably not) -[[User:MikeTheRed|MikeTheRed]] 16:01, 20 June 2008 (PDT)

== On Fire Flag or Timer ? ==

Do we have any idea where a flag is set to show the unit is on fire? This is persistent between saved games so it must be stored in a file somewhere. Possibly UNITPOS.DAT? It could be a flag, but more likely is either a countdown timer for turns remaining on fire, (values 1-5?), or a "what turn do I stop being on fire" timer value (like a grenade timer).

I have uploaded a saved game file with a burning Aquatoid if anyone wants to take a look. I just don't have the right diff tools. Maybe with the Hex Workshop template... [[User:Spike|Spike]] 19:05, 10 March 2009 (CDT)

:Offset 114 in Unitref holds that data. --[[User:Zombie|Zombie]] 19:15, 10 March 2009 (CDT)

:: Sorry I did not read the article carefully enough. It's in there. [[User:Spike|Spike]] 19:16, 10 March 2009 (CDT)

114 / 72: If not 0, then unit is on fire, and will burn for this amount of turns.

== Floating Civilians ==

Civilians float 2 units off the ground, like Floaters and Cyberdisks. Soldiers don't. Should we consider this to be a bug? [[User:Spike|Spike]] 13:41, 20 August 2009 (EDT)

:Probably. I really doubt it's an intentional feature. --[[User:Zombie|Zombie]] 23:09, 20 August 2009 (EDT)

== Remembering morale vs health and pain killers ==

The game remembers whether a health loss has or has not been used to regain morale via pain killers. Presumably this is stored somewhere in UNITREF.DAT? [[User:Spike|Spike]] 10:30, 5 September 2009 (EDT)

== TFTD ==

It appears the name string starts at the same point in TFTD save points, which leads me to believe that the extra bytes are probably just appended at the end of the file, without much changing in the first 124 bytes per entry, anyone know what these extra 8 bytes might represent? - [[User:Hatfarm|Hatfarm]]

----

They are indeed appended. My battlescape editor deals with TFTD's UnitRef by just adjusting for the larger record size, and then ignoring the extra bytes completely - didn't need to do anything else to make it all match up. I've yet to actually look at some sample values in order to work out what they might be for.

Incidently, you can insert signatures into your postings using four tildes (<nowiki>~~~~</nowiki>). - [[User:Bomb Bloke|Bomb Bloke]] 21:48, 20 January 2010 (EST)

== TFTD's extra bytes ==

It appears that byte 126 is a bit flag array of some sort as I have mostly seen values of 1 and 0 for it, but others have appeared. I saved a single mission at several different times and each one had 0 or 1, but a terror mission save had some different values for this, Like 0x20 and 0x4F. I tried adjusting it and checking the saved game, but nothing seemed to change...

Byte 124 I've seen values of 0,4,6,7,0x0A and 0x0E. No idea what these mean, and changing them did not do anything for me.

They appear to only be for Soldiers as well, none of the aliens in any of my saved games have values for these.
[[User:Hatfarm|Hatfarm]] 15:16, 5 June 2010 (EDT)

----

124 may have something to do with the air-bubbles that trickle up from soldiers when they're underwater - an animation counter, similar to offset 8 of [[SMOKREF.DAT]], but with a higher range (0-15, probably). Granted, there's no real reason to keep track of bubbles when saving the game, but they have to be tracked somewhere at run-time, and this seems to be the logical place (the save files are just raw dumps of RAM anyway).

In theory, if you set this to the same value for all soldiers (say 5), on loading the game, they'd all have identical air bubbles over their heads. - [[User:Bomb Bloke|Bomb Bloke]] 22:26, 5 June 2010 (EDT)

----

You're right, I set them all to 5 and they were all in the same place bubble wise,. However, they don't all "rebubble" at the same time. Good call BB. [[User:Hatfarm|Hatfarm]] 02:16, 12 June 2010 (EDT)

----

I'd guess they "rebubble" randomly, though it may be a rather more elaborate setup - bubbles might appear more often for soldiers with lower stamina levels, maybe, to indicate they're out of breath.

Unfortunately, I can't think of anything else TFTD adds that would warrant using those extra bytes at the end of the file. - [[User:Bomb Bloke|Bomb Bloke]] 05:20, 12 June 2010 (EDT)

----

I'm guessing it's a 2 byte count at least, which would account for the 124 and 125 bytes. If I think of anything for the others, I'll let you know. [[User:Hatfarm|Hatfarm]] 01:07, 13 June 2010 (EDT)

Wish List (EU)

2009-04-06T19:55:30Z

Kyrub: /* Geoscape and Strategic */

X-Com is a great game and as evidence just look to the fact this wiki exists even though the game pre-dates the internet. In all it's greatness X-Com has some elements and behaviors players wish they could change. This is a repository of those desires. Some day a fan mod may make your wish come true...

= I Wish... =
State what you want AND what X-com does normally. Sign your name if you think "Oh man! That would be great!"

== Geoscape and Strategic ==

=== Smarter Aircraft Movement Around Globe ===
I wish all craft understood the shortest distance between two points on a globe is a curved path towards the poles. Normally a craft goes in the opposite direction than it should (towards the equator). Pain in the ass when the base in the UK sends a craft to Siberia.
--[[User:Brunpal|Brunpal]]

===Score for retaliation Battleships===

When a Battleship on retaliation attacks your base and is shot down, you get no score for it. This is completely illogical and it discourages any use of base defences. You should get normal 700 (or even 1400) points for it.
--[[User:Kyrub|Kyrub]] 14:05, 30 August 2008 (PDT)

: I'm not sure about this. Yes it's illogical, but it could also be a licence to get a huge score if you have a strong enough base. [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: The impenetrable base setup would turn into a cheat. As the aliens will keep hammering the base with a battleship until one breaks through, you'll have a steady supply of points without having to really do anything. Some balancing, such as paying to rearm your defence modules, ought to be thrown in to balance things out. -[[User:NKF|NKF]] 23:13, 13 September 2008 (PDT)
:::A better fix would be to remove the retaliation flag when a battleship is destroyed. If someone can post a savegame with a never-ending flow of base attacks, I may have a look at the fix. [[User:Seb76|Seb76]] 01:05, 15 September 2008 (PDT)

===Enforced Variant Games===

Various people like to play various variant games, such as No Alien Technology, or No Detection, or No Lethal Weapons - see for example Scott Jones' notes to XComUtil. It would be nice to have options on the game executable to enforce these scenarios. Self restraint is hard! [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

Some of these variant scenarios have been implemented by [[User:Seb76#Mods|Seb76]].

===Recruit Certain Alien Types===

Consider that not all aliens are loyal to their master (most TFTD alien has a device lodged to its brain), it would be interesting (or at least cool) if we could recuit such aliens to the XCOM cause. Maybe we can remove the controling devices from captive aliens after research on that species. Or convince the head of the Snakemen that it would be far more benefit to his race to help us instead of the Ethereals [[User:L-Zwei|L-Zwei]] 23:25, 12 September 2008 (PDT).

Only certain alien types should be recruitable. Ones that should NOT be include Mutons (as they are directly controlled by Ethereals), Chrysallids (unbalancing), etc. It would be nice to be able to reverse-engineer Cyberdiscs or Sectopods, or make it that a Cyberdisc must be researched to build hovertanks/etc.
[[User:MagicJuggler|MagicJuggler]] 13:32, 18 September 2008 (PDT)

=== Smart Interception ===

Aircraft intercepting a UFO just head straight toward the UFOs current position at all times. Unless the UFO is already on a head-on course, this results in the interceptor travelling through a closing parabolic spiral path, and often missing the UFO and ending up in a tail-chase, and then just falling further behind unless the UFO stops or reverses course. This is pretty basic stuff, fighter pilots have known how to do this better for nearly a hundred years. It is particularly important if the aircraft you are trying to intercept is moving faster than you (eg if you are flying an Interceptor).

What is needed is to plot the UFO's current course and speed (which X-Com has from radar data), and plot an intercept course. The maths for this is pretty easy (the intersection of 2 vectors) and can be implemented in a few lines of code, if we can find out where the current interception algorithm is, and patch it.

Actually the radar bearing shown on screen is only accurate to within 45 degrees. I presume that X-Com does actually know the UFO's bearing, since it can clearly track the UFO's movements. Finding where that variable is located might be different.

While we're at it, it would be nice if the UFO detection information displayed the actual bearing in degrees, rather than just the compass direction (North East, South, etc).

Even if the improved intercept algorithm only used a bearing accurate to within 45 degrees, that would still be better for remote UFOs. You might need to switch to "head straight for it" once you get to very close range. [[User:Spike|Spike]]

=== Game option: sell only researched items ===

The fact that you may sell the alien items for the best price once you get them, without any research, is illogical. Such staff would never get on the market, being top secret and potentially dangerous to the humanity.

Selling without proper research does not help the replay value of the game either: once you know the "right path" to get the best items, you simply sell anything else immediately and ignore the unnecessary research. Too easy.

Therefore I wish for this game option: unknown items are sold for 0 (including the alien corpses), the known ones for their full price. This makes the sustainable economics much harder to develop and it gives sense to the "useless" research. Last but not least, it adds a lot of depth to the gameplay: will you choose research of a new weapon you need on the field, or of a mind probe that will earn you millions in sales? --[[User:Kyrub|Kyrub]] 15:55, 6 April 2009 (EDT)

== Battlescape and Tactical ==

===Equipment Management===

All wishes are currently implemented!

===Fog of War Improvements===

I'm sure most of these would be an absolute PAIN to implement, but I figured I'd toss the ideas out here.

====Prior Recon of Battlefield====
One thing that has always irked me is X-COM has no terrain knowledge when it lands, despite having probably circled the place two or three times before landing and thus they should know at least some of the area. This would be nice, but isn't too important. Probably would be a pain to implement so X-COM would have all knowledge of external features but no knowledge of building interiors, anyways. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

:Yes at the very least, when you splash the UFO, it could tell you (via some miracle technology such as "satellite reconnaisance") what the terrain type is of the landing zone area. Then you could adjust equipment accordingly. And adjust your uniform camouflage (if using one of the uniform mods). [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: Geoscape: center on the site, then maximum zoom. Aside from having to disambiguate forest from jungle, this works fine for knowing the exact terrain you're getting into. -- [[User:Zaimoni|Zaimoni]] 10:17, 4 Sept 2008 (CDT)

:::This is already present in the game. To center the Geoscape on a specific location, right-click on the target spot. To do maximum zoom in, right click on the Zoom-In button(and the same works for Zoom-Out). Also, Jungle and Forest use the same display algorithm, but are easy to differentiate; Forest occurs NORTH of the equator, and Jungle occurs SOUTH. [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:23, 4 September 2008 (PDT)

:Returning to AQ's original suggestion, it wouldn't be too hard would it for the dropship to "radar map" the target, and then have the basic map show up on your scanner on Turn 1? [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

====Dynamic Fog====

The Fog of War in X-COM is clumsily implemented, compared to modern expectations. Everything starts out black, but after exploring, is shown...and it's kept in the same showing, regardless of whether you actually have LoS to that area anymore. It would be nice if when you no longer had Line of Sight to a particular map area, it would be cloaked in a way so that you knew the terrain, but not the units there. Since I've sometimes spent over half an hour trying to hunt down that last alien hiding in area I'd already explored. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

====Deactivate Object Radar====

Currently, in X-COM, any objects dropped in a given square show on your Battlescape, regardless of whether you have Line of Sight to the square or not. In regards to dropped weapons/grenades/equipment/dead soldiers/dead aliens, this doesn't make a large difference. But in the case of STUNNED aliens, a quick scan across the Battlescape can tell you whether the alien you stunned 10 turns ago is still down, or stood back up(the stunned alien object will disappear from the stack). Of course, since aliens which have revived from stun are almost always disarmed(and the ones that aren't probably should've been killed instead), the usefulness of this 'exploit' is reduced mainly to finding out that the last alien you're looking for is just wandering aimlessly and unarmed. Perhaps leave stacks showing the same until you regain LoS to that area? [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

===Restore Game from Battlescape===

It would be nice to be able to reload a saved game directly from the Battlescape "?" screen, rather than having to go through the process of Abandoning to the Geoscape. Would you need to check it was a Battlescape save and not a Geoscape save? Maybe, maybe not. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Warm Grenades===

Currently when you set the timer on a grenade (or HE pack), the timer runs down every turn regardless of whether the grenade is worn, held, or dropped. Then, when the timer runs out, it explodes unless it is held or worn. There is no real grenade or explosive that works this way. Once the timer (fuse) starts running, they explode regardless. However for most hand grenades, the timer (fuse) doesn't start until after you throw/drop the grenade. It would be nice to have both of these real world behaviours, and lose the game's default behaviour. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

: Technically the way the game implements grenades, they don't have a timer. At least, not as such. When you set a grenade, the game just assigns it a turn to blow up on. Once the turn has passed, the game checks to see that it's on the ground and blows it up if it is, otherwise it doesn't. I believe Seb76 has already addressed this in his patches where there's an option to make grenade blow up regardless whether they are in inventory or otherwise the moment the timer is set. X-Com Apocalypse does a good job of this. The moment the grenade is so much as moved after the timer is set, it counts down. - [[User:NKF|NKF]] 23:01, 13 September 2008 (PDT)

:: To simulate an actual timer, you would need to do something like: Every turn that a primed grenade is being held by a unit during the "explode" check, increment by +1 the turn when that grenade is going to explode. [[User:Spike|Spike]] 19:10, 14 September 2008 (PDT)
:::I think I would change quantity2 ([[OBPOS.DAT]]) to a countdown instead of a turn, and use quantity3 as a flag indicating if the count has started. This flag is set any time a turn ends and the grenade has no owner. Taking it back in your hand once the timer has started won't help and the thing must be thrown... quantity2 is decreased if quantity3 is set, and the grenade blows up as usual. [[User:Seb76|Seb76]] 01:35, 15 September 2008 (PDT)

: That would be great. It would be exactly consistent with a 'spoon' type hand grenade. The timer only starts when you release the grenade, but after that it explodes at a definite time regardless of whether you pick it up or not. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

===Stun Grenades===

I want flashbangs.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)
:Instead of stunning, I'd see more effect if it would remove some TUs to units having line of sight (to be fare it should affect xcom units too). It would help against reaction fire (which is the point of flashbangs). Given that grenades detonate at the end turns, it would require a good coordination to have the grenade detonate exactly at the end of the alien turn, and just before your attack. Being able to open doors à la xcom2 would also help to throw flashbangs just before a craft assault... [[User:Seb76|Seb76]] 22:03, 12 September 2008 (PDT)
::That would be good. Hard to program, potentially extremely unbalancing, but good. I considered a "debuff" kind of ability (as you suggest) for flashbangs, vs the more obvious substitution of [[stun]] for [[Explosions|HE]] damage. In the end, I picked "I want flashbangs."--[[User:Brunpal|Brunpal]] 03:32, 13 September 2008 (PDT)
: Maybe flashbangs dont' work on Aliens - otherwise, XCom would use them, right? :) But seriously, I too would like flashbangs, and stun grenades / concussion grenades. Both of these would make the game easier, though. With flashbangs, you might have to compensate by just giving the aliens more TUs. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)
::More options for the player is going to make it easier for any kind of game. Particularly of games like XCOM where the computer can't take advantage of the changes. However I don't believe a weak stun grenade (like 44 stun damage, comparable to AC-HE) would change the game much because the 80 item limit remains.--[[User:Brunpal|Brunpal]] 22:21, 13 September 2008 (PDT)

===Night Vision===

I '''don't''' want to add night vision equipment to the game. I assume that either (1) all XCom units already have night vision gear as standard, but it's not as good as alien night vision, and the visibility that XCom units have at night is based on their standard-issue night vision gear, or (2) night vision gear does not work on Aliens. Either they do not appear on night vision, or maybe worse - maybe the aliens can manipulate night vision equipment, causing worse than normal vision, or hallucinations, and even tricking XCom units into firing on each other. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)

===Throwing over stuff===
'''(Moved to Talk, as this is not a bug and so does not need fixing.)'''

===Assault Time Limit===

One of the cool things about UFO Defence is there are no time limits on the scenarios. This is great as it allows for a totally different kind of tactics and much more flexibility.
It's more of a "thinking man's game" as a result. But... arguably this is not very realistic for UFO Assault missions. If the Aliens are getting creamed, they should try to make a getaway if they can (just like XCom would). A simple way to implement this would be a hard time limit (say 20 turns?) on a UFO Assault. Another way would be to base it on Alien Morale. At a certain Morale level the aliens decide to dust off. Give the player say 3 turns warning while they rev up the engines. Then if there is still a Navigator or Engineer in the Control Room alive, the ship takes off. Any XCom troops still aboard are MIA.

You might run into problems if the UFO took off but then landed again or was shot down, generating another ground mission with potentially '''more''' Aliens than were still alive at the end of the Assault. (Still, maybe they hatch some more clones if they get time to....) [[User:Spike|Spike]] 09:51, 4 September 2008 (PDT)

: It strikes me as justified they don't do that. Troops loose in the vessel could be seriously bad. It would be nice if they dusted off on the condition that their morale was low enough or 3 X-com soldiers had the door in their sights without aliens alive outside in the latter case and no X-com soldiers on board in either case. also, if the UFO has a hole in either the command or engine room, it would have to set down before leaving the atmosphere. [[User:(name here)|(name here)]]

===Alien AI===

====Attempts to rearm====
Aliens cannot pick up items, but I wish they would. If an alien has no useful weapons in inventory they should either head for cover or head for a plasma weapon. Panicked aliens drop their weapons but never seem to pick them up when they managed to pull themselves together. It would be nice if they tried to arm themselves again. --[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)

:Even if it's too hard to make aliens head towards weapons (is it safe?, could it be used to trap them, not to mention the complexities of route finding) - it would still be good if an unarmed alien checked for usable weapons in every square it moved through, and at least picked up one loaded weapon or grenade per turn. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

==== End Psi Bullying and Psi Baiting ====
When the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?

: Not a bad idea to randomise this a bit, because while initially this tactic helps the aliens, it becomes so predictable that it can be used against them by deploying unarmed "Psi Bait" soldiers to draw off all the attacks. (Or make aliens avoid controlling/panicking soldiers who have no loaded weapons. But then folks would just give them pea shooters and wear armour.) [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

=== Mind Controlled then Hostile ===
If you mind control a human (civilians) in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control.

=== Mind Controlled then MIA ===
Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
: I believe XComUtil fixes this MIA issue. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

=== 80 Item Limit on Base Defense Mission ===
: Well you get the 80 item limit on every mission, but it hurts more on a Base Defence as you have more limited ability, or sometimes no ability, to manage what goes into those 80 items. I was thinking about a couple of (theoretical) ways to fix this and I hit on a new one (new for me anyway): Why not take the 80 items from the Transport(s), first Transport then second Transport until you run out of items or hit 80. This has a few benefits:
:* Ready made interface to manage the 80-item limit, the Stores <> Craft (Equip Craft) Screen.
:* If you have no warning at all, the 80 items will probably make good tactical sense in general terms, even if they are are not totally optimised for Base Defence (no proximity mines, etc).
: I think that copying the Transport inventory into the Battlescape inventory would be relatively to implement (though what do I know?). As a simplification, you could move only the inventory in the ''first available'' Transport that is present in the Base, into the Battlescape, and not bother looking in more than one place (other Transports, Base Stores) to get up to 80. It would then be a bit of a drag if your Transports are all out on a mission when your Base gets attacked though. Or perhaps inspect the inventory of Transport 1 (wherever it is in the world), and then attempt to copy its inventory, using equipment present in the Base?
: Another way of doing it which has been mentioned elsewhere is to try to reverse the order of the items in the Stores list. This has the effect of putting the more advanced weapons first, rather than the more basic weapons. There could be all kinds of unwanted side effects of this, depending on various programming issues.
: Actually there is already a fix for the 80-item limit in XComUtil. XComUtil records a standard assign weapon set for each of your troops, and then teleports those weapons to the Battlescape from your Base Stores, regardless of the 80-item limit (but still subject to the Battlescape's 170-item limit). Not 100% sure if this works for Base Defence missions though.
:[[User:Spike|Spike]] 13:22, 24 November 2008 (CST)

=== Collision Detection Bugs ===
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!

=== Base Defence Systems Cause Alien Casualties ===

I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).

: The general view is probably that Base Defence missions are a boon to XCOM already, so why make them any easier. At very least there would need to be more damage to the loot than there was to the Alien's combat effectiveness, otherwise this unbalances the game in favour of XCOM. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

=== Alien vs Alien ===
This one is way out there. Alien v Alien battles out with main game, just random battlescape maps. Sectoid and their terrorists against Floaters and theirs etc. One side human controlled the other computer. Choice of ships involved etc.

:I actually love this idea. It might just about be possible using XComUtil, if someone is a total XComUtil guru.

=== Open Doors But Don't Enter/Exit ===

Open doors like they do in TFTD (I know this is mentioned above with the good stun grenades idea).

=== Aircraft in Base Defence Battlescape ===

New graphics for the Interceptor and Firestorm on the battlescape. All your ships could remain in their hangers when the aliens attack your base. Don’t understand why Mythos did not do this originally.
: Simply for one reason: the limit on the size of the battlescape. UFO maps are usually limited to 10000 tiles (50x50x4), on Bases you have 9600 (60x60x3), the last level one being dirt. You need 3 levels to display X-COM craft. [[User:Hobbes|Hobbes]] 14:28, 23 September 2008 (PDT)
:: Could you not do it but clip off the top level of the craft - leaving the ground level and 'deck' level? It would be a cool terrain area to fight in. I like the fact that in TFTD you can still see your subs during a base defence. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

=== Fixed firing TUs ===

Something that always bugged me was how the weapons used percentages for firing TUs. It doesn't make sense that the faster a soldier got, the longer it would take to fire a weapon.

== Miscellaneous ==

===Fix All Bugs===

Oh no [[User:Seb76#Bug Fixes|Seb76]] already did this! :) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

= I Wished (And My Wish Came True)... =

== Geoscape and Strategic ==

=== Fuel Ready always ===
[[User:Seb76#Mods|Implemented - here]]

I wish that I could send out craft at any fuel or ammo level. Normally craft can only leave a base if fully "ready". Craft is only "ready" at 100% fuel (or 0% fuel using an exploit) but there's no logical reason why a full tank and full ammo is required. Fully repaired... that's fine. I can live with pilots refusing to fly a plane missing a wing even if it means England is lost to aliens. 15 hours to fill a tank? Retarded but I can live with that too if I can send out a craft at 20% fuel.
--[[User:Brunpal|Brunpal]]

:Actually, many modern aircraft '''do''' require the fuel tanks to be full on takeoff, and fairly empty on landing. The weight of the fuel is figured into the takeoff aerodynamics, and the tank being full prevents fuel 'sloshing' in the tanks and not actually making it to the engine. (Conversely, many aircraft need to have dispensed of much of that fuel weight before landing.) This holds for most runway-takeoff craft, but may not apply to anything with VTOL capacity; I'm unsure there.

:I do agree that non-full weapons aren't as critical, though. But from a logical standpoint, most modern aircraft should not be launched on an empty fuel tank. I also should noted that an Elerium-fueled craft with [[Known_Bugs#Elerium-fueled_Craft_Bug|50% fuel or less remaining]] will automatically return to base, regardless of distance from base. Of course, given that such craft fuel up quickly, its less of an issue there. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:05, 7 August 2008 (PDT)

:Hum, maybe you can try [[User:Seb76#Mods|this]]? [[User:Seb76|Seb76]] 13:01, 8 August 2008 (PDT)
::Thanks! But I can't try it. I've not been able to get my copy of Xcom to run properly except on a Win98 install. VC2008 requires a more modern OS. I'm sure I could ''eventually'' figure out a way to get it running, but I tried once and wasted too much time before giving up.--[[User:Brunpal|Brunpal]] 14:45, 8 August 2008 (PDT)
:AFAIK VC2008 binaries should run OK on Win98 as long as the runtime is deployed. Anyway, the loader uses CreateRemoteThread API which is not available in Win98 so don't even bother. '''However''', you can manually patch the binary if you want ;-) Data to patch (all in hexadecimal):
offset 0x41752: 2A0075 -> 18207C
:HTH. [[User:Seb76|Seb76]] 14:56, 8 August 2008 (PDT)

===Base Build Stacking===
[[User:Seb76#Base Building Stacking|Implemented - here]]

At the moment you are only allowed to build next to a finished module, and you aren't allowed to plan ahead in your base construction. It would be nice to at least be able to plan more than one phase of construction in advance. This would be pretty easy to implement. There is no need to code any new "queuing system". Just place the new module next to an existing under-construction module, but increment the build time to the normal build time + the time remaining on the under-construction module (the lowest time remaining that would make the square you are building in, a legal square to build in). As a premium for build stacking, you have to pay the costs up-front. As with normal construction, all costs are non-refundable if you change your mind. (There would probably need to be some on-screen feedback for how long the module would take to build, before you were committed to building it.) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

See also: Discussion on [[Talk:Wish List|Talk page]].

== Battlescape and Tactical ==

=== Equipment Management ===

==== Soldiers remembers THEIR equipment ====
[[XcomUtil|Implemented - here]]

I wish soldiers remembered what equipment they LAST used and start with that gear when they land. Normally soldiers grab various gear and put lots of crap on their belt. I put most things on the shoulder slots, and keep many things spare things on the ship just in case I need them. (I only want IN rounds if it's night. Stop picking them up before I shoot you in the back!) Takes forever to sort out the gear so the weakling isn't carrying all the rockets etc.
--[[User:Brunpal|Brunpal]]

:This is already available in [[XcomUtil]]. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:07, 7 August 2008 (PDT)

====Access to Stats screens during equipment allocation====
[[User:Seb76#Equipment Screen|Mostly implemented - here]]

In Battlescape you can get to Stats screens by right clicking on one of the unit's status bars. However you can't do this in the Equipment screen. Things like Statstrings and (even more so) [[User:Seb76|Seb76]]'s modified Equipment screen with actual/max weight help. But it would be nice to be able to see exact stats. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Decrease Accuracy for targets out of sight===
[[User:Seb76#Range_Based_Accuracy|Brilliantly implemented - here]]

How come you can easily shoot on something you do not see?
I find the over-used scout-sniper tactic is a cheap exploit of the X-COM. The tactical game should describe a combat, not a cowardly shooting practice. It would turn into a nice feature, if there would be a penalty of (let us say) -20% to the accuracy of anybody who is firing on a target out of his current sight. This can greatly enhance the tactical depth of the game. (Seb around? ;-) --[[User:Kyrub|Kyrub]] 14:20, 30 August 2008 (PDT)

...discussed [http://www.ufopaedia.org/index.php?title=Talk:Wish_list here]

===Enough Smoke===
[[User:Seb76#Mods|Implemented - here]]

It would be nice to increase the current limit on smoke/fire hexes. This is due to their locations being stored in a small, fixed length array. In effect you can only get about 3-4 smoke grenades worth of smoke or fire on the map at the same time. Being able to use smoke liberally would really open up new tactics. At the moment all you can really do is cover the LZ in smoke when you exit the transport, and maybe cover one advance over open ground. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)
:I did something for that on my loader. Heavy testing is required because it is hard to be make sure smoke still works as before (testing is the hardest part actually). [[User:Seb76|Seb76]] 14:09, 18 September 2008 (PDT)

=== Alien AI ===

====Aliens better with explosions====
Partly implemented [[User:Seb76#Bug Fixes|here (waypoint bug fix)]] and [[User:Seb76#Mods|here (Blaster drift)]]. ''(Possibly move this to talk, as notwithstanding these 2 bugs, apparently the Aliens are fairly safe with lethal explosives.)''

I wish that aliens using grenades or blaster bombs or stun bombs (anything that goes boom) would use more sense. They should not want to use items that go boom when they are guaranteed to be caught in the blast radius. The alien can use grenades and blaster bombs by going out of line of sight before the explosion goes off. That may not save them if the explosion blows out the walls. At least it would be less stupid then firing a point blank blaster bomb vs taking 5 steps and setting up another waypoint. Units with morale above 100 or mind controlled should still be suicidal as normal.--[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)

: Actually, the aliens are quite careful with their explosives, they just seem to be prone to the occasional accident. They're not likely to fire off a blaster or grenade too close to them - as evident by the strategy where if you see an alien with a BB but can't shoot back, the safest place is to stand next to it. The blaster bomb vertical waypoint fix in the loader also eliminates the 'oops' moments where they plot a vertical right angle too close to themselves and there just happens to be a wall to the south. However, they do need more care with stun bombs as you often get to see an alien fire a stun bomb point blank into a HWP parked next to it. But I guess we are talking about three different weapon types here, so they may not be as careful with a standard firearm as they are with grenades and the BB. Wish the Apocalypse aliens at least had as much sense as the UFO/TFTD aliens. In that game, they're utterly psychotic with explosives and ignore nearby allies. -[[User:NKF|NKF]] 14:34, 19 September 2008 (PDT)

= Category =
The page needs to be listed in various categories, which ones I don't know. Also links on other pages to this one would aid people finding it.

: OK how about this one: [[User:Spike|Spike]] 12:21, 3 September 2008 (PDT)

[[Category:Oddities and bugs]]

User talk:Seb76

2009-04-03T00:09:43Z

Kyrub: /* Glitches with Alien Pets */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

User talk:Seb76

2009-04-02T20:22:51Z

Kyrub: /* Glitches with Alien Pets */

User talk:Seb76

2009-04-02T01:43:43Z

Kyrub: /* Glitches with Alien Pets */

User talk:Seb76

2009-04-02T00:26:40Z

Kyrub: /* Glitches with Alien Pets */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an IDA based work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)

User talk:Seb76

2008-09-25T13:15:59Z

Kyrub: /* Facility maintenance cost bug */

Wish List (EU)

2008-09-23T22:54:20Z

Kyrub: /* Decrease Accuracy for targets out of sight */ added link to discussion

X-Com is a great game and as evidence just look to the fact this wiki exists even though the game pre-dates the internet. In all it's greatness X-Com has some elements and behaviors players wish they could change. This is a repository of those desires. Some day a fan mod may make your wish come true...

== I Wish... ==
State what you want AND what X-com does normally. Sign your name if you think "Oh man! That would be great!"
=== Fuel Ready always ===
I wish that I could send out craft at any fuel or ammo level. Normally craft can only leave a base if fully "ready". Craft is only "ready" at 100% fuel (or 0% fuel using an exploit) but there's no logical reason why a full tank and full ammo is required. Fully repaired... that's fine. I can live with pilots refusing to fly a plane missing a wing even if it means England is lost to aliens. 15 hours to fill a tank? Retarded but I can live with that too if I can send out a craft at 20% fuel.
--[[User:Brunpal|Brunpal]]

:Actually, many modern aircraft '''do''' require the fuel tanks to be full on takeoff, and fairly empty on landing. The weight of the fuel is figured into the takeoff aerodynamics, and the tank being full prevents fuel 'sloshing' in the tanks and not actually making it to the engine. (Conversely, many aircraft need to have dispensed of much of that fuel weight before landing.) This holds for most runway-takeoff craft, but may not apply to anything with VTOL capacity; I'm unsure there.

:I do agree that non-full weapons aren't as critical, though. But from a logical standpoint, most modern aircraft should not be launched on an empty fuel tank. I also should noted that an Elerium-fueled craft with [[Known_Bugs#Elerium-fueled_Craft_Bug|50% fuel or less remaining]] will automatically return to base, regardless of distance from base. Of course, given that such craft fuel up quickly, its less of an issue there. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:05, 7 August 2008 (PDT)

:Hum, maybe you can try [[User:Seb76#Mods|this]]? [[User:Seb76|Seb76]] 13:01, 8 August 2008 (PDT)
::Thanks! But I can't try it. I've not been able to get my copy of Xcom to run properly except on a Win98 install. VC2008 requires a more modern OS. I'm sure I could ''eventually'' figure out a way to get it running, but I tried once and wasted too much time before giving up.--[[User:Brunpal|Brunpal]] 14:45, 8 August 2008 (PDT)
:AFAIK VC2008 binaries should run OK on Win98 as long as the runtime is deployed. Anyway, the loader uses CreateRemoteThread API which is not available in Win98 so don't even bother. '''However''', you can manually patch the binary if you want ;-) Data to patch (all in hexadecimal):
offset 0x41752: 2A0075 -> 18207C
:HTH. [[User:Seb76|Seb76]] 14:56, 8 August 2008 (PDT)

=== Smarter on Globe ===
I wish all craft understood the shortest distance between two points on a globe is a curved path towards the poles. Normally a craft goes in the opposite direction than it should (towards the equator). Pain in the ass when the base in the UK sends a craft to Siberia.
--[[User:Brunpal|Brunpal]]

===Equipment Management===

==== Soldiers remembers THEIR equipment ====
I wish soldiers remembered what equipment they LAST used and start with that gear when they land. Normally soldiers grab various gear and put lots of crap on their belt. I put most things on the shoulder slots, and keep many things spare things on the ship just in case I need them. (I only want IN rounds if it's night. Stop picking them up before I shoot you in the back!) Takes forever to sort out the gear so the weakling isn't carrying all the rockets etc.
--[[User:Brunpal|Brunpal]]

:This is already available in [[XcomUtil]]. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:07, 7 August 2008 (PDT)

====Access to Stats screens during equipment allocation====

In Battlescape you can get to Stats screens by right clicking on one of the unit's status bars. However you can't do this in the Equipment screen. Things like Statstrings and (even more so) [[User:Seb76|Seb76]]'s modified Equipment screen with actual/max weight help. But it would be nice to be able to see exact stats. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Fog of War Mk. 2===

I'm sure most of these would be an absolute PAIN to implement, but I figured I'd toss the ideas out here.

====Blind Dropship Pilots====
One thing that has always irked me is X-COM has no terrain knowledge when it lands, despite having probably circled the place two or three times before landing and thus they should know at least some of the area. This would be nice, but isn't too important. Probably would be a pain to implement so X-COM would have all knowledge of external features but no knowledge of building interiors, anyways. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

:Yes at the very least, when you splash the UFO, it could tell you (via some miracle technology such as "satellite reconnaisance") what the terrain type is of the landing zone area. Then you could adjust equipment accordingly. And adjust your uniform camouflage (if using one of the uniform mods). [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: Geoscape: center on the site, then maximum zoom. Aside from having to disambiguate forest from jungle, this works fine for knowing the exact terrain you're getting into. -- [[User:Zaimoni|Zaimoni]] 10:17, 4 Sept 2008 (CDT)

:::This is already present in the game. To center the Geoscape on a specific location, right-click on the target spot. To do maximum zoom in, right click on the Zoom-In button(and the same works for Zoom-Out). Also, Jungle and Forest use the same display algorithm, but are easy to differentiate; Forest occurs NORTH of the equator, and Jungle occurs SOUTH. [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:23, 4 September 2008 (PDT)

====Moving Fog====

The Fog of War in X-COM is clumsily implemented, compared to modern expectations. Everything starts out black, but after exploring, is shown...and it's kept in the same showing, regardless of whether you actually have LoS to that area anymore. It would be nice if when you no longer had Line of Sight to a particular map area, it would be cloaked in a way so that you knew the terrain, but not the units there. Since I've sometimes spent over half an hour trying to hunt down that last alien hiding in area I'd already explored. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

====Deactivate Object Radar====

Currently, in X-COM, any objects dropped in a given square show on your Battlescape, regardless of whether you have Line of Sight to the square or not. In regards to dropped weapons/grenades/equipment/dead soldiers/dead aliens, this doesn't make a large difference. But in the case of STUNNED aliens, a quick scan across the Battlescape can tell you whether the alien you stunned 10 turns ago is still down, or stood back up(the stunned alien object will disappear from the stack). Of course, since aliens which have revived from stun are almost always disarmed(and the ones that aren't probably should've been killed instead), the usefulness of this 'exploit' is reduced mainly to finding out that the last alien you're looking for is just wandering aimlessly and unarmed. Perhaps leave stacks showing the same until you regain LoS to that area? [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

===Score for retaliation Battleships===

When a Battleship on retaliation attacks your base and is shot down, you get no score for it. This is completely illogical and it discourages any use of base defences. You should get normal 700 (or even 1400) points for it.
--[[User:Kyrub|Kyrub]] 14:05, 30 August 2008 (PDT)

: I'm not sure about this. Yes it's illogical, but it could also be a licence to get a huge score if you have a strong enough base. [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: The impenetrable base setup would turn into a cheat. As the aliens will keep hammering the base with a battleship until one breaks through, you'll have a steady supply of points without having to really do anything. Some balancing, such as paying to rearm your defence modules, ought to be thrown in to balance things out. -[[User:NKF|NKF]] 23:13, 13 September 2008 (PDT)
:::A better fix would be to remove the retaliation flag when a battleship is destroyed. If someone can post a savegame with a never-ending flow of base attacks, I may have a look at the fix. [[User:Seb76|Seb76]] 01:05, 15 September 2008 (PDT)

===Decrease Accuracy for targets out of sight===

How come you can easily shoot on something you do not see?
I find the over-used scout-sniper tactic is a cheap exploit of the X-COM. The tactical game should describe a combat, not a cowardly shooting practice. It would turn into a nice feature, if there would be a penalty of (let us say) -20% to the accuracy of anybody who is firing on a target out of his current sight. This can greatly enhance the tactical depth of the game. (Seb around? ;-) --[[User:Kyrub|Kyrub]] 14:20, 30 August 2008 (PDT)

...discussed [http://www.ufopaedia.org/index.php?title=Talk:Wish_list here]

===Enough Smoke===

It would be nice to increase the current limit on smoke/fire hexes. This is due to their locations being stored in a small, fixed length array. In effect you can only get about 3-4 smoke grenades worth of smoke or fire on the map at the same time. Being able to use smoke liberally would really open up new tactics. At the moment all you can really do is cover the LZ in smoke when you exit the transport, and maybe cover one advance over open ground. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)
:I did something for that on my loader. Heavy testing is required because it is hard to be make sure smoke still works as before (testing is the hardest part actually). [[User:Seb76|Seb76]] 14:09, 18 September 2008 (PDT)

===Restore Game from Battlescape===

It would be nice to be able to reload a saved game directly from the Battlescape "?" screen, rather than having to go through the process of Abandoning to the Geoscape. Would you need to check it was a Battlescape save and not a Geoscape save? Maybe, maybe not. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Warm Grenades===

Currently when you set the timer on a grenade (or HE pack), the timer runs down every turn regardless of whether the grenade is worn, held, or dropped. Then, when the timer runs out, it explodes unless it is held or worn. There is no real grenade or explosive that works this way. Once the timer (fuse) starts running, they explode regardless. However for most hand grenades, the timer (fuse) doesn't start until after you throw/drop the grenade. It would be nice to have both of these real world behaviours, and lose the game's default behaviour. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

: Technically the way the game implements grenades, they don't have a timer. At least, not as such. When you set a grenade, the game just assigns it a turn to blow up on. Once the turn has passed, the game checks to see that it's on the ground and blows it up if it is, otherwise it doesn't. I believe Seb76 has already addressed this in his patches where there's an option to make grenade blow up regardless whether they are in inventory or otherwise the moment the timer is set. X-Com Apocalypse does a good job of this. The moment the grenade is so much as moved after the timer is set, it counts down. - [[User:NKF|NKF]] 23:01, 13 September 2008 (PDT)

:: To simulate an actual timer, you would need to do something like: Every turn that a primed grenade is being held by a unit during the "explode" check, increment by +1 the turn when that grenade is going to explode. [[User:Spike|Spike]] 19:10, 14 September 2008 (PDT)
:::I think I would change quantity2 ([[OBPOS.DAT]]) to a countdown instead of a turn, and use quantity3 as a flag indicating if the count has started. This flag is set any time a turn ends and the grenade has no owner. Taking it back in your hand once the timer has started won't help and the thing must be thrown... quantity2 is decreased if quantity3 is set, and the grenade blows up as usual. [[User:Seb76|Seb76]] 01:35, 15 September 2008 (PDT)

===Stun Grenades===

I want flashbangs.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)
:Instead of stunning, I'd see more effect if it would remove some TUs to units having line of sight (to be fare it should affect xcom units too). It would help against reaction fire (which is the point of flashbangs). Given that grenades detonate at the end turns, it would require a good coordination to have the grenade detonate exactly at the end of the alien turn, and just before your attack. Being able to open doors à la xcom2 would also help to throw flashbangs just before a craft assault... [[User:Seb76|Seb76]] 22:03, 12 September 2008 (PDT)
::That would be good. Hard to program, potentially extremely unbalancing, but good. I considered a "debuff" kind of ability (as you suggest) for flashbangs, vs the more obvious substitution of [[stun]] for [[HE]] damage. In the end, I picked "I want flashbangs."--[[User:Brunpal|Brunpal]] 03:32, 13 September 2008 (PDT)
: Maybe flashbangs dont' work on Aliens - otherwise, XCom would use them, right? :) But seriously, I too would like flashbangs, and stun grenades / concussion grenades. Both of these would make the game easier, though. With flashbangs, you might have to compensate by just giving the aliens more TUs. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)
::More options for the player is going to make it easier for any kind of game. Particularly of games like XCOM where the computer can't take advantage of the changes. However I don't believe a weak stun grenade (like 44 stun damage, comparable to AC-HE) would change the game much because the 80 item limit remains.--[[User:Brunpal|Brunpal]] 22:21, 13 September 2008 (PDT)

===Night Vision===

I '''don't''' want to add night vision equipment to the game. I assume that either (1) all XCom units already have night vision gear as standard, but it's not as good as alien night vision, and the visibility that XCom units have at night is based on their standard-issue night vision gear, or (2) night vision gear does not work on Aliens. Either they do not appear on night vision, or maybe worse - maybe the aliens can manipulate night vision equipment, causing worse than normal vision, or hallucinations, and even tricking XCom units into firing on each other. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)

===Throwing over stuff===

I want to throw stuff over other stuff. I don't find grenades useful. I much rather shoot a rocket launcher from outside reaction shot range because even when you miss, odds are it's close enough. The throw itself has an arc trajectory and can hit the ceiling (a feature I like) but to pick the target it has to have straight line of sight (like a bullet) which is stupid. I want to throw onto the top of buildings where I ''can't see'', or bounce a grenade off the ceiling and over the head of a squadie ''because '' I don't have line of sight with a gun. If I had line of sight, I would just shoot since that costs less TU even if I already had an armed grenade.

The easiest way to accomplish this is to keep "out of range" but remove "you can't throw there" and just let a solider throw to any square they want. A better way is to keep the warning but give the player the option to try the throw anyway. If you can't really throw there, then oops... that's your badly positioned live grenade to deal with.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)

:I did some tests disabling the "you can't throw there" check and it does not work. The grenade ends up in the vicinity of the throwing unit. Actually the line of sight is not used when throwing objects. I'm 98% sure it simulates the throwing of the object and if it intercepts anything, the throw is refused. [[User:Seb76|Seb76]] 04:47, 13 September 2008 (PDT)

:: The explicit emulation of the trajectory has been verified as part of the throwing range testing by [[User:Zombie|Zombie]] and myself. The range bands are not consistent with a continuous model; they look like a table lookup from the same source 3rd ed. GURPS (Steve Jackson Games) uses. -- [[User:Zaimoni|Zaimoni]] 8:21 13 September 2008 (CDT)

:::Units don't need LOS to an area to throw a grenade, as evidenced by my favored tactic of chucking an Alien Grenade or HE Pack into any Medium or Large Scout which has had the roof blown away in the crash from outside to 'pacify' any remaining crew. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:22, 13 September 2008 (PDT)

Really? It never seems to work for me. Always requires me to have line of sight. For example tossing in a grenade into the roof hole doesn't work for me if the solider is on level 0 and I target a square inside at level 0. The walls and door obviously block the LoS. However I can target an area on level 1 or 2 in mid air and throw to that location where it naturally drops down to level 0. However I have line of sight to those higher levels in that case.
That's an acceptable compromise in many cases but in others it fails completely. For example having an alien on the top of a 2 story building (level 2) in the middle and a solider standing next to the building and not being able to toss a grenade onto the center of the roof. I could toss a ball there in real life. I wouldn't have thought the trajectory would have been high/steep enough to hit the "sky roof".--[[User:Brunpal|Brunpal]] 22:04, 13 September 2008 (PDT)

: Just how strong are your soldiers? The stronger they are, the higher their toss. There are various occasions where you don't need to see where you're throwing to throw. For example, try tossing grenades over a tall fence or hedge. A High Explosive pack into the apple orchard that is surrounded by a hedge on farm maps is often an easy way to smoke out any hidden aliens - and the orchard. One likely cause why you can't throw inside the UFO is that there's something in the way inside that's preventing the throw, such as a wall. Try adjusting your throwing destination, or reposition your soldier for a better throwing angle.

: I've often found grenades to be much more reliable than a directional attack early in the game where firing accuracy is much lower. You ought to try playing a few of the simpler missions like supply ship or large scout assaults with an all-grenadier cast. Takes a bit of planning to not destroy much of the loot, but otherwise literally a blast. -[[User:NKF|NKF]] 22:52, 13 September 2008 (PDT)

===Enforced Variant Games===

Various people like to play various variant games, such as No Alien Technology, or No Detection, or No Lethal Weapons - see for example Scott Jones' notes to XComUtil. It would be nice to have options on the game executable to enforce these scenarios. Self restraint is hard! [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Assault Time Limit===

One of the cool things about UFO Defence is there are no time limits on the scenarios. This is great as it allows for a totally different kind of tactics and much more flexibility.
It's more of a "thinking man's game" as a result. But... arguably this is not very realistic for UFO Assault missions. If the Aliens are getting creamed, they should try to make a getaway if they can (just like XCom would). A simple way to implement this would be a hard time limit (say 20 turns?) on a UFO Assault. Another way would be to base it on Alien Morale. At a certain Morale level the aliens decide to dust off. Give the player say 3 turns warning while they rev up the engines. Then if there is still a Navigator or Engineer in the Control Room alive, the ship takes off. Any XCom troops still aboard are MIA.

You might run into problems if the UFO took off but then landed again or was shot down, generating another ground mission with potentially '''more''' Aliens than were still alive at the end of the Assault. (Still, maybe they hatch some more clones if they get time to....) [[User:Spike|Spike]] 09:51, 4 September 2008 (PDT)

: It strikes me as justified they don't do that. Troops loose in the vessel could be seriously bad. It would be nice if they dusted off on the condition that their morale was low enough or 3 X-com soldiers had the door in their sights without aliens alive outside in the latter case and no X-com soldiers on board in either case. also, if the UFO has a hole in either the command or engine room, it would have to set down before leaving the atmosphere. [[User:(name here)|(name here)]]

===Base Build Stacking===

At the moment you are only allowed to build next to a finished module, and you aren't allowed to plan ahead in your base construction. It would be nice to at least be able to plan more than one phase of construction in advance. This would be pretty easy to implement. There is no need to code any new "queuing system". Just place the new module next to an existing under-construction module, but increment the build time to the normal build time + the time remaining on the under-construction module (the lowest time remaining that would make the square you are building in, a legal square to build in). As a premium for build stacking, you have to pay the costs up-front. As with normal construction, all costs are non-refundable if you change your mind. (There would probably need to be some on-screen feedback for how long the module would take to build, before you were committed to building it.) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Recuit Certain Enemy===

Consider that not all alien loyal to its master (most TFTD alien has a device lodged to its brain), it should be interesting (or at least cool) if we can recuit such alien. Maybe we can replace those controling device from captive alien after research that specie. Or convince head of the Snakemen that it would be far more benefit to help us instead of the Ethereal [[User:L-Zwei|L-Zwei]] 23:25, 12 September 2008 (PDT).

Only certain alien types should be recruitable. Ones that should NOT be include Mutons (as they are directly controlled by Ethereals), Chrysallids (unbalancing), etc. It would be nice to be able to reverse-engineer Cyberdiscs or Sectopods, or make it that a Cyberdisc must be researched to build hovertanks/etc.
[[User:MagicJuggler|MagicJuggler]] 13:32, 18 September 2008 (PDT)

===Alien AI===
====Attempts to rearm====
Aliens cannot pick up items, but I wish they would. If an alien has no useful weapons in inventory they should either head for cover or head for a plasma weapon. Panicked aliens drop their weapons but never seem to pick them up when they managed to pull themselves together. It would be nice if they tried to arm themselves again. --[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)

====Aliens better with explosions====
I wish that aliens using grenades or blaster bombs or stun bombs (anything that goes boom) would use more sense. They should not want to use items that go boom when they are guaranteed to be caught in the blast radius. The alien can use grenades and blaster bombs by going out of line of sight before the explosion goes off. That may not save them if the explosion blows out the walls. At least it would be less stupid then firing a point blank blaster bomb vs taking 5 steps and setting up another waypoint. Units with morale above 100 or mind controlled should still be suicidal as normal.--[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)

: Actually, the aliens are quite careful with their explosives, they just seem to be prone to the occasional accident. They're not likely to fire off a blaster or grenade too close to them - as evident by the strategy where if you see an alien with a BB but can't shoot back, the safest place is to stand next to it. The blaster bomb vertical waypoint fix in the loader also eliminates the 'oops' moments where they plot a vertical right angle too close to themselves and there just happens to be a wall to the south. However, they do need more care with stun bombs as you often get to see an alien fire a stun bomb point blank into a HWP parked next to it. But I guess we are talking about three different weapon types here, so they may not be as careful with a standard firearm as they are with grenades and the BB. Wish the Apocalypse aliens at least had as much sense as the UFO/TFTD aliens. In that game, they're utterly psychotic with explosives and ignore nearby allies. -[[User:NKF|NKF]] 14:34, 19 September 2008 (PDT)

==Fix All Bugs==

Oh no [[User:Seb76|Seb76]] already did this! :) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

== Category ==
The page needs to be listed in various categories, which ones I don't know. Also links on other pages to this one would aid people finding it.

: OK how about this one: [[User:Spike|Spike]] 12:21, 3 September 2008 (PDT)

[[Category:Oddities and bugs]]

SOME MORE WISH LIST STUFF

I have already listed most of this wish list on Sep’s excellent loader page. Didn’t know this page existed till now.

1. When the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?

2. If you psi control a human (civilians) in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control.

3. Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).

4. 80 item bug on base defense mission

5. I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!

6. I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).

7. This one is way out there. Alien v Alien battles out with main game, just random battlescape maps. Sectoid and their terrorists against Floaters and theirs etc. One side human controlled the other computer. Choice of ships involved etc.

These are a couple of new ones, just thought of them

8. moved

9. Open doors like they do in TFTD (I know this is mentioned above with the good stun grenades idea).

10. New graphics for the Interceptor and Firestorm on the battlescape. All your ships could remain in their hangers when the aliens attack your base. Don’t understand why Mythos did not do this originally.
: Simply for one reason: the limit on the size of the battlescape. UFO maps are usually limited to 10000 tiles (50x50x4), on Bases you have 9600 (60x60x3), the last level one being dirt. You need 3 levels to display X-COM craft. [[User:Hobbes|Hobbes]] 14:28, 23 September 2008 (PDT)

Wish List (EU)

2008-09-23T20:00:12Z

Kyrub: /* Decrease Accuracy for targets out of sight */

X-Com is a great game and as evidence just look to the fact this wiki exists even though the game pre-dates the internet. In all it's greatness X-Com has some elements and behaviors players wish they could change. This is a repository of those desires. Some day a fan mod may make your wish come true...

== I Wish... ==
State what you want AND what X-com does normally. Sign your name if you think "Oh man! That would be great!"
=== Fuel Ready always ===
I wish that I could send out craft at any fuel or ammo level. Normally craft can only leave a base if fully "ready". Craft is only "ready" at 100% fuel (or 0% fuel using an exploit) but there's no logical reason why a full tank and full ammo is required. Fully repaired... that's fine. I can live with pilots refusing to fly a plane missing a wing even if it means England is lost to aliens. 15 hours to fill a tank? Retarded but I can live with that too if I can send out a craft at 20% fuel.
--[[User:Brunpal|Brunpal]]

:Actually, many modern aircraft '''do''' require the fuel tanks to be full on takeoff, and fairly empty on landing. The weight of the fuel is figured into the takeoff aerodynamics, and the tank being full prevents fuel 'sloshing' in the tanks and not actually making it to the engine. (Conversely, many aircraft need to have dispensed of much of that fuel weight before landing.) This holds for most runway-takeoff craft, but may not apply to anything with VTOL capacity; I'm unsure there.

:I do agree that non-full weapons aren't as critical, though. But from a logical standpoint, most modern aircraft should not be launched on an empty fuel tank. I also should noted that an Elerium-fueled craft with [[Known_Bugs#Elerium-fueled_Craft_Bug|50% fuel or less remaining]] will automatically return to base, regardless of distance from base. Of course, given that such craft fuel up quickly, its less of an issue there. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:05, 7 August 2008 (PDT)

:Hum, maybe you can try [[User:Seb76#Mods|this]]? [[User:Seb76|Seb76]] 13:01, 8 August 2008 (PDT)
::Thanks! But I can't try it. I've not been able to get my copy of Xcom to run properly except on a Win98 install. VC2008 requires a more modern OS. I'm sure I could ''eventually'' figure out a way to get it running, but I tried once and wasted too much time before giving up.--[[User:Brunpal|Brunpal]] 14:45, 8 August 2008 (PDT)
:AFAIK VC2008 binaries should run OK on Win98 as long as the runtime is deployed. Anyway, the loader uses CreateRemoteThread API which is not available in Win98 so don't even bother. '''However''', you can manually patch the binary if you want ;-) Data to patch (all in hexadecimal):
offset 0x41752: 2A0075 -> 18207C
:HTH. [[User:Seb76|Seb76]] 14:56, 8 August 2008 (PDT)

=== Smarter on Globe ===
I wish all craft understood the shortest distance between two points on a globe is a curved path towards the poles. Normally a craft goes in the opposite direction than it should (towards the equator). Pain in the ass when the base in the UK sends a craft to Siberia.
--[[User:Brunpal|Brunpal]]

===Equipment Management===

==== Soldiers remembers THEIR equipment ====
I wish soldiers remembered what equipment they LAST used and start with that gear when they land. Normally soldiers grab various gear and put lots of crap on their belt. I put most things on the shoulder slots, and keep many things spare things on the ship just in case I need them. (I only want IN rounds if it's night. Stop picking them up before I shoot you in the back!) Takes forever to sort out the gear so the weakling isn't carrying all the rockets etc.
--[[User:Brunpal|Brunpal]]

:This is already available in [[XcomUtil]]. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:07, 7 August 2008 (PDT)

====Access to Stats screens during equipment allocation====

In Battlescape you can get to Stats screens by right clicking on one of the unit's status bars. However you can't do this in the Equipment screen. Things like Statstrings and (even more so) [[User:Seb76|Seb76]]'s modified Equipment screen with actual/max weight help. But it would be nice to be able to see exact stats. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Fog of War Mk. 2===

I'm sure most of these would be an absolute PAIN to implement, but I figured I'd toss the ideas out here.

====Blind Dropship Pilots====
One thing that has always irked me is X-COM has no terrain knowledge when it lands, despite having probably circled the place two or three times before landing and thus they should know at least some of the area. This would be nice, but isn't too important. Probably would be a pain to implement so X-COM would have all knowledge of external features but no knowledge of building interiors, anyways. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

:Yes at the very least, when you splash the UFO, it could tell you (via some miracle technology such as "satellite reconnaisance") what the terrain type is of the landing zone area. Then you could adjust equipment accordingly. And adjust your uniform camouflage (if using one of the uniform mods). [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: Geoscape: center on the site, then maximum zoom. Aside from having to disambiguate forest from jungle, this works fine for knowing the exact terrain you're getting into. -- [[User:Zaimoni|Zaimoni]] 10:17, 4 Sept 2008 (CDT)

:::This is already present in the game. To center the Geoscape on a specific location, right-click on the target spot. To do maximum zoom in, right click on the Zoom-In button(and the same works for Zoom-Out). Also, Jungle and Forest use the same display algorithm, but are easy to differentiate; Forest occurs NORTH of the equator, and Jungle occurs SOUTH. [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:23, 4 September 2008 (PDT)

====Moving Fog====

The Fog of War in X-COM is clumsily implemented, compared to modern expectations. Everything starts out black, but after exploring, is shown...and it's kept in the same showing, regardless of whether you actually have LoS to that area anymore. It would be nice if when you no longer had Line of Sight to a particular map area, it would be cloaked in a way so that you knew the terrain, but not the units there. Since I've sometimes spent over half an hour trying to hunt down that last alien hiding in area I'd already explored. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

====Deactivate Object Radar====

Currently, in X-COM, any objects dropped in a given square show on your Battlescape, regardless of whether you have Line of Sight to the square or not. In regards to dropped weapons/grenades/equipment/dead soldiers/dead aliens, this doesn't make a large difference. But in the case of STUNNED aliens, a quick scan across the Battlescape can tell you whether the alien you stunned 10 turns ago is still down, or stood back up(the stunned alien object will disappear from the stack). Of course, since aliens which have revived from stun are almost always disarmed(and the ones that aren't probably should've been killed instead), the usefulness of this 'exploit' is reduced mainly to finding out that the last alien you're looking for is just wandering aimlessly and unarmed. Perhaps leave stacks showing the same until you regain LoS to that area? [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

===Score for retaliation Battleships===

When a Battleship on retaliation attacks your base and is shot down, you get no score for it. This is completely illogical and it discourages any use of base defences. You should get normal 700 (or even 1400) points for it.
--[[User:Kyrub|Kyrub]] 14:05, 30 August 2008 (PDT)

: I'm not sure about this. Yes it's illogical, but it could also be a licence to get a huge score if you have a strong enough base. [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: The impenetrable base setup would turn into a cheat. As the aliens will keep hammering the base with a battleship until one breaks through, you'll have a steady supply of points without having to really do anything. Some balancing, such as paying to rearm your defence modules, ought to be thrown in to balance things out. -[[User:NKF|NKF]] 23:13, 13 September 2008 (PDT)
:::A better fix would be to remove the retaliation flag when a battleship is destroyed. If someone can post a savegame with a never-ending flow of base attacks, I may have a look at the fix. [[User:Seb76|Seb76]] 01:05, 15 September 2008 (PDT)

===Decrease Accuracy for targets out of sight===

How come you can easily shoot on something you do not see?
I find the over-used scout-sniper tactic is a cheap exploit of the X-COM. The tactical game should describe a combat, not a cowardly shooting practice. It would turn into a nice feature, if there would be a penalty of (let us say) -20% to the accuracy of anybody who is firing on a target out of his current sight. This can greatly enhance the tactical depth of the game. (Seb around? ;-) --[[User:Kyrub|Kyrub]] 14:20, 30 August 2008 (PDT)

: There is a penalty. Bullet drift. The further away you are, the more this will impact the bullet, potentially making even a 100% accurate shot miss. Also X-Com maps are pretty small, and the aliens already cheat enough as it is to make things difficult even with the sniper/scout strategy. In Apocalypse they addressed this with adding weapon ranges. But then, even some weapons were capable of shooting beyond the unit's ability to see an enemy target. - [[User:NKF|NKF]] 23:07, 13 September 2008 (PDT)

::That's not really a good reason for me. 1) Bullet drift has a very small effect in the game, because the actual percents are set quite high. Example: if you spray an unseen alien from the other corner of the map with autofire of 35%, you'll get a 73,6% chance to hit with at least one bullet. Physics and game balance, adieu. 2) Moreover, bullet drift has nothing to do with not seeing the target. It should be the contrary, you ACCIDENTALLY hit something you don't see, no? 3) You get a penalty for handling two weapons in the same time. Why couldn't we take the same penalty (80%*Acc) for the hit-out-of-sight? (Well, I can't do this actually, maybe others can)--[[User:Kyrub|Kyrub]] 18:25, 14 September 2008 (PDT)

: I don't agree that bullet drift is already there as a penalty, since this doesn't distinguish between seen and unseen targets at all (ok it does indirectly, only in so far as unseen targets tend to be further away). I think we should look at 3 cases: 1. person firing did not happen to be the one who '''spotted''' the target. 2. person firing '''could not''' see/spot the target under any circumstances. In the first case, we can assume the firer has visual contact with the target, after someone else pointed it out. No accuracy penalty should be applied (maybe a TU penalty?). In the second case, there should be an accuracy penalty. 80% would be generous, I would go for 50%. Or maybe something non-linear, so that autofire percentages would not fall by as much as aimed fire and snap fire percentages. One problem you have is how to present these two different cases to the player before they take the shot. It's a bit obscure if you just show them a lower hit probability without explaining why. [[User:Spike|Spike]] 19:02, 14 September 2008 (PDT)

:: Bullet drift is an effect on range (actually it has quite a major effect on the blaster bomb), but yes it's not because of whether or not the unit can see the alien. But then again, the maps are small. If you ever took lots of screen shots of the map and made a large composite from them, you'd find that the area of operations is very tiny and that the 20 tile visual range means that our avatars are quite short sighted. That's not realistic either, but imposed for game balance. Other tactical games appear to handle the accuracy vs. range dropoff issue by combining the shooter's skill and the weapon's maximum range. Basically you can operate the weapon to the best of the shooter's ability within the maximum range, but the further away you try to aim, accuracy is decreased. In some games, you even get to see the effect on the accuracy before you pull the trigger as the accuracy is attached to the cursor. - [[User:NKF|NKF]] 22:46, 14 September 2008 (PDT)

:::Actually the blaster bomb "drift" issue is not mainly caused by drift, but by accuracy adjustment between each waypoint (60% for xcom players, 55% for aliens). Maybe we can cook a kind of "max effective range" for a weapon base on firing mode (auto<snap<aimed) and gun type (pistol/rifle). Firing above this range would decrease the accuracy. [[User:Seb76|Seb76]] 01:03, 15 September 2008 (PDT)

:::: (to NKF) The main flaw of the whole "shoot the unseen" thing is the aliens cannot shoot back at somebody shooting at them (no reaction fire). If they could (or if they'd shoot at least the soldier they see), I wouldn't complain. This destroys the battle tactics side of the game, you just sent a man to "spot them". Nota bene, they cannot use the same scout-sniper tactic, the way we do, either. (This would be most annoying, by the way).
::::(to Seb76) Effective range would restore some balance and add some use to the aimed shots. I thought about a simpler solution with ''substracting'' some accuracy (which would make auto useless, snap into a poor and aimed into a solid chance-to-hit). Your suggestion is much more elegant, Seb, if you can cook it ;-) --[[User:Kyrub|Kyrub]] 08:00, 18 September 2008 (PDT)

::: Fair enough, but do note that even your units cannot react against an alien that they cannot see within their visual range. Attacks of opportunity and actively taking your turn are two different tasks after all. I'm not sure the aliens would be such sportsmen though. It might be worth looking into whether there is cooperation amongst the aliens while they are taking their turn - and I think I just have the scenario savegame to test this. If I could find it. BBs probably break the rules of basic firearms and range, and mind control has its own set of rules, so probably wouldn't count. -[[User:NKF|NKF]] 00:37, 19 September 2008 (PDT)
::::Hmm, maybe we could have accuracy impacted like this:
::::*aimed shot: no range penalty
::::*snap shot: penalty if shooting beyond visual range (reaction fire is not impacted since it uses snap shots)
::::*auto shot: no penalty if shooting under night visual range, small penalty if between day and night range, big penalty if above visual range.
::::Maybe we can use a function of the distance for the penalty instead of hard values. What do you think? [[User:Seb76|Seb76]] 16:53, 19 September 2008 (PDT)

How about you reduce accuracy by (Effective Range / Actual Range), whenever Actual Range > Effective Range. This could be applied for all attacks, and applied again (or another factor applied) for out-of-sight targets. I would suggest that the effective ranges, in relative terms, are something like this order (highest to lowest):

*HWP / Terrorist weapons
*Heavy Laser
*Rocket Launcher
*Heavy Cannon
*Laser Rifle (or higher up for this one?)
*Rifle
*Plasma Rifle
*Auto Cannon
*Heavy Plasma
*Pistols (Laser Pistol, Pistol, Plasma Pistol)

(Yes I'm prejudiced against plasma weapons but I'd like to rebalance the game a bit. All that plasma just expands too quickly and interacts with our atmosphere too much for the bolt to stay coherent over longer ranges.)

Now, apart from the problem of coming up with the values for Effective Range for each weapon - where would they be stored? [[User:Spike|Spike]] 10:45, 20 September 2008 (PDT)
:The point of using visibility range only is not to have to specify effective range per weapon; tuning good balanced values can be quite difficult. As for their storage, they can be hard-coded in the loader, or defined in the ini file. [[User:Seb76|Seb76]] 05:23, 21 September 2008 (PDT)
:: Good point, tuning it correctly is very tricky, it would be easier just to use visibility range rather than creating new "max effective range" for various weapons and making sure it's balanced. A couple of other options when the sniper is outside visual range: 1. disallow the attack with an "Out of Range" message. 2. allow the attack but only for Aimed Fire, otherwise give an "Out of Range for [Snap Fire|Auto Fire]" message. As was mentioned, this restores some use to Aimed Fire which otherwise is under-used. For this to make sense, we would have to take the interpretation that "visibility range" means "spotting range". Clearly it does not make sense to be able to do Aimed fire at something you cannot possibly see at all, even if you know where to look for it. So if, on the other hand, we assume that an out-of-range sniper can't see his target at all, the accuracy should be reduced to something lower than the lowest accuracy of the weapon - say half of auto or snap accuracy. [[User:Spike|Spike]] 05:49, 21 September 2008 (PDT)
(Off Topic: this all should be now moved to the 'talk' page, no? Can anybody do it?)
:Let us keep the change simple! When the game mechanics are too complicated (for the realism purpose or other), you lose control over the way the game is played. While I understand your points, Spike, I'd personnally go with what Seb76 has suggested: Aimed - no penalty, Snap - penalty at vision range (20), Auto, Full auto - penalty on night (9) range. Plus the customization in the ini file. We need to rethink all the launchers, I could let them with no penalty (they seem to be guided).--[[User:Kyrub|Kyrub]] 13:00, 23 September 2008 (PDT)

===Enough Smoke===

It would be nice to increase the current limit on smoke/fire hexes. This is due to their locations being stored in a small, fixed length array. In effect you can only get about 3-4 smoke grenades worth of smoke or fire on the map at the same time. Being able to use smoke liberally would really open up new tactics. At the moment all you can really do is cover the LZ in smoke when you exit the transport, and maybe cover one advance over open ground. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)
:I did something for that on my loader. Heavy testing is required because it is hard to be make sure smoke still works as before (testing is the hardest part actually). [[User:Seb76|Seb76]] 14:09, 18 September 2008 (PDT)

===Restore Game from Battlescape===

It would be nice to be able to reload a saved game directly from the Battlescape "?" screen, rather than having to go through the process of Abandoning to the Geoscape. Would you need to check it was a Battlescape save and not a Geoscape save? Maybe, maybe not. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Warm Grenades===

Currently when you set the timer on a grenade (or HE pack), the timer runs down every turn regardless of whether the grenade is worn, held, or dropped. Then, when the timer runs out, it explodes unless it is held or worn. There is no real grenade or explosive that works this way. Once the timer (fuse) starts running, they explode regardless. However for most hand grenades, the timer (fuse) doesn't start until after you throw/drop the grenade. It would be nice to have both of these real world behaviours, and lose the game's default behaviour. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

: Technically the way the game implements grenades, they don't have a timer. At least, not as such. When you set a grenade, the game just assigns it a turn to blow up on. Once the turn has passed, the game checks to see that it's on the ground and blows it up if it is, otherwise it doesn't. I believe Seb76 has already addressed this in his patches where there's an option to make grenade blow up regardless whether they are in inventory or otherwise the moment the timer is set. X-Com Apocalypse does a good job of this. The moment the grenade is so much as moved after the timer is set, it counts down. - [[User:NKF|NKF]] 23:01, 13 September 2008 (PDT)

:: To simulate an actual timer, you would need to do something like: Every turn that a primed grenade is being held by a unit during the "explode" check, increment by +1 the turn when that grenade is going to explode. [[User:Spike|Spike]] 19:10, 14 September 2008 (PDT)
:::I think I would change quantity2 ([[OBPOS.DAT]]) to a countdown instead of a turn, and use quantity3 as a flag indicating if the count has started. This flag is set any time a turn ends and the grenade has no owner. Taking it back in your hand once the timer has started won't help and the thing must be thrown... quantity2 is decreased if quantity3 is set, and the grenade blows up as usual. [[User:Seb76|Seb76]] 01:35, 15 September 2008 (PDT)

===Stun Grenades===

I want flashbangs.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)
:Instead of stunning, I'd see more effect if it would remove some TUs to units having line of sight (to be fare it should affect xcom units too). It would help against reaction fire (which is the point of flashbangs). Given that grenades detonate at the end turns, it would require a good coordination to have the grenade detonate exactly at the end of the alien turn, and just before your attack. Being able to open doors à la xcom2 would also help to throw flashbangs just before a craft assault... [[User:Seb76|Seb76]] 22:03, 12 September 2008 (PDT)
::That would be good. Hard to program, potentially extremely unbalancing, but good. I considered a "debuff" kind of ability (as you suggest) for flashbangs, vs the more obvious substitution of [[stun]] for [[HE]] damage. In the end, I picked "I want flashbangs."--[[User:Brunpal|Brunpal]] 03:32, 13 September 2008 (PDT)
: Maybe flashbangs dont' work on Aliens - otherwise, XCom would use them, right? :) But seriously, I too would like flashbangs, and stun grenades / concussion grenades. Both of these would make the game easier, though. With flashbangs, you might have to compensate by just giving the aliens more TUs. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)
::More options for the player is going to make it easier for any kind of game. Particularly of games like XCOM where the computer can't take advantage of the changes. However I don't believe a weak stun grenade (like 44 stun damage, comparable to AC-HE) would change the game much because the 80 item limit remains.--[[User:Brunpal|Brunpal]] 22:21, 13 September 2008 (PDT)

===Night Vision===

I '''don't''' want to add night vision equipment to the game. I assume that either (1) all XCom units already have night vision gear as standard, but it's not as good as alien night vision, and the visibility that XCom units have at night is based on their standard-issue night vision gear, or (2) night vision gear does not work on Aliens. Either they do not appear on night vision, or maybe worse - maybe the aliens can manipulate night vision equipment, causing worse than normal vision, or hallucinations, and even tricking XCom units into firing on each other. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)

===Throwing over stuff===

I want to throw stuff over other stuff. I don't find grenades useful. I much rather shoot a rocket launcher from outside reaction shot range because even when you miss, odds are it's close enough. The throw itself has an arc trajectory and can hit the ceiling (a feature I like) but to pick the target it has to have straight line of sight (like a bullet) which is stupid. I want to throw onto the top of buildings where I ''can't see'', or bounce a grenade off the ceiling and over the head of a squadie ''because '' I don't have line of sight with a gun. If I had line of sight, I would just shoot since that costs less TU even if I already had an armed grenade.

The easiest way to accomplish this is to keep "out of range" but remove "you can't throw there" and just let a solider throw to any square they want. A better way is to keep the warning but give the player the option to try the throw anyway. If you can't really throw there, then oops... that's your badly positioned live grenade to deal with.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)

:I did some tests disabling the "you can't throw there" check and it does not work. The grenade ends up in the vicinity of the throwing unit. Actually the line of sight is not used when throwing objects. I'm 98% sure it simulates the throwing of the object and if it intercepts anything, the throw is refused. [[User:Seb76|Seb76]] 04:47, 13 September 2008 (PDT)

:: The explicit emulation of the trajectory has been verified as part of the throwing range testing by [[User:Zombie|Zombie]] and myself. The range bands are not consistent with a continuous model; they look like a table lookup from the same source 3rd ed. GURPS (Steve Jackson Games) uses. -- [[User:Zaimoni|Zaimoni]] 8:21 13 September 2008 (CDT)

:::Units don't need LOS to an area to throw a grenade, as evidenced by my favored tactic of chucking an Alien Grenade or HE Pack into any Medium or Large Scout which has had the roof blown away in the crash from outside to 'pacify' any remaining crew. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:22, 13 September 2008 (PDT)

Really? It never seems to work for me. Always requires me to have line of sight. For example tossing in a grenade into the roof hole doesn't work for me if the solider is on level 0 and I target a square inside at level 0. The walls and door obviously block the LoS. However I can target an area on level 1 or 2 in mid air and throw to that location where it naturally drops down to level 0. However I have line of sight to those higher levels in that case.
That's an acceptable compromise in many cases but in others it fails completely. For example having an alien on the top of a 2 story building (level 2) in the middle and a solider standing next to the building and not being able to toss a grenade onto the center of the roof. I could toss a ball there in real life. I wouldn't have thought the trajectory would have been high/steep enough to hit the "sky roof".--[[User:Brunpal|Brunpal]] 22:04, 13 September 2008 (PDT)

: Just how strong are your soldiers? The stronger they are, the higher their toss. There are various occasions where you don't need to see where you're throwing to throw. For example, try tossing grenades over a tall fence or hedge. A High Explosive pack into the apple orchard that is surrounded by a hedge on farm maps is often an easy way to smoke out any hidden aliens - and the orchard. One likely cause why you can't throw inside the UFO is that there's something in the way inside that's preventing the throw, such as a wall. Try adjusting your throwing destination, or reposition your soldier for a better throwing angle.

: I've often found grenades to be much more reliable than a directional attack early in the game where firing accuracy is much lower. You ought to try playing a few of the simpler missions like supply ship or large scout assaults with an all-grenadier cast. Takes a bit of planning to not destroy much of the loot, but otherwise literally a blast. -[[User:NKF|NKF]] 22:52, 13 September 2008 (PDT)

===Enforced Variant Games===

Various people like to play various variant games, such as No Alien Technology, or No Detection, or No Lethal Weapons - see for example Scott Jones' notes to XComUtil. It would be nice to have options on the game executable to enforce these scenarios. Self restraint is hard! [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Assault Time Limit===

One of the cool things about UFO Defence is there are no time limits on the scenarios. This is great as it allows for a totally different kind of tactics and much more flexibility.
It's more of a "thinking man's game" as a result. But... arguably this is not very realistic for UFO Assault missions. If the Aliens are getting creamed, they should try to make a getaway if they can (just like XCom would). A simple way to implement this would be a hard time limit (say 20 turns?) on a UFO Assault. Another way would be to base it on Alien Morale. At a certain Morale level the aliens decide to dust off. Give the player say 3 turns warning while they rev up the engines. Then if there is still a Navigator or Engineer in the Control Room alive, the ship takes off. Any XCom troops still aboard are MIA.

You might run into problems if the UFO took off but then landed again or was shot down, generating another ground mission with potentially '''more''' Aliens than were still alive at the end of the Assault. (Still, maybe they hatch some more clones if they get time to....) [[User:Spike|Spike]] 09:51, 4 September 2008 (PDT)

: It strikes me as justified they don't do that. Troops loose in the vessel could be seriously bad. It would be nice if they dusted off on the condition that their morale was low enough or 3 X-com soldiers had the door in their sights without aliens alive outside in the latter case and no X-com soldiers on board in either case. also, if the UFO has a hole in either the command or engine room, it would have to set down before leaving the atmosphere. [[User:(name here)|(name here)]]

===Base Build Stacking===

At the moment you are only allowed to build next to a finished module, and you aren't allowed to plan ahead in your base construction. It would be nice to at least be able to plan more than one phase of construction in advance. This would be pretty easy to implement. There is no need to code any new "queuing system". Just place the new module next to an existing under-construction module, but increment the build time to the normal build time + the time remaining on the under-construction module (the lowest time remaining that would make the square you are building in, a legal square to build in). As a premium for build stacking, you have to pay the costs up-front. As with normal construction, all costs are non-refundable if you change your mind. (There would probably need to be some on-screen feedback for how long the module would take to build, before you were committed to building it.) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Recuit Certain Enemy===

Consider that not all alien loyal to its master (most TFTD alien has a device lodged to its brain), it should be interesting (or at least cool) if we can recuit such alien. Maybe we can replace those controling device from captive alien after research that specie. Or convince head of the Snakemen that it would be far more benefit to help us instead of the Ethereal [[User:L-Zwei|L-Zwei]] 23:25, 12 September 2008 (PDT).

Only certain alien types should be recruitable. Ones that should NOT be include Mutons (as they are directly controlled by Ethereals), Chrysallids (unbalancing), etc. It would be nice to be able to reverse-engineer Cyberdiscs or Sectopods, or make it that a Cyberdisc must be researched to build hovertanks/etc.
[[User:MagicJuggler|MagicJuggler]] 13:32, 18 September 2008 (PDT)

===Alien AI===
====Attempts to rearm====
Aliens cannot pick up items, but I wish they would. If an alien has no useful weapons in inventory they should either head for cover or head for a plasma weapon. Panicked aliens drop their weapons but never seem to pick them up when they managed to pull themselves together. It would be nice if they tried to arm themselves again. --[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)

====Aliens better with explosions====
I wish that aliens using grenades or blaster bombs or stun bombs (anything that goes boom) would use more sense. They should not want to use items that go boom when they are guaranteed to be caught in the blast radius. The alien can use grenades and blaster bombs by going out of line of sight before the explosion goes off. That may not save them if the explosion blows out the walls. At least it would be less stupid then firing a point blank blaster bomb vs taking 5 steps and setting up another waypoint. Units with morale above 100 or mind controlled should still be suicidal as normal.--[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)

: Actually, the aliens are quite careful with their explosives, they just seem to be prone to the occasional accident. They're not likely to fire off a blaster or grenade too close to them - as evident by the strategy where if you see an alien with a BB but can't shoot back, the safest place is to stand next to it. The blaster bomb vertical waypoint fix in the loader also eliminates the 'oops' moments where they plot a vertical right angle too close to themselves and there just happens to be a wall to the south. However, they do need more care with stun bombs as you often get to see an alien fire a stun bomb point blank into a HWP parked next to it. But I guess we are talking about three different weapon types here, so they may not be as careful with a standard firearm as they are with grenades and the BB. Wish the Apocalypse aliens at least had as much sense as the UFO/TFTD aliens. In that game, they're utterly psychotic with explosives and ignore nearby allies. -[[User:NKF|NKF]] 14:34, 19 September 2008 (PDT)

==Fix All Bugs==

Oh no [[User:Seb76|Seb76]] already did this! :) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

== Category ==
The page needs to be listed in various categories, which ones I don't know. Also links on other pages to this one would aid people finding it.

: OK how about this one: [[User:Spike|Spike]] 12:21, 3 September 2008 (PDT)

[[Category:Oddities and bugs]]

SOME MORE WISH LIST STUFF

I have already listed most of this wish list on Sep’s excellent loader page. Didn’t know this page existed till now.

1. When the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?

2. If you psi control a human (civilians) in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control.

3. Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).

4. 80 item bug on base defense mission

5. I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!

6. I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).

7. This one is way out there. Alien v Alien battles out with main game, just random battlescape maps. Sectoid and their terrorists against Floaters and theirs etc. One side human controlled the other computer. Choice of ships involved etc.

These are a couple of new ones, just thought of them

8. moved

9. Open doors like they do in TFTD (I know this is mentioned above with the good stun grenades idea).

10. New graphics for the Interceptor and Firestorm on the battlescape. All your ships could remain in their hangers when the aliens attack your base. Don’t understand why Mythos did not do this originally.

Wish List (EU)

2008-09-23T19:59:29Z

Kyrub: /* Decrease Accuracy for targets out of sight */

X-Com is a great game and as evidence just look to the fact this wiki exists even though the game pre-dates the internet. In all it's greatness X-Com has some elements and behaviors players wish they could change. This is a repository of those desires. Some day a fan mod may make your wish come true...

== I Wish... ==
State what you want AND what X-com does normally. Sign your name if you think "Oh man! That would be great!"
=== Fuel Ready always ===
I wish that I could send out craft at any fuel or ammo level. Normally craft can only leave a base if fully "ready". Craft is only "ready" at 100% fuel (or 0% fuel using an exploit) but there's no logical reason why a full tank and full ammo is required. Fully repaired... that's fine. I can live with pilots refusing to fly a plane missing a wing even if it means England is lost to aliens. 15 hours to fill a tank? Retarded but I can live with that too if I can send out a craft at 20% fuel.
--[[User:Brunpal|Brunpal]]

:Actually, many modern aircraft '''do''' require the fuel tanks to be full on takeoff, and fairly empty on landing. The weight of the fuel is figured into the takeoff aerodynamics, and the tank being full prevents fuel 'sloshing' in the tanks and not actually making it to the engine. (Conversely, many aircraft need to have dispensed of much of that fuel weight before landing.) This holds for most runway-takeoff craft, but may not apply to anything with VTOL capacity; I'm unsure there.

:I do agree that non-full weapons aren't as critical, though. But from a logical standpoint, most modern aircraft should not be launched on an empty fuel tank. I also should noted that an Elerium-fueled craft with [[Known_Bugs#Elerium-fueled_Craft_Bug|50% fuel or less remaining]] will automatically return to base, regardless of distance from base. Of course, given that such craft fuel up quickly, its less of an issue there. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:05, 7 August 2008 (PDT)

:Hum, maybe you can try [[User:Seb76#Mods|this]]? [[User:Seb76|Seb76]] 13:01, 8 August 2008 (PDT)
::Thanks! But I can't try it. I've not been able to get my copy of Xcom to run properly except on a Win98 install. VC2008 requires a more modern OS. I'm sure I could ''eventually'' figure out a way to get it running, but I tried once and wasted too much time before giving up.--[[User:Brunpal|Brunpal]] 14:45, 8 August 2008 (PDT)
:AFAIK VC2008 binaries should run OK on Win98 as long as the runtime is deployed. Anyway, the loader uses CreateRemoteThread API which is not available in Win98 so don't even bother. '''However''', you can manually patch the binary if you want ;-) Data to patch (all in hexadecimal):
offset 0x41752: 2A0075 -> 18207C
:HTH. [[User:Seb76|Seb76]] 14:56, 8 August 2008 (PDT)

=== Smarter on Globe ===
I wish all craft understood the shortest distance between two points on a globe is a curved path towards the poles. Normally a craft goes in the opposite direction than it should (towards the equator). Pain in the ass when the base in the UK sends a craft to Siberia.
--[[User:Brunpal|Brunpal]]

===Equipment Management===

==== Soldiers remembers THEIR equipment ====
I wish soldiers remembered what equipment they LAST used and start with that gear when they land. Normally soldiers grab various gear and put lots of crap on their belt. I put most things on the shoulder slots, and keep many things spare things on the ship just in case I need them. (I only want IN rounds if it's night. Stop picking them up before I shoot you in the back!) Takes forever to sort out the gear so the weakling isn't carrying all the rockets etc.
--[[User:Brunpal|Brunpal]]

:This is already available in [[XcomUtil]]. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:07, 7 August 2008 (PDT)

====Access to Stats screens during equipment allocation====

In Battlescape you can get to Stats screens by right clicking on one of the unit's status bars. However you can't do this in the Equipment screen. Things like Statstrings and (even more so) [[User:Seb76|Seb76]]'s modified Equipment screen with actual/max weight help. But it would be nice to be able to see exact stats. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Fog of War Mk. 2===

I'm sure most of these would be an absolute PAIN to implement, but I figured I'd toss the ideas out here.

====Blind Dropship Pilots====
One thing that has always irked me is X-COM has no terrain knowledge when it lands, despite having probably circled the place two or three times before landing and thus they should know at least some of the area. This would be nice, but isn't too important. Probably would be a pain to implement so X-COM would have all knowledge of external features but no knowledge of building interiors, anyways. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

:Yes at the very least, when you splash the UFO, it could tell you (via some miracle technology such as "satellite reconnaisance") what the terrain type is of the landing zone area. Then you could adjust equipment accordingly. And adjust your uniform camouflage (if using one of the uniform mods). [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: Geoscape: center on the site, then maximum zoom. Aside from having to disambiguate forest from jungle, this works fine for knowing the exact terrain you're getting into. -- [[User:Zaimoni|Zaimoni]] 10:17, 4 Sept 2008 (CDT)

:::This is already present in the game. To center the Geoscape on a specific location, right-click on the target spot. To do maximum zoom in, right click on the Zoom-In button(and the same works for Zoom-Out). Also, Jungle and Forest use the same display algorithm, but are easy to differentiate; Forest occurs NORTH of the equator, and Jungle occurs SOUTH. [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:23, 4 September 2008 (PDT)

====Moving Fog====

The Fog of War in X-COM is clumsily implemented, compared to modern expectations. Everything starts out black, but after exploring, is shown...and it's kept in the same showing, regardless of whether you actually have LoS to that area anymore. It would be nice if when you no longer had Line of Sight to a particular map area, it would be cloaked in a way so that you knew the terrain, but not the units there. Since I've sometimes spent over half an hour trying to hunt down that last alien hiding in area I'd already explored. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

====Deactivate Object Radar====

Currently, in X-COM, any objects dropped in a given square show on your Battlescape, regardless of whether you have Line of Sight to the square or not. In regards to dropped weapons/grenades/equipment/dead soldiers/dead aliens, this doesn't make a large difference. But in the case of STUNNED aliens, a quick scan across the Battlescape can tell you whether the alien you stunned 10 turns ago is still down, or stood back up(the stunned alien object will disappear from the stack). Of course, since aliens which have revived from stun are almost always disarmed(and the ones that aren't probably should've been killed instead), the usefulness of this 'exploit' is reduced mainly to finding out that the last alien you're looking for is just wandering aimlessly and unarmed. Perhaps leave stacks showing the same until you regain LoS to that area? [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

===Score for retaliation Battleships===

When a Battleship on retaliation attacks your base and is shot down, you get no score for it. This is completely illogical and it discourages any use of base defences. You should get normal 700 (or even 1400) points for it.
--[[User:Kyrub|Kyrub]] 14:05, 30 August 2008 (PDT)

: I'm not sure about this. Yes it's illogical, but it could also be a licence to get a huge score if you have a strong enough base. [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: The impenetrable base setup would turn into a cheat. As the aliens will keep hammering the base with a battleship until one breaks through, you'll have a steady supply of points without having to really do anything. Some balancing, such as paying to rearm your defence modules, ought to be thrown in to balance things out. -[[User:NKF|NKF]] 23:13, 13 September 2008 (PDT)
:::A better fix would be to remove the retaliation flag when a battleship is destroyed. If someone can post a savegame with a never-ending flow of base attacks, I may have a look at the fix. [[User:Seb76|Seb76]] 01:05, 15 September 2008 (PDT)

===Decrease Accuracy for targets out of sight===

How come you can easily shoot on something you do not see?
I find the over-used scout-sniper tactic is a cheap exploit of the X-COM. The tactical game should describe a combat, not a cowardly shooting practice. It would turn into a nice feature, if there would be a penalty of (let us say) -20% to the accuracy of anybody who is firing on a target out of his current sight. This can greatly enhance the tactical depth of the game. (Seb around? ;-) --[[User:Kyrub|Kyrub]] 14:20, 30 August 2008 (PDT)

: There is a penalty. Bullet drift. The further away you are, the more this will impact the bullet, potentially making even a 100% accurate shot miss. Also X-Com maps are pretty small, and the aliens already cheat enough as it is to make things difficult even with the sniper/scout strategy. In Apocalypse they addressed this with adding weapon ranges. But then, even some weapons were capable of shooting beyond the unit's ability to see an enemy target. - [[User:NKF|NKF]] 23:07, 13 September 2008 (PDT)

::That's not really a good reason for me. 1) Bullet drift has a very small effect in the game, because the actual percents are set quite high. Example: if you spray an unseen alien from the other corner of the map with autofire of 35%, you'll get a 73,6% chance to hit with at least one bullet. Physics and game balance, adieu. 2) Moreover, bullet drift has nothing to do with not seeing the target. It should be the contrary, you ACCIDENTALLY hit something you don't see, no? 3) You get a penalty for handling two weapons in the same time. Why couldn't we take the same penalty (80%*Acc) for the hit-out-of-sight? (Well, I can't do this actually, maybe others can)--[[User:Kyrub|Kyrub]] 18:25, 14 September 2008 (PDT)

: I don't agree that bullet drift is already there as a penalty, since this doesn't distinguish between seen and unseen targets at all (ok it does indirectly, only in so far as unseen targets tend to be further away). I think we should look at 3 cases: 1. person firing did not happen to be the one who '''spotted''' the target. 2. person firing '''could not''' see/spot the target under any circumstances. In the first case, we can assume the firer has visual contact with the target, after someone else pointed it out. No accuracy penalty should be applied (maybe a TU penalty?). In the second case, there should be an accuracy penalty. 80% would be generous, I would go for 50%. Or maybe something non-linear, so that autofire percentages would not fall by as much as aimed fire and snap fire percentages. One problem you have is how to present these two different cases to the player before they take the shot. It's a bit obscure if you just show them a lower hit probability without explaining why. [[User:Spike|Spike]] 19:02, 14 September 2008 (PDT)

:: Bullet drift is an effect on range (actually it has quite a major effect on the blaster bomb), but yes it's not because of whether or not the unit can see the alien. But then again, the maps are small. If you ever took lots of screen shots of the map and made a large composite from them, you'd find that the area of operations is very tiny and that the 20 tile visual range means that our avatars are quite short sighted. That's not realistic either, but imposed for game balance. Other tactical games appear to handle the accuracy vs. range dropoff issue by combining the shooter's skill and the weapon's maximum range. Basically you can operate the weapon to the best of the shooter's ability within the maximum range, but the further away you try to aim, accuracy is decreased. In some games, you even get to see the effect on the accuracy before you pull the trigger as the accuracy is attached to the cursor. - [[User:NKF|NKF]] 22:46, 14 September 2008 (PDT)

:::Actually the blaster bomb "drift" issue is not mainly caused by drift, but by accuracy adjustment between each waypoint (60% for xcom players, 55% for aliens). Maybe we can cook a kind of "max effective range" for a weapon base on firing mode (auto<snap<aimed) and gun type (pistol/rifle). Firing above this range would decrease the accuracy. [[User:Seb76|Seb76]] 01:03, 15 September 2008 (PDT)

:::: (to NKF) The main flaw of the whole "shoot the unseen" thing is the aliens cannot shoot back at somebody shooting at them (no reaction fire). If they could (or if they'd shoot at least the soldier they see), I wouldn't complain. This destroys the battle tactics side of the game, you just sent a man to "spot them". Nota bene, they cannot use the same scout-sniper tactic, the way we do, either. (This would be most annoying, by the way).
::::(to Seb76) Effective range would restore some balance and add some use to the aimed shots. I thought about a simpler solution with ''substracting'' some accuracy (which would make auto useless, snap into a poor and aimed into a solid chance-to-hit). Your suggestion is much more elegant, Seb, if you can cook it ;-) --[[User:Kyrub|Kyrub]] 08:00, 18 September 2008 (PDT)

::: Fair enough, but do note that even your units cannot react against an alien that they cannot see within their visual range. Attacks of opportunity and actively taking your turn are two different tasks after all. I'm not sure the aliens would be such sportsmen though. It might be worth looking into whether there is cooperation amongst the aliens while they are taking their turn - and I think I just have the scenario savegame to test this. If I could find it. BBs probably break the rules of basic firearms and range, and mind control has its own set of rules, so probably wouldn't count. -[[User:NKF|NKF]] 00:37, 19 September 2008 (PDT)
::::Hmm, maybe we could have accuracy impacted like this:
::::*aimed shot: no range penalty
::::*snap shot: penalty if shooting beyond visual range (reaction fire is not impacted since it uses snap shots)
::::*auto shot: no penalty if shooting under night visual range, small penalty if between day and night range, big penalty if above visual range.
::::Maybe we can use a function of the distance for the penalty instead of hard values. What do you think? [[User:Seb76|Seb76]] 16:53, 19 September 2008 (PDT)

How about you reduce accuracy by (Effective Range / Actual Range), whenever Actual Range > Effective Range. This could be applied for all attacks, and applied again (or another factor applied) for out-of-sight targets. I would suggest that the effective ranges, in relative terms, are something like this order (highest to lowest):

*HWP / Terrorist weapons
*Heavy Laser
*Rocket Launcher
*Heavy Cannon
*Laser Rifle (or higher up for this one?)
*Rifle
*Plasma Rifle
*Auto Cannon
*Heavy Plasma
*Pistols (Laser Pistol, Pistol, Plasma Pistol)

(Yes I'm prejudiced against plasma weapons but I'd like to rebalance the game a bit. All that plasma just expands too quickly and interacts with our atmosphere too much for the bolt to stay coherent over longer ranges.)

Now, apart from the problem of coming up with the values for Effective Range for each weapon - where would they be stored? [[User:Spike|Spike]] 10:45, 20 September 2008 (PDT)
:The point of using visibility range only is not to have to specify effective range per weapon; tuning good balanced values can be quite difficult. As for their storage, they can be hard-coded in the loader, or defined in the ini file. [[User:Seb76|Seb76]] 05:23, 21 September 2008 (PDT)
:: Good point, tuning it correctly is very tricky, it would be easier just to use visibility range rather than creating new "max effective range" for various weapons and making sure it's balanced. A couple of other options when the sniper is outside visual range: 1. disallow the attack with an "Out of Range" message. 2. allow the attack but only for Aimed Fire, otherwise give an "Out of Range for [Snap Fire|Auto Fire]" message. As was mentioned, this restores some use to Aimed Fire which otherwise is under-used. For this to make sense, we would have to take the interpretation that "visibility range" means "spotting range". Clearly it does not make sense to be able to do Aimed fire at something you cannot possibly see at all, even if you know where to look for it. So if, on the other hand, we assume that an out-of-range sniper can't see his target at all, the accuracy should be reduced to something lower than the lowest accuracy of the weapon - say half of auto or snap accuracy. [[User:Spike|Spike]] 05:49, 21 September 2008 (PDT)
(Off Topic: this all should be now moved to the 'talk' page, no? Can anybody do it?)
:Let us keep the change simple! When the game mechanics are too complicated (for the realism purpose or other), you lose control over the way the game is played. While I understand your points, Spike, I'd personnally go with what Seb76 has suggested: Aimed - no penalty, Snap - penalty at vision range (20), Auto, Full auto - penalty on night (9) range. Plus the customization in the ini file. We need to rethink all the launchers, I could let them with no penalty (they seem to be guided).

===Enough Smoke===

It would be nice to increase the current limit on smoke/fire hexes. This is due to their locations being stored in a small, fixed length array. In effect you can only get about 3-4 smoke grenades worth of smoke or fire on the map at the same time. Being able to use smoke liberally would really open up new tactics. At the moment all you can really do is cover the LZ in smoke when you exit the transport, and maybe cover one advance over open ground. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)
:I did something for that on my loader. Heavy testing is required because it is hard to be make sure smoke still works as before (testing is the hardest part actually). [[User:Seb76|Seb76]] 14:09, 18 September 2008 (PDT)

===Restore Game from Battlescape===

It would be nice to be able to reload a saved game directly from the Battlescape "?" screen, rather than having to go through the process of Abandoning to the Geoscape. Would you need to check it was a Battlescape save and not a Geoscape save? Maybe, maybe not. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Warm Grenades===

Currently when you set the timer on a grenade (or HE pack), the timer runs down every turn regardless of whether the grenade is worn, held, or dropped. Then, when the timer runs out, it explodes unless it is held or worn. There is no real grenade or explosive that works this way. Once the timer (fuse) starts running, they explode regardless. However for most hand grenades, the timer (fuse) doesn't start until after you throw/drop the grenade. It would be nice to have both of these real world behaviours, and lose the game's default behaviour. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

: Technically the way the game implements grenades, they don't have a timer. At least, not as such. When you set a grenade, the game just assigns it a turn to blow up on. Once the turn has passed, the game checks to see that it's on the ground and blows it up if it is, otherwise it doesn't. I believe Seb76 has already addressed this in his patches where there's an option to make grenade blow up regardless whether they are in inventory or otherwise the moment the timer is set. X-Com Apocalypse does a good job of this. The moment the grenade is so much as moved after the timer is set, it counts down. - [[User:NKF|NKF]] 23:01, 13 September 2008 (PDT)

:: To simulate an actual timer, you would need to do something like: Every turn that a primed grenade is being held by a unit during the "explode" check, increment by +1 the turn when that grenade is going to explode. [[User:Spike|Spike]] 19:10, 14 September 2008 (PDT)
:::I think I would change quantity2 ([[OBPOS.DAT]]) to a countdown instead of a turn, and use quantity3 as a flag indicating if the count has started. This flag is set any time a turn ends and the grenade has no owner. Taking it back in your hand once the timer has started won't help and the thing must be thrown... quantity2 is decreased if quantity3 is set, and the grenade blows up as usual. [[User:Seb76|Seb76]] 01:35, 15 September 2008 (PDT)

===Stun Grenades===

I want flashbangs.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)
:Instead of stunning, I'd see more effect if it would remove some TUs to units having line of sight (to be fare it should affect xcom units too). It would help against reaction fire (which is the point of flashbangs). Given that grenades detonate at the end turns, it would require a good coordination to have the grenade detonate exactly at the end of the alien turn, and just before your attack. Being able to open doors à la xcom2 would also help to throw flashbangs just before a craft assault... [[User:Seb76|Seb76]] 22:03, 12 September 2008 (PDT)
::That would be good. Hard to program, potentially extremely unbalancing, but good. I considered a "debuff" kind of ability (as you suggest) for flashbangs, vs the more obvious substitution of [[stun]] for [[HE]] damage. In the end, I picked "I want flashbangs."--[[User:Brunpal|Brunpal]] 03:32, 13 September 2008 (PDT)
: Maybe flashbangs dont' work on Aliens - otherwise, XCom would use them, right? :) But seriously, I too would like flashbangs, and stun grenades / concussion grenades. Both of these would make the game easier, though. With flashbangs, you might have to compensate by just giving the aliens more TUs. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)
::More options for the player is going to make it easier for any kind of game. Particularly of games like XCOM where the computer can't take advantage of the changes. However I don't believe a weak stun grenade (like 44 stun damage, comparable to AC-HE) would change the game much because the 80 item limit remains.--[[User:Brunpal|Brunpal]] 22:21, 13 September 2008 (PDT)

===Night Vision===

I '''don't''' want to add night vision equipment to the game. I assume that either (1) all XCom units already have night vision gear as standard, but it's not as good as alien night vision, and the visibility that XCom units have at night is based on their standard-issue night vision gear, or (2) night vision gear does not work on Aliens. Either they do not appear on night vision, or maybe worse - maybe the aliens can manipulate night vision equipment, causing worse than normal vision, or hallucinations, and even tricking XCom units into firing on each other. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)

===Throwing over stuff===

I want to throw stuff over other stuff. I don't find grenades useful. I much rather shoot a rocket launcher from outside reaction shot range because even when you miss, odds are it's close enough. The throw itself has an arc trajectory and can hit the ceiling (a feature I like) but to pick the target it has to have straight line of sight (like a bullet) which is stupid. I want to throw onto the top of buildings where I ''can't see'', or bounce a grenade off the ceiling and over the head of a squadie ''because '' I don't have line of sight with a gun. If I had line of sight, I would just shoot since that costs less TU even if I already had an armed grenade.

The easiest way to accomplish this is to keep "out of range" but remove "you can't throw there" and just let a solider throw to any square they want. A better way is to keep the warning but give the player the option to try the throw anyway. If you can't really throw there, then oops... that's your badly positioned live grenade to deal with.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)

:I did some tests disabling the "you can't throw there" check and it does not work. The grenade ends up in the vicinity of the throwing unit. Actually the line of sight is not used when throwing objects. I'm 98% sure it simulates the throwing of the object and if it intercepts anything, the throw is refused. [[User:Seb76|Seb76]] 04:47, 13 September 2008 (PDT)

:: The explicit emulation of the trajectory has been verified as part of the throwing range testing by [[User:Zombie|Zombie]] and myself. The range bands are not consistent with a continuous model; they look like a table lookup from the same source 3rd ed. GURPS (Steve Jackson Games) uses. -- [[User:Zaimoni|Zaimoni]] 8:21 13 September 2008 (CDT)

:::Units don't need LOS to an area to throw a grenade, as evidenced by my favored tactic of chucking an Alien Grenade or HE Pack into any Medium or Large Scout which has had the roof blown away in the crash from outside to 'pacify' any remaining crew. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:22, 13 September 2008 (PDT)

Really? It never seems to work for me. Always requires me to have line of sight. For example tossing in a grenade into the roof hole doesn't work for me if the solider is on level 0 and I target a square inside at level 0. The walls and door obviously block the LoS. However I can target an area on level 1 or 2 in mid air and throw to that location where it naturally drops down to level 0. However I have line of sight to those higher levels in that case.
That's an acceptable compromise in many cases but in others it fails completely. For example having an alien on the top of a 2 story building (level 2) in the middle and a solider standing next to the building and not being able to toss a grenade onto the center of the roof. I could toss a ball there in real life. I wouldn't have thought the trajectory would have been high/steep enough to hit the "sky roof".--[[User:Brunpal|Brunpal]] 22:04, 13 September 2008 (PDT)

: Just how strong are your soldiers? The stronger they are, the higher their toss. There are various occasions where you don't need to see where you're throwing to throw. For example, try tossing grenades over a tall fence or hedge. A High Explosive pack into the apple orchard that is surrounded by a hedge on farm maps is often an easy way to smoke out any hidden aliens - and the orchard. One likely cause why you can't throw inside the UFO is that there's something in the way inside that's preventing the throw, such as a wall. Try adjusting your throwing destination, or reposition your soldier for a better throwing angle.

: I've often found grenades to be much more reliable than a directional attack early in the game where firing accuracy is much lower. You ought to try playing a few of the simpler missions like supply ship or large scout assaults with an all-grenadier cast. Takes a bit of planning to not destroy much of the loot, but otherwise literally a blast. -[[User:NKF|NKF]] 22:52, 13 September 2008 (PDT)

===Enforced Variant Games===

Various people like to play various variant games, such as No Alien Technology, or No Detection, or No Lethal Weapons - see for example Scott Jones' notes to XComUtil. It would be nice to have options on the game executable to enforce these scenarios. Self restraint is hard! [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Assault Time Limit===

One of the cool things about UFO Defence is there are no time limits on the scenarios. This is great as it allows for a totally different kind of tactics and much more flexibility.
It's more of a "thinking man's game" as a result. But... arguably this is not very realistic for UFO Assault missions. If the Aliens are getting creamed, they should try to make a getaway if they can (just like XCom would). A simple way to implement this would be a hard time limit (say 20 turns?) on a UFO Assault. Another way would be to base it on Alien Morale. At a certain Morale level the aliens decide to dust off. Give the player say 3 turns warning while they rev up the engines. Then if there is still a Navigator or Engineer in the Control Room alive, the ship takes off. Any XCom troops still aboard are MIA.

You might run into problems if the UFO took off but then landed again or was shot down, generating another ground mission with potentially '''more''' Aliens than were still alive at the end of the Assault. (Still, maybe they hatch some more clones if they get time to....) [[User:Spike|Spike]] 09:51, 4 September 2008 (PDT)

: It strikes me as justified they don't do that. Troops loose in the vessel could be seriously bad. It would be nice if they dusted off on the condition that their morale was low enough or 3 X-com soldiers had the door in their sights without aliens alive outside in the latter case and no X-com soldiers on board in either case. also, if the UFO has a hole in either the command or engine room, it would have to set down before leaving the atmosphere. [[User:(name here)|(name here)]]

===Base Build Stacking===

At the moment you are only allowed to build next to a finished module, and you aren't allowed to plan ahead in your base construction. It would be nice to at least be able to plan more than one phase of construction in advance. This would be pretty easy to implement. There is no need to code any new "queuing system". Just place the new module next to an existing under-construction module, but increment the build time to the normal build time + the time remaining on the under-construction module (the lowest time remaining that would make the square you are building in, a legal square to build in). As a premium for build stacking, you have to pay the costs up-front. As with normal construction, all costs are non-refundable if you change your mind. (There would probably need to be some on-screen feedback for how long the module would take to build, before you were committed to building it.) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Recuit Certain Enemy===

Consider that not all alien loyal to its master (most TFTD alien has a device lodged to its brain), it should be interesting (or at least cool) if we can recuit such alien. Maybe we can replace those controling device from captive alien after research that specie. Or convince head of the Snakemen that it would be far more benefit to help us instead of the Ethereal [[User:L-Zwei|L-Zwei]] 23:25, 12 September 2008 (PDT).

Only certain alien types should be recruitable. Ones that should NOT be include Mutons (as they are directly controlled by Ethereals), Chrysallids (unbalancing), etc. It would be nice to be able to reverse-engineer Cyberdiscs or Sectopods, or make it that a Cyberdisc must be researched to build hovertanks/etc.
[[User:MagicJuggler|MagicJuggler]] 13:32, 18 September 2008 (PDT)

===Alien AI===
====Attempts to rearm====
Aliens cannot pick up items, but I wish they would. If an alien has no useful weapons in inventory they should either head for cover or head for a plasma weapon. Panicked aliens drop their weapons but never seem to pick them up when they managed to pull themselves together. It would be nice if they tried to arm themselves again. --[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)

====Aliens better with explosions====
I wish that aliens using grenades or blaster bombs or stun bombs (anything that goes boom) would use more sense. They should not want to use items that go boom when they are guaranteed to be caught in the blast radius. The alien can use grenades and blaster bombs by going out of line of sight before the explosion goes off. That may not save them if the explosion blows out the walls. At least it would be less stupid then firing a point blank blaster bomb vs taking 5 steps and setting up another waypoint. Units with morale above 100 or mind controlled should still be suicidal as normal.--[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)

: Actually, the aliens are quite careful with their explosives, they just seem to be prone to the occasional accident. They're not likely to fire off a blaster or grenade too close to them - as evident by the strategy where if you see an alien with a BB but can't shoot back, the safest place is to stand next to it. The blaster bomb vertical waypoint fix in the loader also eliminates the 'oops' moments where they plot a vertical right angle too close to themselves and there just happens to be a wall to the south. However, they do need more care with stun bombs as you often get to see an alien fire a stun bomb point blank into a HWP parked next to it. But I guess we are talking about three different weapon types here, so they may not be as careful with a standard firearm as they are with grenades and the BB. Wish the Apocalypse aliens at least had as much sense as the UFO/TFTD aliens. In that game, they're utterly psychotic with explosives and ignore nearby allies. -[[User:NKF|NKF]] 14:34, 19 September 2008 (PDT)

==Fix All Bugs==

Oh no [[User:Seb76|Seb76]] already did this! :) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

== Category ==
The page needs to be listed in various categories, which ones I don't know. Also links on other pages to this one would aid people finding it.

: OK how about this one: [[User:Spike|Spike]] 12:21, 3 September 2008 (PDT)

[[Category:Oddities and bugs]]

SOME MORE WISH LIST STUFF

I have already listed most of this wish list on Sep’s excellent loader page. Didn’t know this page existed till now.

1. When the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?

2. If you psi control a human (civilians) in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control.

3. Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).

4. 80 item bug on base defense mission

5. I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!

6. I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).

7. This one is way out there. Alien v Alien battles out with main game, just random battlescape maps. Sectoid and their terrorists against Floaters and theirs etc. One side human controlled the other computer. Choice of ships involved etc.

These are a couple of new ones, just thought of them

8. moved

9. Open doors like they do in TFTD (I know this is mentioned above with the good stun grenades idea).

10. New graphics for the Interceptor and Firestorm on the battlescape. All your ships could remain in their hangers when the aliens attack your base. Don’t understand why Mythos did not do this originally.

Wish List (EU)

2008-09-18T15:26:21Z

Kyrub: /* Decrease Accuracy for targets out of sight */

X-Com is a great game and as evidence just look to the fact this wiki exists even though the game pre-dates the internet. In all it's greatness X-Com has some elements and behaviors players wish they could change. This is a repository of those desires. Some day a fan mod may make your wish come true...

== I Wish... ==
State what you want AND what X-com does normally. Sign your name if you think "Oh man! That would be great!"
=== Fuel Ready always ===
I wish that I could send out craft at any fuel or ammo level. Normally craft can only leave a base if fully "ready". Craft is only "ready" at 100% fuel (or 0% fuel using an exploit) but there's no logical reason why a full tank and full ammo is required. Fully repaired... that's fine. I can live with pilots refusing to fly a plane missing a wing even if it means England is lost to aliens. 15 hours to fill a tank? Retarded but I can live with that too if I can send out a craft at 20% fuel.
--[[User:Brunpal|Brunpal]]

:Actually, many modern aircraft '''do''' require the fuel tanks to be full on takeoff, and fairly empty on landing. The weight of the fuel is figured into the takeoff aerodynamics, and the tank being full prevents fuel 'sloshing' in the tanks and not actually making it to the engine. (Conversely, many aircraft need to have dispensed of much of that fuel weight before landing.) This holds for most runway-takeoff craft, but may not apply to anything with VTOL capacity; I'm unsure there.

:I do agree that non-full weapons aren't as critical, though. But from a logical standpoint, most modern aircraft should not be launched on an empty fuel tank. I also should noted that an Elerium-fueled craft with [[Known_Bugs#Elerium-fueled_Craft_Bug|50% fuel or less remaining]] will automatically return to base, regardless of distance from base. Of course, given that such craft fuel up quickly, its less of an issue there. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:05, 7 August 2008 (PDT)

:Hum, maybe you can try [[User:Seb76#Mods|this]]? [[User:Seb76|Seb76]] 13:01, 8 August 2008 (PDT)
::Thanks! But I can't try it. I've not been able to get my copy of Xcom to run properly except on a Win98 install. VC2008 requires a more modern OS. I'm sure I could ''eventually'' figure out a way to get it running, but I tried once and wasted too much time before giving up.--[[User:Brunpal|Brunpal]] 14:45, 8 August 2008 (PDT)
:AFAIK VC2008 binaries should run OK on Win98 as long as the runtime is deployed. Anyway, the loader uses CreateRemoteThread API which is not available in Win98 so don't even bother. '''However''', you can manually patch the binary if you want ;-) Data to patch (all in hexadecimal):
offset 0x41752: 2A0075 -> 18207C
:HTH. [[User:Seb76|Seb76]] 14:56, 8 August 2008 (PDT)

=== Smarter on Globe ===
I wish all craft understood the shortest distance between two points on a globe is a curved path towards the poles. Normally a craft goes in the opposite direction than it should (towards the equator). Pain in the ass when the base in the UK sends a craft to Siberia.
--[[User:Brunpal|Brunpal]]

===Equipment Management===

==== Soldiers remembers THEIR equipment ====
I wish soldiers remembered what equipment they LAST used and start with that gear when they land. Normally soldiers grab various gear and put lots of crap on their belt. I put most things on the shoulder slots, and keep many things spare things on the ship just in case I need them. (I only want IN rounds if it's night. Stop picking them up before I shoot you in the back!) Takes forever to sort out the gear so the weakling isn't carrying all the rockets etc.
--[[User:Brunpal|Brunpal]]

:This is already available in [[XcomUtil]]. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:07, 7 August 2008 (PDT)

====Access to Stats screens during equipment allocation====

In Battlescape you can get to Stats screens by right clicking on one of the unit's status bars. However you can't do this in the Equipment screen. Things like Statstrings and (even more so) [[User:Seb76|Seb76]]'s modified Equipment screen with actual/max weight help. But it would be nice to be able to see exact stats. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Fog of War Mk. 2===

I'm sure most of these would be an absolute PAIN to implement, but I figured I'd toss the ideas out here.

====Blind Dropship Pilots====
One thing that has always irked me is X-COM has no terrain knowledge when it lands, despite having probably circled the place two or three times before landing and thus they should know at least some of the area. This would be nice, but isn't too important. Probably would be a pain to implement so X-COM would have all knowledge of external features but no knowledge of building interiors, anyways. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

:Yes at the very least, when you splash the UFO, it could tell you (via some miracle technology such as "satellite reconnaisance") what the terrain type is of the landing zone area. Then you could adjust equipment accordingly. And adjust your uniform camouflage (if using one of the uniform mods). [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: Geoscape: center on the site, then maximum zoom. Aside from having to disambiguate forest from jungle, this works fine for knowing the exact terrain you're getting into. -- [[User:Zaimoni|Zaimoni]] 10:17, 4 Sept 2008 (CDT)

:::This is already present in the game. To center the Geoscape on a specific location, right-click on the target spot. To do maximum zoom in, right click on the Zoom-In button(and the same works for Zoom-Out). Also, Jungle and Forest use the same display algorithm, but are easy to differentiate; Forest occurs NORTH of the equator, and Jungle occurs SOUTH. [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:23, 4 September 2008 (PDT)

====Moving Fog====

The Fog of War in X-COM is clumsily implemented, compared to modern expectations. Everything starts out black, but after exploring, is shown...and it's kept in the same showing, regardless of whether you actually have LoS to that area anymore. It would be nice if when you no longer had Line of Sight to a particular map area, it would be cloaked in a way so that you knew the terrain, but not the units there. Since I've sometimes spent over half an hour trying to hunt down that last alien hiding in area I'd already explored. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

====Deactivate Object Radar====

Currently, in X-COM, any objects dropped in a given square show on your Battlescape, regardless of whether you have Line of Sight to the square or not. In regards to dropped weapons/grenades/equipment/dead soldiers/dead aliens, this doesn't make a large difference. But in the case of STUNNED aliens, a quick scan across the Battlescape can tell you whether the alien you stunned 10 turns ago is still down, or stood back up(the stunned alien object will disappear from the stack). Of course, since aliens which have revived from stun are almost always disarmed(and the ones that aren't probably should've been killed instead), the usefulness of this 'exploit' is reduced mainly to finding out that the last alien you're looking for is just wandering aimlessly and unarmed. Perhaps leave stacks showing the same until you regain LoS to that area? [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

===Score for retaliation Battleships===

When a Battleship on retaliation attacks your base and is shot down, you get no score for it. This is completely illogical and it discourages any use of base defences. You should get normal 700 (or even 1400) points for it.
--[[User:Kyrub|Kyrub]] 14:05, 30 August 2008 (PDT)

: I'm not sure about this. Yes it's illogical, but it could also be a licence to get a huge score if you have a strong enough base. [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: The impenetrable base setup would turn into a cheat. As the aliens will keep hammering the base with a battleship until one breaks through, you'll have a steady supply of points without having to really do anything. Some balancing, such as paying to rearm your defence modules, ought to be thrown in to balance things out. -[[User:NKF|NKF]] 23:13, 13 September 2008 (PDT)
:::A better fix would be to remove the retaliation flag when a battleship is destroyed. If someone can post a savegame with a never-ending flow of base attacks, I may have a look at the fix. [[User:Seb76|Seb76]] 01:05, 15 September 2008 (PDT)

===Decrease Accuracy for targets out of sight===

How come you can easily shoot on something you do not see?
I find the over-used scout-sniper tactic is a cheap exploit of the X-COM. The tactical game should describe a combat, not a cowardly shooting practice. It would turn into a nice feature, if there would be a penalty of (let us say) -20% to the accuracy of anybody who is firing on a target out of his current sight. This can greatly enhance the tactical depth of the game. (Seb around? ;-) --[[User:Kyrub|Kyrub]] 14:20, 30 August 2008 (PDT)

: There is a penalty. Bullet drift. The further away you are, the more this will impact the bullet, potentially making even a 100% accurate shot miss. Also X-Com maps are pretty small, and the aliens already cheat enough as it is to make things difficult even with the sniper/scout strategy. In Apocalypse they addressed this with adding weapon ranges. But then, even some weapons were capable of shooting beyond the unit's ability to see an enemy target. - [[User:NKF|NKF]] 23:07, 13 September 2008 (PDT)

::That's not really a good reason for me. 1) Bullet drift has a very small effect in the game, because the actual percents are set quite high. Example: if you spray an unseen alien from the other corner of the map with autofire of 35%, you'll get a 73,6% chance to hit with at least one bullet. Physics and game balance, adieu. 2) Moreover, bullet drift has nothing to do with not seeing the target. It should be the contrary, you ACCIDENTALLY hit something you don't see, no? 3) You get a penalty for handling two weapons in the same time. Why couldn't we take the same penalty (80%*Acc) for the hit-out-of-sight? (Well, I can't do this actually, maybe others can)--[[User:Kyrub|Kyrub]] 18:25, 14 September 2008 (PDT)

: I don't agree that bullet drift is already there as a penalty, since this doesn't distinguish between seen and unseen targets at all (ok it does indirectly, only in so far as unseen targets tend to be further away). I think we should look at 3 cases: 1. person firing did not happen to be the one who '''spotted''' the target. 2. person firing '''could not''' see/spot the target under any circumstances. In the first case, we can assume the firer has visual contact with the target, after someone else pointed it out. No accuracy penalty should be applied (maybe a TU penalty?). In the second case, there should be an accuracy penalty. 80% would be generous, I would go for 50%. Or maybe something non-linear, so that autofire percentages would not fall by as much as aimed fire and snap fire percentages. One problem you have is how to present these two different cases to the player before they take the shot. It's a bit obscure if you just show them a lower hit probability without explaining why. [[User:Spike|Spike]] 19:02, 14 September 2008 (PDT)

:: Bullet drift is an effect on range (actually it has quite a major effect on the blaster bomb), but yes it's not because of whether or not the unit can see the alien. But then again, the maps are small. If you ever took lots of screen shots of the map and made a large composite from them, you'd find that the area of operations is very tiny and that the 20 tile visual range means that our avatars are quite short sighted. That's not realistic either, but imposed for game balance. Other tactical games appear to handle the accuracy vs. range dropoff issue by combining the shooter's skill and the weapon's maximum range. Basically you can operate the weapon to the best of the shooter's ability within the maximum range, but the further away you try to aim, accuracy is decreased. In some games, you even get to see the effect on the accuracy before you pull the trigger as the accuracy is attached to the cursor. - [[User:NKF|NKF]] 22:46, 14 September 2008 (PDT)

:::Actually the blaster bomb "drift" issue is not mainly caused by drift, but by accuracy adjustment between each waypoint (60% for xcom players, 55% for aliens). Maybe we can cook a kind of "max effective range" for a weapon base on firing mode (auto<snap<aimed) and gun type (pistol/rifle). Firing above this range would decrease the accuracy. [[User:Seb76|Seb76]] 01:03, 15 September 2008 (PDT)

:::: (to NKF) The main flaw of the whole "shoot the unseen" thing is the aliens cannot shoot back at somebody shooting at them (no reaction fire). If they could (or if they'd shoot at least the soldier they see), I wouldn't complain. This destroys the battle tactics side of the game, you just sent a man to "spot them". Nota bene, they cannot use the same scout-sniper tactic, the way we do, either. (This would be most annoying, by the way).
::::(to Seb76) Effective range would restore some balance and add some use to the aimed shots. I thought about a simpler solution with ''substracting'' some accuracy (which would make auto useless, snap into a poor and aimed into a solid chance-to-hit). Your suggestion is much more elegant, Seb, if you can cook it ;-) --[[User:Kyrub|Kyrub]] 08:00, 18 September 2008 (PDT)

===Enough Smoke===

It would be nice to increase the current limit on smoke/fire hexes. This is due to their locations being stored in a small, fixed length array. In effect you can only get about 3-4 smoke grenades worth of smoke or fire on the map at the same time. Being able to use smoke liberally would really open up new tactics. At the moment all you can really do is cover the LZ in smoke when you exit the transport, and maybe cover one advance over open ground. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Restore Game from Battlescape===

It would be nice to be able to reload a saved game directly from the Battlescape "?" screen, rather than having to go through the process of Abandoning to the Geoscape. Would you need to check it was a Battlescape save and not a Geoscape save? Maybe, maybe not. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Warm Grenades===

Currently when you set the timer on a grenade (or HE pack), the timer runs down every turn regardless of whether the grenade is worn, held, or dropped. Then, when the timer runs out, it explodes unless it is held or worn. There is no real grenade or explosive that works this way. Once the timer (fuse) starts running, they explode regardless. However for most hand grenades, the timer (fuse) doesn't start until after you throw/drop the grenade. It would be nice to have both of these real world behaviours, and lose the game's default behaviour. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

: Technically the way the game implements grenades, they don't have a timer. At least, not as such. When you set a grenade, the game just assigns it a turn to blow up on. Once the turn has passed, the game checks to see that it's on the ground and blows it up if it is, otherwise it doesn't. I believe Seb76 has already addressed this in his patches where there's an option to make grenade blow up regardless whether they are in inventory or otherwise the moment the timer is set. X-Com Apocalypse does a good job of this. The moment the grenade is so much as moved after the timer is set, it counts down. - [[User:NKF|NKF]] 23:01, 13 September 2008 (PDT)

:: To simulate an actual timer, you would need to do something like: Every turn that a primed grenade is being held by a unit during the "explode" check, increment by +1 the turn when that grenade is going to explode. [[User:Spike|Spike]] 19:10, 14 September 2008 (PDT)
:::I think I would change quantity2 ([[OBPOS.DAT]]) to a countdown instead of a turn, and use quantity3 as a flag indicating if the count has started. This flag is set any time a turn ends and the grenade has no owner. Taking it back in your hand once the timer has started won't help and the thing must be thrown... quantity2 is decreased if quantity3 is set, and the grenade blows up as usual. [[User:Seb76|Seb76]] 01:35, 15 September 2008 (PDT)

===Stun Grenades===

I want flashbangs.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)
:Instead of stunning, I'd see more effect if it would remove some TUs to units having line of sight (to be fare it should affect xcom units too). It would help against reaction fire (which is the point of flashbangs). Given that grenades detonate at the end turns, it would require a good coordination to have the grenade detonate exactly at the end of the alien turn, and just before your attack. Being able to open doors à la xcom2 would also help to throw flashbangs just before a craft assault... [[User:Seb76|Seb76]] 22:03, 12 September 2008 (PDT)
::That would be good. Hard to program, potentially extremely unbalancing, but good. I considered a "debuff" kind of ability (as you suggest) for flashbangs, vs the more obvious substitution of [[stun]] for [[HE]] damage. In the end, I picked "I want flashbangs."--[[User:Brunpal|Brunpal]] 03:32, 13 September 2008 (PDT)
: Maybe flashbangs dont' work on Aliens - otherwise, XCom would use them, right? :) But seriously, I too would like flashbangs, and stun grenades / concussion grenades. Both of these would make the game easier, though. With flashbangs, you might have to compensate by just giving the aliens more TUs. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)
::More options for the player is going to make it easier for any kind of game. Particularly of games like XCOM where the computer can't take advantage of the changes. However I don't believe a weak stun grenade (like 44 stun damage, comparable to AC-HE) would change the game much because the 80 item limit remains.--[[User:Brunpal|Brunpal]] 22:21, 13 September 2008 (PDT)

===Night Vision===

I '''don't''' want to add night vision equipment to the game. I assume that either (1) all XCom units already have night vision gear as standard, but it's not as good as alien night vision, and the visibility that XCom units have at night is based on their standard-issue night vision gear, or (2) night vision gear does not work on Aliens. Either they do not appear on night vision, or maybe worse - maybe the aliens can manipulate night vision equipment, causing worse than normal vision, or hallucinations, and even tricking XCom units into firing on each other. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)

===Throwing over stuff===

I want to throw stuff over other stuff. I don't find grenades useful. I much rather shoot a rocket launcher from outside reaction shot range because even when you miss, odds are it's close enough. The throw itself has an arc trajectory and can hit the ceiling (a feature I like) but to pick the target it has to have straight line of sight (like a bullet) which is stupid. I want to throw onto the top of buildings where I ''can't see'', or bounce a grenade off the ceiling and over the head of a squadie ''because '' I don't have line of sight with a gun. If I had line of sight, I would just shoot since that costs less TU even if I already had an armed grenade.

The easiest way to accomplish this is to keep "out of range" but remove "you can't throw there" and just let a solider throw to any square they want. A better way is to keep the warning but give the player the option to try the throw anyway. If you can't really throw there, then oops... that's your badly positioned live grenade to deal with.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)

:I did some tests disabling the "you can't throw there" check and it does not work. The grenade ends up in the vicinity of the throwing unit. Actually the line of sight is not used when throwing objects. I'm 98% sure it simulates the throwing of the object and if it intercepts anything, the throw is refused. [[User:Seb76|Seb76]] 04:47, 13 September 2008 (PDT)

:: The explicit emulation of the trajectory has been verified as part of the throwing range testing by [[User:Zombie|Zombie]] and myself. The range bands are not consistent with a continuous model; they look like a table lookup from the same source 3rd ed. GURPS (Steve Jackson Games) uses. -- [[User:Zaimoni|Zaimoni]] 8:21 13 September 2008 (CDT)

:::Units don't need LOS to an area to throw a grenade, as evidenced by my favored tactic of chucking an Alien Grenade or HE Pack into any Medium or Large Scout which has had the roof blown away in the crash from outside to 'pacify' any remaining crew. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:22, 13 September 2008 (PDT)

Really? It never seems to work for me. Always requires me to have line of sight. For example tossing in a grenade into the roof hole doesn't work for me if the solider is on level 0 and I target a square inside at level 0. The walls and door obviously block the LoS. However I can target an area on level 1 or 2 in mid air and throw to that location where it naturally drops down to level 0. However I have line of sight to those higher levels in that case.
That's an acceptable compromise in many cases but in others it fails completely. For example having an alien on the top of a 2 story building (level 2) in the middle and a solider standing next to the building and not being able to toss a grenade onto the center of the roof. I could toss a ball there in real life. I wouldn't have thought the trajectory would have been high/steep enough to hit the "sky roof".--[[User:Brunpal|Brunpal]] 22:04, 13 September 2008 (PDT)

: Just how strong are your soldiers? The stronger they are, the higher their toss. There are various occasions where you don't need to see where you're throwing to throw. For example, try tossing grenades over a tall fence or hedge. A High Explosive pack into the apple orchard that is surrounded by a hedge on farm maps is often an easy way to smoke out any hidden aliens - and the orchard. One likely cause why you can't throw inside the UFO is that there's something in the way inside that's preventing the throw, such as a wall. Try adjusting your throwing destination, or reposition your soldier for a better throwing angle.

: I've often found grenades to be much more reliable than a directional attack early in the game where firing accuracy is much lower. You ought to try playing a few of the simpler missions like supply ship or large scout assaults with an all-grenadier cast. Takes a bit of planning to not destroy much of the loot, but otherwise literally a blast. -[[User:NKF|NKF]] 22:52, 13 September 2008 (PDT)

===Enforced Variant Games===

Various people like to play various variant games, such as No Alien Technology, or No Detection, or No Lethal Weapons - see for example Scott Jones' notes to XComUtil. It would be nice to have options on the game executable to enforce these scenarios. Self restraint is hard! [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Assault Time Limit===

One of the cool things about UFO Defence is there are no time limits on the scenarios. This is great as it allows for a totally different kind of tactics and much more flexibility.
It's more of a "thinking man's game" as a result. But... arguably this is not very realistic for UFO Assault missions. If the Aliens are getting creamed, they should try to make a getaway if they can (just like XCom would). A simple way to implement this would be a hard time limit (say 20 turns?) on a UFO Assault. Another way would be to base it on Alien Morale. At a certain Morale level the aliens decide to dust off. Give the player say 3 turns warning while they rev up the engines. Then if there is still a Navigator or Engineer in the Control Room alive, the ship takes off. Any XCom troops still aboard are MIA.

You might run into problems if the UFO took off but then landed again or was shot down, generating another ground mission with potentially '''more''' Aliens than were still alive at the end of the Assault. (Still, maybe they hatch some more clones if they get time to....) [[User:Spike|Spike]] 09:51, 4 September 2008 (PDT)

: It strikes me as justified they don't do that. Troops loose in the vessel could be seriously bad. It would be nice if they dusted off on the condition that their morale was low enough or 3 X-com soldiers had the door in their sights without aliens alive outside in the latter case and no X-com soldiers on board in either case. also, if the UFO has a hole in either the command or engine room, it would have to set down before leaving the atmosphere. [[User:(name here)|(name here)]]

===Base Build Stacking===

At the moment you are only allowed to build next to a finished module, and you aren't allowed to plan ahead in your base construction. It would be nice to at least be able to plan more than one phase of construction in advance. This would be pretty easy to implement. There is no need to code any new "queuing system". Just place the new module next to an existing under-construction module, but increment the build time to the normal build time + the time remaining on the under-construction module (the lowest time remaining that would make the square you are building in, a legal square to build in). As a premium for build stacking, you have to pay the costs up-front. As with normal construction, all costs are non-refundable if you change your mind. (There would probably need to be some on-screen feedback for how long the module would take to build, before you were committed to building it.) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Recuit Certain Enemy===

Consider that not all alien loyal to its master (most TFTD alien has a device lodged to its brain), it should be interesting (or at least cool) if we can recuit such alien. Maybe we can replace those controling device from captive alien after research that specie. Or convince head of the Snakemen that it would be far more benefit to help us instead of the Ethereal [[User:L-Zwei|L-Zwei]] 23:25, 12 September 2008 (PDT).

==Fix All Bugs==

Oh no [[User:Seb76|Seb76]] already did this! :) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

== Category ==
The page needs to be listed in various categories, which ones I don't know. Also links on other pages to this one would aid people finding it.

: OK how about this one: [[User:Spike|Spike]] 12:21, 3 September 2008 (PDT)

[[Category:Oddities and bugs]]

Wish List (EU)

2008-09-18T15:03:57Z

Kyrub: /* Decrease Accuracy for targets out of sight */

X-Com is a great game and as evidence just look to the fact this wiki exists even though the game pre-dates the internet. In all it's greatness X-Com has some elements and behaviors players wish they could change. This is a repository of those desires. Some day a fan mod may make your wish come true...

== I Wish... ==
State what you want AND what X-com does normally. Sign your name if you think "Oh man! That would be great!"
=== Fuel Ready always ===
I wish that I could send out craft at any fuel or ammo level. Normally craft can only leave a base if fully "ready". Craft is only "ready" at 100% fuel (or 0% fuel using an exploit) but there's no logical reason why a full tank and full ammo is required. Fully repaired... that's fine. I can live with pilots refusing to fly a plane missing a wing even if it means England is lost to aliens. 15 hours to fill a tank? Retarded but I can live with that too if I can send out a craft at 20% fuel.
--[[User:Brunpal|Brunpal]]

:Actually, many modern aircraft '''do''' require the fuel tanks to be full on takeoff, and fairly empty on landing. The weight of the fuel is figured into the takeoff aerodynamics, and the tank being full prevents fuel 'sloshing' in the tanks and not actually making it to the engine. (Conversely, many aircraft need to have dispensed of much of that fuel weight before landing.) This holds for most runway-takeoff craft, but may not apply to anything with VTOL capacity; I'm unsure there.

:I do agree that non-full weapons aren't as critical, though. But from a logical standpoint, most modern aircraft should not be launched on an empty fuel tank. I also should noted that an Elerium-fueled craft with [[Known_Bugs#Elerium-fueled_Craft_Bug|50% fuel or less remaining]] will automatically return to base, regardless of distance from base. Of course, given that such craft fuel up quickly, its less of an issue there. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:05, 7 August 2008 (PDT)

:Hum, maybe you can try [[User:Seb76#Mods|this]]? [[User:Seb76|Seb76]] 13:01, 8 August 2008 (PDT)
::Thanks! But I can't try it. I've not been able to get my copy of Xcom to run properly except on a Win98 install. VC2008 requires a more modern OS. I'm sure I could ''eventually'' figure out a way to get it running, but I tried once and wasted too much time before giving up.--[[User:Brunpal|Brunpal]] 14:45, 8 August 2008 (PDT)
:AFAIK VC2008 binaries should run OK on Win98 as long as the runtime is deployed. Anyway, the loader uses CreateRemoteThread API which is not available in Win98 so don't even bother. '''However''', you can manually patch the binary if you want ;-) Data to patch (all in hexadecimal):
offset 0x41752: 2A0075 -> 18207C
:HTH. [[User:Seb76|Seb76]] 14:56, 8 August 2008 (PDT)

=== Smarter on Globe ===
I wish all craft understood the shortest distance between two points on a globe is a curved path towards the poles. Normally a craft goes in the opposite direction than it should (towards the equator). Pain in the ass when the base in the UK sends a craft to Siberia.
--[[User:Brunpal|Brunpal]]

===Equipment Management===

==== Soldiers remembers THEIR equipment ====
I wish soldiers remembered what equipment they LAST used and start with that gear when they land. Normally soldiers grab various gear and put lots of crap on their belt. I put most things on the shoulder slots, and keep many things spare things on the ship just in case I need them. (I only want IN rounds if it's night. Stop picking them up before I shoot you in the back!) Takes forever to sort out the gear so the weakling isn't carrying all the rockets etc.
--[[User:Brunpal|Brunpal]]

:This is already available in [[XcomUtil]]. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:07, 7 August 2008 (PDT)

====Access to Stats screens during equipment allocation====

In Battlescape you can get to Stats screens by right clicking on one of the unit's status bars. However you can't do this in the Equipment screen. Things like Statstrings and (even more so) [[User:Seb76|Seb76]]'s modified Equipment screen with actual/max weight help. But it would be nice to be able to see exact stats. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Fog of War Mk. 2===

I'm sure most of these would be an absolute PAIN to implement, but I figured I'd toss the ideas out here.

====Blind Dropship Pilots====
One thing that has always irked me is X-COM has no terrain knowledge when it lands, despite having probably circled the place two or three times before landing and thus they should know at least some of the area. This would be nice, but isn't too important. Probably would be a pain to implement so X-COM would have all knowledge of external features but no knowledge of building interiors, anyways. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

:Yes at the very least, when you splash the UFO, it could tell you (via some miracle technology such as "satellite reconnaisance") what the terrain type is of the landing zone area. Then you could adjust equipment accordingly. And adjust your uniform camouflage (if using one of the uniform mods). [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: Geoscape: center on the site, then maximum zoom. Aside from having to disambiguate forest from jungle, this works fine for knowing the exact terrain you're getting into. -- [[User:Zaimoni|Zaimoni]] 10:17, 4 Sept 2008 (CDT)

:::This is already present in the game. To center the Geoscape on a specific location, right-click on the target spot. To do maximum zoom in, right click on the Zoom-In button(and the same works for Zoom-Out). Also, Jungle and Forest use the same display algorithm, but are easy to differentiate; Forest occurs NORTH of the equator, and Jungle occurs SOUTH. [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:23, 4 September 2008 (PDT)

====Moving Fog====

The Fog of War in X-COM is clumsily implemented, compared to modern expectations. Everything starts out black, but after exploring, is shown...and it's kept in the same showing, regardless of whether you actually have LoS to that area anymore. It would be nice if when you no longer had Line of Sight to a particular map area, it would be cloaked in a way so that you knew the terrain, but not the units there. Since I've sometimes spent over half an hour trying to hunt down that last alien hiding in area I'd already explored. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

====Deactivate Object Radar====

Currently, in X-COM, any objects dropped in a given square show on your Battlescape, regardless of whether you have Line of Sight to the square or not. In regards to dropped weapons/grenades/equipment/dead soldiers/dead aliens, this doesn't make a large difference. But in the case of STUNNED aliens, a quick scan across the Battlescape can tell you whether the alien you stunned 10 turns ago is still down, or stood back up(the stunned alien object will disappear from the stack). Of course, since aliens which have revived from stun are almost always disarmed(and the ones that aren't probably should've been killed instead), the usefulness of this 'exploit' is reduced mainly to finding out that the last alien you're looking for is just wandering aimlessly and unarmed. Perhaps leave stacks showing the same until you regain LoS to that area? [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

===Score for retaliation Battleships===

When a Battleship on retaliation attacks your base and is shot down, you get no score for it. This is completely illogical and it discourages any use of base defences. You should get normal 700 (or even 1400) points for it.
--[[User:Kyrub|Kyrub]] 14:05, 30 August 2008 (PDT)

: I'm not sure about this. Yes it's illogical, but it could also be a licence to get a huge score if you have a strong enough base. [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: The impenetrable base setup would turn into a cheat. As the aliens will keep hammering the base with a battleship until one breaks through, you'll have a steady supply of points without having to really do anything. Some balancing, such as paying to rearm your defence modules, ought to be thrown in to balance things out. -[[User:NKF|NKF]] 23:13, 13 September 2008 (PDT)
:::A better fix would be to remove the retaliation flag when a battleship is destroyed. If someone can post a savegame with a never-ending flow of base attacks, I may have a look at the fix. [[User:Seb76|Seb76]] 01:05, 15 September 2008 (PDT)

===Decrease Accuracy for targets out of sight===

How come you can easily shoot on something you do not see?
I find the over-used scout-sniper tactic is a cheap exploit of the X-COM. The tactical game should describe a combat, not a cowardly shooting practice. It would turn into a nice feature, if there would be a penalty of (let us say) -20% to the accuracy of anybody who is firing on a target out of his current sight. This can greatly enhance the tactical depth of the game. (Seb around? ;-) --[[User:Kyrub|Kyrub]] 14:20, 30 August 2008 (PDT)

: There is a penalty. Bullet drift. The further away you are, the more this will impact the bullet, potentially making even a 100% accurate shot miss. Also X-Com maps are pretty small, and the aliens already cheat enough as it is to make things difficult even with the sniper/scout strategy. In Apocalypse they addressed this with adding weapon ranges. But then, even some weapons were capable of shooting beyond the unit's ability to see an enemy target. - [[User:NKF|NKF]] 23:07, 13 September 2008 (PDT)

::That's not really a good reason for me. 1) Bullet drift has a very small effect in the game, because the actual percents are set quite high. Example: if you spray an unseen alien from the other corner of the map with autofire of 35%, you'll get a 73,6% chance to hit with at least one bullet. Physics and game balance, adieu. 2) Moreover, bullet drift has nothing to do with not seeing the target. It should be the contrary, you ACCIDENTALLY hit something you don't see, no? 3) You get a penalty for handling two weapons in the same time. Why couldn't we take the same penalty (80%*Acc) for the hit-out-of-sight? (Well, I can't do this actually, maybe others can)--[[User:Kyrub|Kyrub]] 18:25, 14 September 2008 (PDT)

: I don't agree that bullet drift is already there as a penalty, since this doesn't distinguish between seen and unseen targets at all (ok it does indirectly, only in so far as unseen targets tend to be further away). I think we should look at 3 cases: 1. person firing did not happen to be the one who '''spotted''' the target. 2. person firing '''could not''' see/spot the target under any circumstances. In the first case, we can assume the firer has visual contact with the target, after someone else pointed it out. No accuracy penalty should be applied (maybe a TU penalty?). In the second case, there should be an accuracy penalty. 80% would be generous, I would go for 50%. Or maybe something non-linear, so that autofire percentages would not fall by as much as aimed fire and snap fire percentages. One problem you have is how to present these two different cases to the player before they take the shot. It's a bit obscure if you just show them a lower hit probability without explaining why. [[User:Spike|Spike]] 19:02, 14 September 2008 (PDT)

:: Bullet drift is an effect on range (actually it has quite a major effect on the blaster bomb), but yes it's not because of whether or not the unit can see the alien. But then again, the maps are small. If you ever took lots of screen shots of the map and made a large composite from them, you'd find that the area of operations is very tiny and that the 20 tile visual range means that our avatars are quite short sighted. That's not realistic either, but imposed for game balance. Other tactical games appear to handle the accuracy vs. range dropoff issue by combining the shooter's skill and the weapon's maximum range. Basically you can operate the weapon to the best of the shooter's ability within the maximum range, but the further away you try to aim, accuracy is decreased. In some games, you even get to see the effect on the accuracy before you pull the trigger as the accuracy is attached to the cursor. - [[User:NKF|NKF]] 22:46, 14 September 2008 (PDT)
::::The main flaw of the whole "shoot the unseen" thing is the aliens cannot shoot back at somebody shooting at them (no reaction fire). If they could (or if they'd shoot at least the soldier they see), I wouldn't complain. This destroys the battle tactics side of the game, you just sent a man to "spot them". Nota bene, they cannot use the same scout-sniper tactic, the way we do, either. (This would be most annoying, by the way). --[[User:Kyrub|Kyrub]] 08:00, 18 September 2008 (PDT)
:::Actually the blaster bomb "drift" issue is not mainly caused by drift, but by accuracy adjustment between each waypoint (60% for xcom players, 55% for aliens). Maybe we can cook a kind of "max effective range" for a weapon base on firing mode (auto<snap<aimed) and gun type (pistol/rifle). Firing above this range would decrease the accuracy. [[User:Seb76|Seb76]] 01:03, 15 September 2008 (PDT)

===Enough Smoke===

It would be nice to increase the current limit on smoke/fire hexes. This is due to their locations being stored in a small, fixed length array. In effect you can only get about 3-4 smoke grenades worth of smoke or fire on the map at the same time. Being able to use smoke liberally would really open up new tactics. At the moment all you can really do is cover the LZ in smoke when you exit the transport, and maybe cover one advance over open ground. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Restore Game from Battlescape===

It would be nice to be able to reload a saved game directly from the Battlescape "?" screen, rather than having to go through the process of Abandoning to the Geoscape. Would you need to check it was a Battlescape save and not a Geoscape save? Maybe, maybe not. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Warm Grenades===

Currently when you set the timer on a grenade (or HE pack), the timer runs down every turn regardless of whether the grenade is worn, held, or dropped. Then, when the timer runs out, it explodes unless it is held or worn. There is no real grenade or explosive that works this way. Once the timer (fuse) starts running, they explode regardless. However for most hand grenades, the timer (fuse) doesn't start until after you throw/drop the grenade. It would be nice to have both of these real world behaviours, and lose the game's default behaviour. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

: Technically the way the game implements grenades, they don't have a timer. At least, not as such. When you set a grenade, the game just assigns it a turn to blow up on. Once the turn has passed, the game checks to see that it's on the ground and blows it up if it is, otherwise it doesn't. I believe Seb76 has already addressed this in his patches where there's an option to make grenade blow up regardless whether they are in inventory or otherwise the moment the timer is set. X-Com Apocalypse does a good job of this. The moment the grenade is so much as moved after the timer is set, it counts down. - [[User:NKF|NKF]] 23:01, 13 September 2008 (PDT)

:: To simulate an actual timer, you would need to do something like: Every turn that a primed grenade is being held by a unit during the "explode" check, increment by +1 the turn when that grenade is going to explode. [[User:Spike|Spike]] 19:10, 14 September 2008 (PDT)
:::I think I would change quantity2 ([[OBPOS.DAT]]) to a countdown instead of a turn, and use quantity3 as a flag indicating if the count has started. This flag is set any time a turn ends and the grenade has no owner. Taking it back in your hand once the timer has started won't help and the thing must be thrown... quantity2 is decreased if quantity3 is set, and the grenade blows up as usual. [[User:Seb76|Seb76]] 01:35, 15 September 2008 (PDT)

===Stun Grenades===

I want flashbangs.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)
:Instead of stunning, I'd see more effect if it would remove some TUs to units having line of sight (to be fare it should affect xcom units too). It would help against reaction fire (which is the point of flashbangs). Given that grenades detonate at the end turns, it would require a good coordination to have the grenade detonate exactly at the end of the alien turn, and just before your attack. Being able to open doors à la xcom2 would also help to throw flashbangs just before a craft assault... [[User:Seb76|Seb76]] 22:03, 12 September 2008 (PDT)
::That would be good. Hard to program, potentially extremely unbalancing, but good. I considered a "debuff" kind of ability (as you suggest) for flashbangs, vs the more obvious substitution of [[stun]] for [[HE]] damage. In the end, I picked "I want flashbangs."--[[User:Brunpal|Brunpal]] 03:32, 13 September 2008 (PDT)
: Maybe flashbangs dont' work on Aliens - otherwise, XCom would use them, right? :) But seriously, I too would like flashbangs, and stun grenades / concussion grenades. Both of these would make the game easier, though. With flashbangs, you might have to compensate by just giving the aliens more TUs. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)
::More options for the player is going to make it easier for any kind of game. Particularly of games like XCOM where the computer can't take advantage of the changes. However I don't believe a weak stun grenade (like 44 stun damage, comparable to AC-HE) would change the game much because the 80 item limit remains.--[[User:Brunpal|Brunpal]] 22:21, 13 September 2008 (PDT)

===Night Vision===

I '''don't''' want to add night vision equipment to the game. I assume that either (1) all XCom units already have night vision gear as standard, but it's not as good as alien night vision, and the visibility that XCom units have at night is based on their standard-issue night vision gear, or (2) night vision gear does not work on Aliens. Either they do not appear on night vision, or maybe worse - maybe the aliens can manipulate night vision equipment, causing worse than normal vision, or hallucinations, and even tricking XCom units into firing on each other. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)

===Throwing over stuff===

I want to throw stuff over other stuff. I don't find grenades useful. I much rather shoot a rocket launcher from outside reaction shot range because even when you miss, odds are it's close enough. The throw itself has an arc trajectory and can hit the ceiling (a feature I like) but to pick the target it has to have straight line of sight (like a bullet) which is stupid. I want to throw onto the top of buildings where I ''can't see'', or bounce a grenade off the ceiling and over the head of a squadie ''because '' I don't have line of sight with a gun. If I had line of sight, I would just shoot since that costs less TU even if I already had an armed grenade.

The easiest way to accomplish this is to keep "out of range" but remove "you can't throw there" and just let a solider throw to any square they want. A better way is to keep the warning but give the player the option to try the throw anyway. If you can't really throw there, then oops... that's your badly positioned live grenade to deal with.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)

:I did some tests disabling the "you can't throw there" check and it does not work. The grenade ends up in the vicinity of the throwing unit. Actually the line of sight is not used when throwing objects. I'm 98% sure it simulates the throwing of the object and if it intercepts anything, the throw is refused. [[User:Seb76|Seb76]] 04:47, 13 September 2008 (PDT)

:: The explicit emulation of the trajectory has been verified as part of the throwing range testing by [[User:Zombie|Zombie]] and myself. The range bands are not consistent with a continuous model; they look like a table lookup from the same source 3rd ed. GURPS (Steve Jackson Games) uses. -- [[User:Zaimoni|Zaimoni]] 8:21 13 September 2008 (CDT)

:::Units don't need LOS to an area to throw a grenade, as evidenced by my favored tactic of chucking an Alien Grenade or HE Pack into any Medium or Large Scout which has had the roof blown away in the crash from outside to 'pacify' any remaining crew. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:22, 13 September 2008 (PDT)

Really? It never seems to work for me. Always requires me to have line of sight. For example tossing in a grenade into the roof hole doesn't work for me if the solider is on level 0 and I target a square inside at level 0. The walls and door obviously block the LoS. However I can target an area on level 1 or 2 in mid air and throw to that location where it naturally drops down to level 0. However I have line of sight to those higher levels in that case.
That's an acceptable compromise in many cases but in others it fails completely. For example having an alien on the top of a 2 story building (level 2) in the middle and a solider standing next to the building and not being able to toss a grenade onto the center of the roof. I could toss a ball there in real life. I wouldn't have thought the trajectory would have been high/steep enough to hit the "sky roof".--[[User:Brunpal|Brunpal]] 22:04, 13 September 2008 (PDT)

: Just how strong are your soldiers? The stronger they are, the higher their toss. There are various occasions where you don't need to see where you're throwing to throw. For example, try tossing grenades over a tall fence or hedge. A High Explosive pack into the apple orchard that is surrounded by a hedge on farm maps is often an easy way to smoke out any hidden aliens - and the orchard. One likely cause why you can't throw inside the UFO is that there's something in the way inside that's preventing the throw, such as a wall. Try adjusting your throwing destination, or reposition your soldier for a better throwing angle.

: I've often found grenades to be much more reliable than a directional attack early in the game where firing accuracy is much lower. You ought to try playing a few of the simpler missions like supply ship or large scout assaults with an all-grenadier cast. Takes a bit of planning to not destroy much of the loot, but otherwise literally a blast. -[[User:NKF|NKF]] 22:52, 13 September 2008 (PDT)

===Enforced Variant Games===

Various people like to play various variant games, such as No Alien Technology, or No Detection, or No Lethal Weapons - see for example Scott Jones' notes to XComUtil. It would be nice to have options on the game executable to enforce these scenarios. Self restraint is hard! [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Assault Time Limit===

One of the cool things about UFO Defence is there are no time limits on the scenarios. This is great as it allows for a totally different kind of tactics and much more flexibility.
It's more of a "thinking man's game" as a result. But... arguably this is not very realistic for UFO Assault missions. If the Aliens are getting creamed, they should try to make a getaway if they can (just like XCom would). A simple way to implement this would be a hard time limit (say 20 turns?) on a UFO Assault. Another way would be to base it on Alien Morale. At a certain Morale level the aliens decide to dust off. Give the player say 3 turns warning while they rev up the engines. Then if there is still a Navigator or Engineer in the Control Room alive, the ship takes off. Any XCom troops still aboard are MIA.

You might run into problems if the UFO took off but then landed again or was shot down, generating another ground mission with potentially '''more''' Aliens than were still alive at the end of the Assault. (Still, maybe they hatch some more clones if they get time to....) [[User:Spike|Spike]] 09:51, 4 September 2008 (PDT)

: It strikes me as justified they don't do that. Troops loose in the vessel could be seriously bad. It would be nice if they dusted off on the condition that their morale was low enough or 3 X-com soldiers had the door in their sights without aliens alive outside in the latter case and no X-com soldiers on board in either case. also, if the UFO has a hole in either the command or engine room, it would have to set down before leaving the atmosphere. [[User:(name here)|(name here)]]

===Base Build Stacking===

At the moment you are only allowed to build next to a finished module, and you aren't allowed to plan ahead in your base construction. It would be nice to at least be able to plan more than one phase of construction in advance. This would be pretty easy to implement. There is no need to code any new "queuing system". Just place the new module next to an existing under-construction module, but increment the build time to the normal build time + the time remaining on the under-construction module (the lowest time remaining that would make the square you are building in, a legal square to build in). As a premium for build stacking, you have to pay the costs up-front. As with normal construction, all costs are non-refundable if you change your mind. (There would probably need to be some on-screen feedback for how long the module would take to build, before you were committed to building it.) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Recuit Certain Enemy===

Consider that not all alien loyal to its master (most TFTD alien has a device lodged to its brain), it should be interesting (or at least cool) if we can recuit such alien. Maybe we can replace those controling device from captive alien after research that specie. Or convince head of the Snakemen that it would be far more benefit to help us instead of the Ethereal [[User:L-Zwei|L-Zwei]] 23:25, 12 September 2008 (PDT).

==Fix All Bugs==

Oh no [[User:Seb76|Seb76]] already did this! :) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

== Category ==
The page needs to be listed in various categories, which ones I don't know. Also links on other pages to this one would aid people finding it.

: OK how about this one: [[User:Spike|Spike]] 12:21, 3 September 2008 (PDT)

[[Category:Oddities and bugs]]

Wish List (EU)

2008-09-18T15:00:09Z

Kyrub: /* Decrease Accuracy for targets out of sight */

X-Com is a great game and as evidence just look to the fact this wiki exists even though the game pre-dates the internet. In all it's greatness X-Com has some elements and behaviors players wish they could change. This is a repository of those desires. Some day a fan mod may make your wish come true...

== I Wish... ==
State what you want AND what X-com does normally. Sign your name if you think "Oh man! That would be great!"
=== Fuel Ready always ===
I wish that I could send out craft at any fuel or ammo level. Normally craft can only leave a base if fully "ready". Craft is only "ready" at 100% fuel (or 0% fuel using an exploit) but there's no logical reason why a full tank and full ammo is required. Fully repaired... that's fine. I can live with pilots refusing to fly a plane missing a wing even if it means England is lost to aliens. 15 hours to fill a tank? Retarded but I can live with that too if I can send out a craft at 20% fuel.
--[[User:Brunpal|Brunpal]]

:Actually, many modern aircraft '''do''' require the fuel tanks to be full on takeoff, and fairly empty on landing. The weight of the fuel is figured into the takeoff aerodynamics, and the tank being full prevents fuel 'sloshing' in the tanks and not actually making it to the engine. (Conversely, many aircraft need to have dispensed of much of that fuel weight before landing.) This holds for most runway-takeoff craft, but may not apply to anything with VTOL capacity; I'm unsure there.

:I do agree that non-full weapons aren't as critical, though. But from a logical standpoint, most modern aircraft should not be launched on an empty fuel tank. I also should noted that an Elerium-fueled craft with [[Known_Bugs#Elerium-fueled_Craft_Bug|50% fuel or less remaining]] will automatically return to base, regardless of distance from base. Of course, given that such craft fuel up quickly, its less of an issue there. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:05, 7 August 2008 (PDT)

:Hum, maybe you can try [[User:Seb76#Mods|this]]? [[User:Seb76|Seb76]] 13:01, 8 August 2008 (PDT)
::Thanks! But I can't try it. I've not been able to get my copy of Xcom to run properly except on a Win98 install. VC2008 requires a more modern OS. I'm sure I could ''eventually'' figure out a way to get it running, but I tried once and wasted too much time before giving up.--[[User:Brunpal|Brunpal]] 14:45, 8 August 2008 (PDT)
:AFAIK VC2008 binaries should run OK on Win98 as long as the runtime is deployed. Anyway, the loader uses CreateRemoteThread API which is not available in Win98 so don't even bother. '''However''', you can manually patch the binary if you want ;-) Data to patch (all in hexadecimal):
offset 0x41752: 2A0075 -> 18207C
:HTH. [[User:Seb76|Seb76]] 14:56, 8 August 2008 (PDT)

=== Smarter on Globe ===
I wish all craft understood the shortest distance between two points on a globe is a curved path towards the poles. Normally a craft goes in the opposite direction than it should (towards the equator). Pain in the ass when the base in the UK sends a craft to Siberia.
--[[User:Brunpal|Brunpal]]

===Equipment Management===

==== Soldiers remembers THEIR equipment ====
I wish soldiers remembered what equipment they LAST used and start with that gear when they land. Normally soldiers grab various gear and put lots of crap on their belt. I put most things on the shoulder slots, and keep many things spare things on the ship just in case I need them. (I only want IN rounds if it's night. Stop picking them up before I shoot you in the back!) Takes forever to sort out the gear so the weakling isn't carrying all the rockets etc.
--[[User:Brunpal|Brunpal]]

:This is already available in [[XcomUtil]]. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:07, 7 August 2008 (PDT)

====Access to Stats screens during equipment allocation====

In Battlescape you can get to Stats screens by right clicking on one of the unit's status bars. However you can't do this in the Equipment screen. Things like Statstrings and (even more so) [[User:Seb76|Seb76]]'s modified Equipment screen with actual/max weight help. But it would be nice to be able to see exact stats. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Fog of War Mk. 2===

I'm sure most of these would be an absolute PAIN to implement, but I figured I'd toss the ideas out here.

====Blind Dropship Pilots====
One thing that has always irked me is X-COM has no terrain knowledge when it lands, despite having probably circled the place two or three times before landing and thus they should know at least some of the area. This would be nice, but isn't too important. Probably would be a pain to implement so X-COM would have all knowledge of external features but no knowledge of building interiors, anyways. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

:Yes at the very least, when you splash the UFO, it could tell you (via some miracle technology such as "satellite reconnaisance") what the terrain type is of the landing zone area. Then you could adjust equipment accordingly. And adjust your uniform camouflage (if using one of the uniform mods). [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: Geoscape: center on the site, then maximum zoom. Aside from having to disambiguate forest from jungle, this works fine for knowing the exact terrain you're getting into. -- [[User:Zaimoni|Zaimoni]] 10:17, 4 Sept 2008 (CDT)

:::This is already present in the game. To center the Geoscape on a specific location, right-click on the target spot. To do maximum zoom in, right click on the Zoom-In button(and the same works for Zoom-Out). Also, Jungle and Forest use the same display algorithm, but are easy to differentiate; Forest occurs NORTH of the equator, and Jungle occurs SOUTH. [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:23, 4 September 2008 (PDT)

====Moving Fog====

The Fog of War in X-COM is clumsily implemented, compared to modern expectations. Everything starts out black, but after exploring, is shown...and it's kept in the same showing, regardless of whether you actually have LoS to that area anymore. It would be nice if when you no longer had Line of Sight to a particular map area, it would be cloaked in a way so that you knew the terrain, but not the units there. Since I've sometimes spent over half an hour trying to hunt down that last alien hiding in area I'd already explored. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

====Deactivate Object Radar====

Currently, in X-COM, any objects dropped in a given square show on your Battlescape, regardless of whether you have Line of Sight to the square or not. In regards to dropped weapons/grenades/equipment/dead soldiers/dead aliens, this doesn't make a large difference. But in the case of STUNNED aliens, a quick scan across the Battlescape can tell you whether the alien you stunned 10 turns ago is still down, or stood back up(the stunned alien object will disappear from the stack). Of course, since aliens which have revived from stun are almost always disarmed(and the ones that aren't probably should've been killed instead), the usefulness of this 'exploit' is reduced mainly to finding out that the last alien you're looking for is just wandering aimlessly and unarmed. Perhaps leave stacks showing the same until you regain LoS to that area? [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

===Score for retaliation Battleships===

When a Battleship on retaliation attacks your base and is shot down, you get no score for it. This is completely illogical and it discourages any use of base defences. You should get normal 700 (or even 1400) points for it.
--[[User:Kyrub|Kyrub]] 14:05, 30 August 2008 (PDT)

: I'm not sure about this. Yes it's illogical, but it could also be a licence to get a huge score if you have a strong enough base. [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: The impenetrable base setup would turn into a cheat. As the aliens will keep hammering the base with a battleship until one breaks through, you'll have a steady supply of points without having to really do anything. Some balancing, such as paying to rearm your defence modules, ought to be thrown in to balance things out. -[[User:NKF|NKF]] 23:13, 13 September 2008 (PDT)
:::A better fix would be to remove the retaliation flag when a battleship is destroyed. If someone can post a savegame with a never-ending flow of base attacks, I may have a look at the fix. [[User:Seb76|Seb76]] 01:05, 15 September 2008 (PDT)

===Decrease Accuracy for targets out of sight===

How come you can easily shoot on something you do not see?
I find the over-used scout-sniper tactic is a cheap exploit of the X-COM. The tactical game should describe a combat, not a cowardly shooting practice. It would turn into a nice feature, if there would be a penalty of (let us say) -20% to the accuracy of anybody who is firing on a target out of his current sight. This can greatly enhance the tactical depth of the game. (Seb around? ;-) --[[User:Kyrub|Kyrub]] 14:20, 30 August 2008 (PDT)

: There is a penalty. Bullet drift. The further away you are, the more this will impact the bullet, potentially making even a 100% accurate shot miss. Also X-Com maps are pretty small, and the aliens already cheat enough as it is to make things difficult even with the sniper/scout strategy. In Apocalypse they addressed this with adding weapon ranges. But then, even some weapons were capable of shooting beyond the unit's ability to see an enemy target. - [[User:NKF|NKF]] 23:07, 13 September 2008 (PDT)

::That's not really a good reason for me. 1) Bullet drift has a very small effect in the game, because the actual percents are set quite high. Example: if you spray an unseen alien from the other corner of the map with autofire of 35%, you'll get a 73,6% chance to hit with at least one bullet. Physics and game balance, adieu. 2) Moreover, bullet drift has nothing to do with not seeing the target. It should be the contrary, you ACCIDENTALLY hit something you don't see, no? 3) You get a penalty for handling two weapons in the same time. Why couldn't we take the same penalty (80%*Acc) for the hit-out-of-sight? (Well, I can't do this actually, maybe others can)--[[User:Kyrub|Kyrub]] 18:25, 14 September 2008 (PDT)

: I don't agree that bullet drift is already there as a penalty, since this doesn't distinguish between seen and unseen targets at all (ok it does indirectly, only in so far as unseen targets tend to be further away). I think we should look at 3 cases: 1. person firing did not happen to be the one who '''spotted''' the target. 2. person firing '''could not''' see/spot the target under any circumstances. In the first case, we can assume the firer has visual contact with the target, after someone else pointed it out. No accuracy penalty should be applied (maybe a TU penalty?). In the second case, there should be an accuracy penalty. 80% would be generous, I would go for 50%. Or maybe something non-linear, so that autofire percentages would not fall by as much as aimed fire and snap fire percentages. One problem you have is how to present these two different cases to the player before they take the shot. It's a bit obscure if you just show them a lower hit probability without explaining why. [[User:Spike|Spike]] 19:02, 14 September 2008 (PDT)

:: Bullet drift is an effect on range (actually it has quite a major effect on the blaster bomb), but yes it's not because of whether or not the unit can see the alien. But then again, the maps are small. If you ever took lots of screen shots of the map and made a large composite from them, you'd find that the area of operations is very tiny and that the 20 tile visual range means that our avatars are quite short sighted. That's not realistic either, but imposed for game balance. Other tactical games appear to handle the accuracy vs. range dropoff issue by combining the shooter's skill and the weapon's maximum range. Basically you can operate the weapon to the best of the shooter's ability within the maximum range, but the further away you try to aim, accuracy is decreased. In some games, you even get to see the effect on the accuracy before you pull the trigger as the accuracy is attached to the cursor. - [[User:NKF|NKF]] 22:46, 14 September 2008 (PDT)
::::The main problem with "shoot the unseen" thing is the aliens cannot shoot back at somebody shooting at them. This destroys the battle tactics side of the game. If they could, I wouldn't complain. Nota bene, they cannot use the same scout-sniper tactic, the way we do, either. (This would be most annoying, by the way). --[[User:Kyrub|Kyrub]] 08:00, 18 September 2008 (PDT)
:::Actually the blaster bomb "drift" issue is not mainly caused by drift, but by accuracy adjustment between each waypoint (60% for xcom players, 55% for aliens). Maybe we can cook a kind of "max effective range" for a weapon base on firing mode (auto<snap<aimed) and gun type (pistol/rifle). Firing above this range would decrease the accuracy. [[User:Seb76|Seb76]] 01:03, 15 September 2008 (PDT)

===Enough Smoke===

It would be nice to increase the current limit on smoke/fire hexes. This is due to their locations being stored in a small, fixed length array. In effect you can only get about 3-4 smoke grenades worth of smoke or fire on the map at the same time. Being able to use smoke liberally would really open up new tactics. At the moment all you can really do is cover the LZ in smoke when you exit the transport, and maybe cover one advance over open ground. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Restore Game from Battlescape===

It would be nice to be able to reload a saved game directly from the Battlescape "?" screen, rather than having to go through the process of Abandoning to the Geoscape. Would you need to check it was a Battlescape save and not a Geoscape save? Maybe, maybe not. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Warm Grenades===

Currently when you set the timer on a grenade (or HE pack), the timer runs down every turn regardless of whether the grenade is worn, held, or dropped. Then, when the timer runs out, it explodes unless it is held or worn. There is no real grenade or explosive that works this way. Once the timer (fuse) starts running, they explode regardless. However for most hand grenades, the timer (fuse) doesn't start until after you throw/drop the grenade. It would be nice to have both of these real world behaviours, and lose the game's default behaviour. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

: Technically the way the game implements grenades, they don't have a timer. At least, not as such. When you set a grenade, the game just assigns it a turn to blow up on. Once the turn has passed, the game checks to see that it's on the ground and blows it up if it is, otherwise it doesn't. I believe Seb76 has already addressed this in his patches where there's an option to make grenade blow up regardless whether they are in inventory or otherwise the moment the timer is set. X-Com Apocalypse does a good job of this. The moment the grenade is so much as moved after the timer is set, it counts down. - [[User:NKF|NKF]] 23:01, 13 September 2008 (PDT)

:: To simulate an actual timer, you would need to do something like: Every turn that a primed grenade is being held by a unit during the "explode" check, increment by +1 the turn when that grenade is going to explode. [[User:Spike|Spike]] 19:10, 14 September 2008 (PDT)
:::I think I would change quantity2 ([[OBPOS.DAT]]) to a countdown instead of a turn, and use quantity3 as a flag indicating if the count has started. This flag is set any time a turn ends and the grenade has no owner. Taking it back in your hand once the timer has started won't help and the thing must be thrown... quantity2 is decreased if quantity3 is set, and the grenade blows up as usual. [[User:Seb76|Seb76]] 01:35, 15 September 2008 (PDT)

===Stun Grenades===

I want flashbangs.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)
:Instead of stunning, I'd see more effect if it would remove some TUs to units having line of sight (to be fare it should affect xcom units too). It would help against reaction fire (which is the point of flashbangs). Given that grenades detonate at the end turns, it would require a good coordination to have the grenade detonate exactly at the end of the alien turn, and just before your attack. Being able to open doors à la xcom2 would also help to throw flashbangs just before a craft assault... [[User:Seb76|Seb76]] 22:03, 12 September 2008 (PDT)
::That would be good. Hard to program, potentially extremely unbalancing, but good. I considered a "debuff" kind of ability (as you suggest) for flashbangs, vs the more obvious substitution of [[stun]] for [[HE]] damage. In the end, I picked "I want flashbangs."--[[User:Brunpal|Brunpal]] 03:32, 13 September 2008 (PDT)
: Maybe flashbangs dont' work on Aliens - otherwise, XCom would use them, right? :) But seriously, I too would like flashbangs, and stun grenades / concussion grenades. Both of these would make the game easier, though. With flashbangs, you might have to compensate by just giving the aliens more TUs. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)
::More options for the player is going to make it easier for any kind of game. Particularly of games like XCOM where the computer can't take advantage of the changes. However I don't believe a weak stun grenade (like 44 stun damage, comparable to AC-HE) would change the game much because the 80 item limit remains.--[[User:Brunpal|Brunpal]] 22:21, 13 September 2008 (PDT)

===Night Vision===

I '''don't''' want to add night vision equipment to the game. I assume that either (1) all XCom units already have night vision gear as standard, but it's not as good as alien night vision, and the visibility that XCom units have at night is based on their standard-issue night vision gear, or (2) night vision gear does not work on Aliens. Either they do not appear on night vision, or maybe worse - maybe the aliens can manipulate night vision equipment, causing worse than normal vision, or hallucinations, and even tricking XCom units into firing on each other. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)

===Throwing over stuff===

I want to throw stuff over other stuff. I don't find grenades useful. I much rather shoot a rocket launcher from outside reaction shot range because even when you miss, odds are it's close enough. The throw itself has an arc trajectory and can hit the ceiling (a feature I like) but to pick the target it has to have straight line of sight (like a bullet) which is stupid. I want to throw onto the top of buildings where I ''can't see'', or bounce a grenade off the ceiling and over the head of a squadie ''because '' I don't have line of sight with a gun. If I had line of sight, I would just shoot since that costs less TU even if I already had an armed grenade.

The easiest way to accomplish this is to keep "out of range" but remove "you can't throw there" and just let a solider throw to any square they want. A better way is to keep the warning but give the player the option to try the throw anyway. If you can't really throw there, then oops... that's your badly positioned live grenade to deal with.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)

:I did some tests disabling the "you can't throw there" check and it does not work. The grenade ends up in the vicinity of the throwing unit. Actually the line of sight is not used when throwing objects. I'm 98% sure it simulates the throwing of the object and if it intercepts anything, the throw is refused. [[User:Seb76|Seb76]] 04:47, 13 September 2008 (PDT)

:: The explicit emulation of the trajectory has been verified as part of the throwing range testing by [[User:Zombie|Zombie]] and myself. The range bands are not consistent with a continuous model; they look like a table lookup from the same source 3rd ed. GURPS (Steve Jackson Games) uses. -- [[User:Zaimoni|Zaimoni]] 8:21 13 September 2008 (CDT)

:::Units don't need LOS to an area to throw a grenade, as evidenced by my favored tactic of chucking an Alien Grenade or HE Pack into any Medium or Large Scout which has had the roof blown away in the crash from outside to 'pacify' any remaining crew. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:22, 13 September 2008 (PDT)

Really? It never seems to work for me. Always requires me to have line of sight. For example tossing in a grenade into the roof hole doesn't work for me if the solider is on level 0 and I target a square inside at level 0. The walls and door obviously block the LoS. However I can target an area on level 1 or 2 in mid air and throw to that location where it naturally drops down to level 0. However I have line of sight to those higher levels in that case.
That's an acceptable compromise in many cases but in others it fails completely. For example having an alien on the top of a 2 story building (level 2) in the middle and a solider standing next to the building and not being able to toss a grenade onto the center of the roof. I could toss a ball there in real life. I wouldn't have thought the trajectory would have been high/steep enough to hit the "sky roof".--[[User:Brunpal|Brunpal]] 22:04, 13 September 2008 (PDT)

: Just how strong are your soldiers? The stronger they are, the higher their toss. There are various occasions where you don't need to see where you're throwing to throw. For example, try tossing grenades over a tall fence or hedge. A High Explosive pack into the apple orchard that is surrounded by a hedge on farm maps is often an easy way to smoke out any hidden aliens - and the orchard. One likely cause why you can't throw inside the UFO is that there's something in the way inside that's preventing the throw, such as a wall. Try adjusting your throwing destination, or reposition your soldier for a better throwing angle.

: I've often found grenades to be much more reliable than a directional attack early in the game where firing accuracy is much lower. You ought to try playing a few of the simpler missions like supply ship or large scout assaults with an all-grenadier cast. Takes a bit of planning to not destroy much of the loot, but otherwise literally a blast. -[[User:NKF|NKF]] 22:52, 13 September 2008 (PDT)

===Enforced Variant Games===

Various people like to play various variant games, such as No Alien Technology, or No Detection, or No Lethal Weapons - see for example Scott Jones' notes to XComUtil. It would be nice to have options on the game executable to enforce these scenarios. Self restraint is hard! [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Assault Time Limit===

One of the cool things about UFO Defence is there are no time limits on the scenarios. This is great as it allows for a totally different kind of tactics and much more flexibility.
It's more of a "thinking man's game" as a result. But... arguably this is not very realistic for UFO Assault missions. If the Aliens are getting creamed, they should try to make a getaway if they can (just like XCom would). A simple way to implement this would be a hard time limit (say 20 turns?) on a UFO Assault. Another way would be to base it on Alien Morale. At a certain Morale level the aliens decide to dust off. Give the player say 3 turns warning while they rev up the engines. Then if there is still a Navigator or Engineer in the Control Room alive, the ship takes off. Any XCom troops still aboard are MIA.

You might run into problems if the UFO took off but then landed again or was shot down, generating another ground mission with potentially '''more''' Aliens than were still alive at the end of the Assault. (Still, maybe they hatch some more clones if they get time to....) [[User:Spike|Spike]] 09:51, 4 September 2008 (PDT)

: It strikes me as justified they don't do that. Troops loose in the vessel could be seriously bad. It would be nice if they dusted off on the condition that their morale was low enough or 3 X-com soldiers had the door in their sights without aliens alive outside in the latter case and no X-com soldiers on board in either case. also, if the UFO has a hole in either the command or engine room, it would have to set down before leaving the atmosphere. [[User:(name here)|(name here)]]

===Base Build Stacking===

At the moment you are only allowed to build next to a finished module, and you aren't allowed to plan ahead in your base construction. It would be nice to at least be able to plan more than one phase of construction in advance. This would be pretty easy to implement. There is no need to code any new "queuing system". Just place the new module next to an existing under-construction module, but increment the build time to the normal build time + the time remaining on the under-construction module (the lowest time remaining that would make the square you are building in, a legal square to build in). As a premium for build stacking, you have to pay the costs up-front. As with normal construction, all costs are non-refundable if you change your mind. (There would probably need to be some on-screen feedback for how long the module would take to build, before you were committed to building it.) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Recuit Certain Enemy===

Consider that not all alien loyal to its master (most TFTD alien has a device lodged to its brain), it should be interesting (or at least cool) if we can recuit such alien. Maybe we can replace those controling device from captive alien after research that specie. Or convince head of the Snakemen that it would be far more benefit to help us instead of the Ethereal [[User:L-Zwei|L-Zwei]] 23:25, 12 September 2008 (PDT).

==Fix All Bugs==

Oh no [[User:Seb76|Seb76]] already did this! :) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

== Category ==
The page needs to be listed in various categories, which ones I don't know. Also links on other pages to this one would aid people finding it.

: OK how about this one: [[User:Spike|Spike]] 12:21, 3 September 2008 (PDT)

[[Category:Oddities and bugs]]

User talk:Seb76

2008-09-17T22:34:32Z

Kyrub: /* Facility maintenance cost bug */

User talk:Seb76

2008-09-17T22:32:54Z

Kyrub: /* Facility maintenance cost bug */

Wish List (EU)

2008-09-15T01:27:29Z

Kyrub: /* Decrease Accuracy for targets out of sight */

Wish List (EU)

2008-09-15T01:25:12Z

Kyrub: /* Decrease Accuracy for targets out of sight */

User talk:Seb76

2008-09-08T22:43:40Z

Kyrub: /* UFOloader and Xcomutil */

File:RunXcomW.zip

2008-09-08T22:34:42Z

Kyrub:

Modified batch to make work Seb76's Ufoloader with Xcomutil /author Seb76/

You may need to activate "Video pitch" AND "Music" bug fixes in Ufoextender.ini to let the game work properly.

File:RunXcomW.zip

2008-09-08T22:33:57Z

Kyrub:

Modified batch to make work Seb76's Ufoloader with Xcomutil /author Seb76/

You may need to activate "Video pitch" AND "Music" bug fixes in Ufoextender.ini!