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 unmodified, and so are 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 can still allow the shot to land).

Because perfect aim is perfect aim, no matter the size or distance of the target 100% accuracy should give a 100% hit rate. For anything less then a rated 100% accuracy, size and distance become all important: As size decreases and distance increases, the range of angles that could lead to a hit fall. As accuracy decreases, the range of angles that a shot can take rise 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 is (range of acceptable hitting angles)/(range of possible firing angles). This assumes 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.

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.

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 stood on tiles similar to the large earth blocks you see in bases, 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 second row stood on walls facing to the east/west. Unlike the first row, in this example I moved a single layer for each tile, as opposed to having all layers and 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 third 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).

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.

Now, assuming that at 100% accuracy you should never miss, a formula should be apparent in there somewhere. However I'll collect a few more for other rated accuracies before I start any serious number crunching.

Target Size

To do: Determine the exact size of a given unit. We know height and where a unit "floats" within a tile, have to find width and depth. Hopefully these values are in UnitRef[48]/[52].

After setting up a spare machine to perform the angle tests, I ran into an immediate problem: I could not target units. Attempts to do so gave a "No LOF!" error, no matter what the range was between them. Attempting to fire at the ground worked fine. After replacing my modified LOFTemps file with an original, this was resolved.

Despite the conclusion being obvious, it took a little while for me to work out what this meant: Units use the same LOF templates as terrain!!

I still believe the aforementioned UnitRef values are involved (indeed, it looks like they could map directly into LOFTemps), but some testing is still required to work out exactly what's going on here.

Guess this means we'll soon be able to make a "truly" invulnerable unit.

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)

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)

User talk:Bomb Bloke

Contents