User talk:Bomb Bloke

Redundant Images / Pages

Here be a list of images and / or pages that I think can be deleted safely (because they've been replaced with other files or links, or created by accident).

None at the moment.

You Have New Messages

Now that I've started using this talk page again, I get the message "You have new messages" attached to the top of every page (other then this one) that I visit. Most annoying. Anyone know how to get rid of it? - BB

---

Do you still get those messages BB? --Zombie 00:04, 11 September 2006 (PDT)

---

I just figured out the answer a couple of days ago. Up the top of the page is an watch/unwatch link that toggles. Whenever a new post is made on the messages page, the page becomes "watched", and you have to click it before the notifications stop. - Bomb Bloke 03:16, 11 September 2006 (PDT)

Firing Accuracy

Consider this a draft/discussion on 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 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.

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.

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, 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]).

LOFtemps used, as opposed to the 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).

---

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? 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 - 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. 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). -- Zaimoni 11:49, 3 May 2008 (CDT)

Rated Accuracy Vs Angle Range

Just a few results before I go off camping for the weekend. First off, note that 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 2550 results for 0% firing accuracy overnight and 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*. - 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. - 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... - 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. - 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. - 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. - 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". - 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. 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. - 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! 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): 0% - 25% - 50% - 75% - 100%

New data (with a roof, vertical shot data might actually be worth something): 0% - 25% - 50% - 75% - 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. :(

- Bomb Bloke 09:37, 18 March 2009 (EDT)

---

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...

- 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.) -- 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. -- 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)? Spike 17:53, 15 April 2009 (EDT)

Target Size

Units are cylinders, made up of a LOFTEMPS.DAT layer determined by 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

Can't get Hybrid to work

Hey BB, I've downloaded your Hybrid program but I can't seem to be able to run. I got latest Java, I unzipped Hybrid to the UFO folder and I have changed the Hybrid.bat file to: set CLASSPATH=D:\Terror\ Every time i ran it though I get an exception- Can you please tell me what i've been doing wrong? Hobbes 10:34, 22 March 2008 (PDT)

---

Edit edit edit, I forgot how this thing worked...

Ok, extract the archive into your game folder, open up a prompt window. If UFO is in D:\UFO, the program should end up in D:\UFO\Hybrid. Change to that folder and run it with the other game's path as a parameter. eg:

Hybrid D:\Terror

If that gives an exception, lemme know what it is.

The classpath line should be left as it was. It's just required on some systems for java to work correctly.

- Bomb Bloke 16:17, 22 March 2008 (PDT)

Inventory screens

Hi Bomb Bloke

I really love your Map editor, which in fairness is a full Battlescape editor. It crashes for me a lot but probably that's because I have other mods messing with the files.

My question is - do your cool Inventory screens work with the actual game? I would love to see my weight and TUs while loading up my guys. Otherwise you need paper and pencil and printouts.

thanks! Spike 11:28, 25 March 2008 (PDT)

---

The alien portraits do, the editor tweaks the save files so the actual game will use them. I'll be making that optional though (because if the saves are then transferred to a system that doesn't have the extra graphics the game could crash).

I'm afraid I can't add the weight display stats to the original game. Seb76 or one of the other machine coders out there might be able to pull it off, but it's a big ask (right up there with adding stuff to the tech tree).

You mean stuff like that? File:Ufo weight.zip ;-) Seb76 18:09, 28 March 2008 (PDT)

That's pretty impressive... :O Reckon you could get it to display unit strength as well? Bomb Bloke 20:53, 28 March 2008 (PDT)

You are correct, I could have done it. Have a look at the updated version ;-) Seb76 10:23, 29 March 2008 (PDT)

That's nearly perfect, but... well, there's always a catch, isn't there? ;)

For whatever reason, the weight carried by some troopers won't display. Here's a sample save game: File:GAME 4.zip (check the guy in front of the ramp). I've tried loading up the units in concern and they do get their TU penalty if I go over their limit, but the weight carried always shows up as "0" on their inventory screens.

In most of my saves (just about any that involve flying suits) it doesn't work for any units. Bomb Bloke 19:53, 29 March 2008 (PDT)

I'm using offset 0x28 of unitref.dat to get the soldier.dat index (to in turn get the carried weigth via an already builtin function). Strangely it is set to 0xff for some units. Did you mess too much with this file? Or maybe offset 0x28 is not yet completely understood. Seb76 02:07, 30 March 2008 (PDT)

I think I nailed it. Care for another try? Seb76 02:42, 30 March 2008 (PDT)

Yes, this one seems to be working perfectly. Mind if I build it into a patcher tomorrow and stick it up on StrategyCore, so it can be used with other mods? (or does it add code to the end of the executable, like Mok's does)?

Some code is added in the executable in a padding section (unused space in the binary) so the file has still the same size. It'll conflict with other patches if they use the same place in the executable to inject their code (the patch specifics are available on the download page). I have no account in SC so I don't know what other mods do... Perhaps a bit of testing is required before posting this (does it works if you MC an alien and go to its inventory screen?). Seb76 10:09, 30 March 2008 (PDT)

That offset isn't used by non-X-Com troopers (the trooper in front of the ramp was created with my editor, which "wipes" that offset for clones). So it should've also failed for civilians and aliens.

Not sure why it failed for my flying suit troopers. I was starting to think large units might've been messing up the calculation. Bomb Bloke 08:34, 30 March 2008 (PDT)

The first version was faulty anyway: it used the soldier.dat entry index instead of unitpos index. It worked as long as noone died else things start to get out of sync. Seb76 10:09, 30 March 2008 (PDT)

If you know specific methods to crash the editor, or have certain save games it won't load, I'd love to see them. I'm forever working bugs out of the thing but I'm limited in that I never get any actual bug reports. :(

I do know that it probably won't load XcomUtil based saves that use alternate terrain sets (eg. Hobbes's maps).

- Bomb Bloke 19:02, 25 March 2008 (PDT)

---

Thanks BB. What tends to happen is the editor hangs during file load, on the saved games list screen. The only clue is that the mouse pointer is visible/movable(normally the pointer disappears during file load). Back in the BBmap_edit.bat Dos window, it will have an "Array out of bounds" error (generic, I know). Will try to get a reproducible bug and send you the game save dir. Cheers, Spike 01:56, 27 March 2008 (PDT)