Automated UFO Trials

[Bomb Bloke]

Long have people been performing simple, repedative tasks over and over in UFO in order to record the results. No more! The time for this madness has come to an end!

 

Two things are required in order to make the computer do all of the work for you - Something to perform the actions, and something to record the results. Although different software would need to be written for recording different situations, there's not much that isn't already covered by my logger, and so that's what we'll be using for this example (in the form of a firing accuracy test).

 

Download and install it as per the readme in the archive. Note that it states a requirement of installing XcomUtil for CE users, but details how to do so without contaminating your game files. If you really want to go without it, though, the required split of the game executable can now also be performed by this new program.

 

Once set up, try out the logger for a bit, get the hang of it. Again, the instructions are included in the archive. When you have a vague idea as to how it works, create a save game with a unit ready to shoot an alien. He should have his loaded gun in hand, and be facing the visible foe with enough time units to make the shot.

 

Ideally, you want this unit to be selected as soon as the game is loaded. If he's the first unit in the unit table, this is impossible - That is to say, if you send only one unit into combat and save the game, when you reload, no unit will be selected at all! Hence I recommend sending only two units, and using the second one in your trials. This ensures the correct unit will be selected whenever the logger loads the game. Unsure as to which is the first unit in play? Load the game with my editer, select the guy you want to query, and when you quit you'll see his index. If that's unitref[0], he's at the top of the list.

 

Once you have the save tailored to your liking, get AutoHotKey. This free program allows you to record keyboard and mouse input, then play it back. It's a little complex at first, so I'll be going over it in some detail.

 

Once installed, find the program on your Start Menu, and boot up the "AutoScriptWriter (recorder)". Boot up the logger, and when the game map loads, abort the mission. The logger will prompt you to press any key to continue. Press "record" on the script writer, select the logger window again, then hit space.

 

When the game loads, your unit will be selected, and the "alien visible" box will be flashing around the lower right hand corner. Don't scroll to the aliens location, as the recorder won't catch that - Instead, click the visibility box to center the alien instantly. Select your gun, select your firing mode, then click the alien. Once the shot is fired, abort the mission.

 

The logger will again prompt you to press a key. Hit space again, but this time when the game loads up, abort right away, then hit the "stop" button on the recorder.

 

Now you have a macro. All the actions performed are listed line by line in front of you. Now you need to clean it up. Look for the first instance of a line reading "Send, {SPACE}", and delete everything above it. Once you've done that, look for the next line which reads "Send, {SPACE}" and delete it, along with everything below. Your macro should now look something like this:

 

Send, {SPACE}
WinWait, X-COM Gold Edition, 
IfWinNotActive, X-COM Gold Edition, , WinActivate, X-COM Gold Edition, 
WinWaitActive, X-COM Gold Edition, 
MouseClick, left,  306,  132
Sleep, 100
MouseClick, left,  294,  168
Sleep, 100
MouseClick, left,  90,  101
Sleep, 100
MouseClick, left,  160,  77
Sleep, 100
MouseClick, left,  248,  164
Sleep, 100
MouseClick, left,  78,  118
Sleep, 100
WinWait, C:\WINDOWS\system32\cmd.exe, 
IfWinNotActive, C:\WINDOWS\system32\cmd.exe, , WinActivate, C:\WINDOWS\system32\cmd.exe, 
WinWaitActive, C:\WINDOWS\system32\cmd.exe,

 

Even non-coders shouldn't have too hard a time guessing what these lines do. To sum up the flow of this script, first the space bar is pressed, then the macro waits until UFO loads up. Once that's done, it executes the mouse clicks at the location you made them, and then waits for the command window (that is, the logger) to become active again before ending. If this were to be looped, then your trial would be repeated automatically for you. But first, you need to make sure you can rely on this to work.

 

When the macro plays back, it does so at speed. Fast enough that it's possible some of your clicks might be missed by the game, which is a very, very bad thing - All of your trials must be the same. Having two shots fired in one sample, or none at all, messes up your results. Hence every click must register.

 

Add a line stating "Sleep, 4000" after the two "WinWaitActive" lines. The sleep line basically makes the macro wait an extra period of time. This makes sure the logger, and UFO, is not only active, but ready to recieve input when the clicks and key presses start coming. If you see any "MouseClick" lines without a "Sleep, 100" line under it, you'll also need to insert those there:

 

Send, {SPACE}
WinWait, X-COM Gold Edition, 
IfWinNotActive, X-COM Gold Edition, , WinActivate, X-COM Gold Edition, 
WinWaitActive, X-COM Gold Edition, 
Sleep, 4000
MouseClick, left,  306,  132
Sleep, 100
MouseClick, left,  294,  168
Sleep, 100
MouseClick, left,  90,  101
Sleep, 100
MouseClick, left,  160,  77
Sleep, 100
MouseClick, left,  248,  164
Sleep, 100
MouseClick, left,  78,  118
Sleep, 100
WinWait, C:\WINDOWS\system32\cmd.exe, 
IfWinNotActive, C:\WINDOWS\system32\cmd.exe, , WinActivate, C:\WINDOWS\system32\cmd.exe, 
WinWaitActive, C:\WINDOWS\system32\cmd.exe,
Sleep, 4000

 

Next off, we need to extend the clicks of the mouse. Unfortunetly, I can't seem to find a way to do this other then by making the macro drag the mouse. However, this isn't too hard to do.

 

Change each instance of the term "MouseClick" to "MouseClickDrag". You'll note that each of these lines also has two numbers at the end, preceded by commas. These are the screen offsets of where the initial clicks are to be made. Add an extra copy of those numbers to the end of the lines, but increment them by one. For example:

 

MouseClick, left, 306, 132

 

Becomes:

 

MouseClickDrag, left, 306, 132, 307, 133

 

Resulting in this:

 

Send, {SPACE}
WinWait, X-COM Gold Edition, 
IfWinNotActive, X-COM Gold Edition, , WinActivate, X-COM Gold Edition, 
WinWaitActive, X-COM Gold Edition, 
Sleep, 4000
MouseClickDrag, left,  306,  132,  307,  133
Sleep, 100
MouseClickDrag, left,  294,  168,  295,  169
Sleep, 100
MouseClickDrag, left,  90,  101,  91,  102
Sleep, 100
MouseClickDrag, left,  160,  77,  161,  78
Sleep, 100
MouseClickDrag, left,  248,  164,  249,  165
Sleep, 100
MouseClickDrag, left,  78,  118,  79,  119
Sleep, 100
WinWait, C:\WINDOWS\system32\cmd.exe, 
IfWinNotActive, C:\WINDOWS\system32\cmd.exe, , WinActivate, C:\WINDOWS\system32\cmd.exe, 
WinWaitActive, C:\WINDOWS\system32\cmd.exe, 
Sleep, 4000

 

And for now, that's it. You're ready to try it out. Save the script to your UFO game folder, and double click on it. It'll automatically send a press of the space bar, but since the logger isn't running yet, this won't result in UFO booting up - Hence the macro will sit and wait there until that happens. Boot up the logger, and you should see your shot being replayed before you, before the mission automatically aborts.

 

In my case, I found that the click on the "abort" button didn't happen. This is because there wasn't enough time between the shot being fired, and the next click being made. The solution is to raise the delay after the shot is fired.

 

Given that the first click I made was on the "visible alien" icon, the second was to select my gun, and the third to select my firing method, the forth mouse click was the one I used to fire the actual shot at the alien. And indeed, the co-ordinates roughly match the center of the screen. Raise the delay after this to 4000.

 

Send, {SPACE}
WinWait, X-COM Gold Edition, 
IfWinNotActive, X-COM Gold Edition, , WinActivate, X-COM Gold Edition, 
WinWaitActive, X-COM Gold Edition, 
Sleep, 4000
MouseClickDrag, left,  306,  132,  307,  133
Sleep, 100
MouseClickDrag, left,  294,  168,  295,  169
Sleep, 100
MouseClickDrag, left,  90,  101,  91,  102
Sleep, 100
MouseClickDrag, left,  160,  77,  161,  78
Sleep, 4000
MouseClickDrag, left,  248,  164,  249,  165
Sleep, 100
MouseClickDrag, left,  78,  118,  79,  119
Sleep, 100
WinWait, C:\WINDOWS\system32\cmd.exe, 
IfWinNotActive, C:\WINDOWS\system32\cmd.exe, , WinActivate, C:\WINDOWS\system32\cmd.exe, 
WinWaitActive, C:\WINDOWS\system32\cmd.exe, 
Sleep, 4000

 

Resave the file, and give it another go.

 

If you have similar problems after other mouse clicks, try raising the other values, too. Obviously, you want the macro to run at top speed, but it's useless if it's not reliable. The value of 4000 I used for the larger delays gives enough time for me to fire across a screen, the alien to return fire, and for my unit to die, which is pretty much as long as it gets.

 

You could, in theory, have a unit fire the whole way across the map, so long as the alien is visible. Select the unit you want to take the shot, then select the overhead map. Use this to center on the alien before closing it and taking the shot. You might need to extend the "after shot" delay a little more in this case, but remember you can speed up the time taken to fire in the UFO options menu.

 

Once it's working, you're ready to go fully automated, and turn the script into a loop. Right at the top, add a line stating "start:", and right at the bottom, add a line stating "goto start". Save the file, start the script, then start the logger.

 

Your test should be repeated over... and over... and over...

 

To stop it, wait for the logger screen to appear, and quickly hit Ctrl+C. This will prevent the game starting again, and the macro will sit and wait for that to happen instead of jerking your mouse around. You can now right click the macro in your system tray, and tell it to exit.

 

Here is the final version of the script made via this tutorial:

 

start:
Send, {SPACE}
WinWait, X-COM Gold Edition, 
IfWinNotActive, X-COM Gold Edition, , WinActivate, X-COM Gold Edition, 
WinWaitActive, X-COM Gold Edition, 
Sleep, 4000
MouseClickDrag, left,  306,  132,  307,  133
Sleep, 100
MouseClickDrag, left,  294,  168,  295,  169
Sleep, 100
MouseClickDrag, left,  90,  101,  91,  102
Sleep, 100
MouseClickDrag, left,  160,  77,  161,  78
Sleep, 4000
MouseClickDrag, left,  248,  164,  249,  165
Sleep, 100
MouseClickDrag, left,  78,  118,  79,  119
Sleep, 100
WinWait, C:\WINDOWS\system32\cmd.exe, 
IfWinNotActive, C:\WINDOWS\system32\cmd.exe, , WinActivate, C:\WINDOWS\system32\cmd.exe, 
WinWaitActive, C:\WINDOWS\system32\cmd.exe, 
Sleep, 4000
goto start

 

Because it uses the "visible alien" button to center on the alien, this script will work on any save game which matches the description I gave above: The unit that makes the shot must be selected as soon as the game is loaded, with a loaded weapon in his right hand. He must be facing an alien that he is able to see. If those conditions are true, this script should work for you. Although you could just paste it into a file with an ".ahk" extension and run it right away, I do recommend following the tutorial so you get a feel as to how to create your own scripts.

 

I have spent very little time on AutoHotKey, but believe this script to be stable. Tonight I shall run a macro, and see how far it gets. With any luck, it'll still be going in the morning. The version shown above makes four shots per minute on my machine. That's 240 shots per hour, so when I check on it again in around eight hours, about 2000 shots should have been made (it must be true - Zombie does not sleep! ).

 

Finally, my logger does not cover every situation. It covers a lot of them, but not all of them. If it doesn't suit a certain test you want done, that doesn't mean you have to record results by hand - Ask for a program to fit your needs. I'm not the only programmer in the world, so there should always be someone around able to help you, but they won't if you don't ask. The worst that'll happen is that someone will say no.

[Zombie]

Thanks BB. I tried AutoIt with some success in the past, just not in conjunction with your logger. I'll give AutoHotKey a try to see how it fairs. Still, I'm not too fond of any kind of automated programs as trying to get them to work (and run stable over long periods of time) is a huge headache for me. By the time I figure it out (or ask someone to help) I could have had the darn trials finished by doing it pseudo-manually (the brute force over finesse idea). Hopefully your walkthrough will help in this matter, but I make no guarantees that my feeble brain can grasp the specifics.

 

I have spent very little time on AutoHotKey, but believe this script to be stable. Tonight I shall run a macro, and see how far it gets. With any luck, it'll still be going in the morning. The version shown above makes four shots per minute on my machine. That's 240 shots per hour, so when I check on it again in around eight hours, about 2000 shots should have been made (it must be true - Zombie does not sleep! ).

If I really book I can run between 6-7 shooting trials in a minute with your logger (I checked this out while doing the damage modifier tests). The actual sustainable rate I could manage is probably around 5 per minute depending how the scenario is setup. Of course, this neglects the necessary down-time (phone calls, eating, bathroom breaks, sleeping etc). Short-term I could beat automation, but in the long-run automated gathering wins as computers don't need to sleep.

 

- Zombie

[Bomb Bloke]

I found a couple of holes in my setup. If the alien returned fire and missed badly enough, the shot would fly all the way across the map, taking so long that the "abort" button would not get pushed. There was foliage behind the alien, so my misses didn't matter so much.

 

When I got up, I found that but a few minutes after I'd gone to bed, the script had hanged - One of the alien shots had made my unit unconcious, and the script of course ignored the "ok" button on the displayed dialog.

 

Hence I'd recommend a bit of tinkering with my map editer. Give the alien 0 TU, so that it can't return fire at all. Build a wall behind it, so that any misses won't travel too far. Give the soldier enough time units to fire one shot only, to be sure that's all it does in a sample.

[Zombie]

I was going to ask why you decided to shoot at an armed alien controlled unit with full TU instead of using a X-COM controlled alien.

 

Ideally, you want this unit to be selected as soon as the game is loaded. If he's the first unit in the unit table, this is impossible - That is to say, if you send only one unit into combat and save the game, when you reload, no unit will be selected at all! Hence I recommend sending only two units, and using the second one in your trials. This ensures the correct unit will be selected whenever the logger loads the game. Unsure as to which is the first unit in play? Load the game with my editer, select the guy you want to query, and when you quit you'll see his index. If that's unitref[0], he's at the top of the list.

One of my biggest pet-peeves in testing is trying to figure out who will be selected when you load a game. I usually lock out all the soldiers except for two and hope that the one holding the correct weapon was chosen. That doesn't always work though. So what is the deal? Is the soldier lower on the list in unitref going to be the selected unit? Please fill me in because this is a bit annoying at times.

 

- Zombie

[Bomb Bloke]

I didn't neuter the alien because I was lazy. I'll run another test tonight, but this time I'll follow my own advice, and up the game speed while I'm at it.

 

Unit selection is quite complex, I'm afraid. Whenever you select a unit, a bit flag in unitref gets set to 1. When you load the game in future, that unit typically won't be the first selected. This is why if you keep loading and saving over and over, it'll be a different unit each time, usually the next highest on the list. I believe ending the turn, or running through all units in this matter, resets the flags.

 

Once you run through the list, the game reverses direction and starts going back the other way. The order it runs through seems to be based on the location of the units on the map, which Mike pointed out to me yesterday.

 

Locked out units also seem to be excluded from selection, as you already know. I'm afraid this is all a bit vague, but so is my understanding of the matter.

 

It seems to be the case that locking out all the units except the one you want is the best method. If this results in no unit being selected, then your target must be the first on the list - Use my editer to clone him, then remove/delete the original. That should do the job.

[Bomb Bloke]

I modified the script and game settings to pull 6 trials per minute, and ran it overnight again. When I got up in the morning, I found it had simply stopped after ~2330 trials. I assume my virus scanner (which runs every day at 5am) slowed the system down and confused it.

 

I started it up again before going off to work, and came back to find my system had rebooted. Nevertheless, a total of 4390 runs were performed. My machine has been a little unstable since I swapped the motherboard, but I reseated the RAM and with any luck there won't be any more problems there.

 

Anyway! Might as well post the results. A standing soldier using snap shots with a laser rifle, hit a Floater at a distance of 15 tiles and one level lower, with 2857 out of 4390 shots.

 

The soldier had 99 points of firing accuracy, and the weapon reading suggested a 64% chance to hit. The actual percentage reported by the tests was just over 65%.

 

Note that even if the trials glitched, it was impossible for the success rate to be boosted incorrectly, as the soldier did not have enough TUs to fire more then once per run. Hence mis-trials could result in a lower success rate being reported, but not a higher one.

 

This is somewhat of a surprise to me. I expected the accuracy level to be quite different to that the game suggested. Now I have to try some tests with a partly obscured target to see if that has any effects.

[Zombie]

So what we have here is a complete agreement between experimental results and the base chance to hit calculation given by the game. Your values would also seem to indicate that distance does not play any role in the equation (15 tiles away should be far enough to see a significant reduction in hit accuracy).

 

- Zombie

[Bomb Bloke]

I was hoping for lower values. My result was ever so slightly higher then the game suggested, when all possible errors should only have brought it down.

[zaimoni]

You don't have to be logged in to download.

 

My guess is it's got something to do with Firefox's download "acceleration", which basically attempts to get maximum bandwidth off the server by opening multiple connections. My bet is the server didn't like this kind of flood. Dunno if Zombie's tweak will change that, or if you'll need to mess with your browser settings.

SeaMonkey is even more affected (some versions can't even save web pages reliably).

 

I generally use Opera when I have to download content onto the hard drive.

[Bomb Bloke]

Yet another logging program for you all to mess with.

 

This one is an accuracy tester, but instead of just checking whether the target was hit or not, it records where the bullet actually went and calculates the angle of fire.

 

It's modeled after the throwing logger I created a little while back. After extracting the archive to your game folder, run "bb_fire.bat" to start it up. You can modify the soldier's accuracy before you begin. CE users will need a split UFO executable, use this splitter if you don't already have one...

 

My modified desert terrain is used, same as with the throwing logger. The program automatically backs up the original tileset and restores it when you exit.

 

In order to record where the bullet ended up, you'll be required to save the game to slot 10 after each shot, then exit UFO. The logger backs up the original save game that was in this slot when you begun to the GAME_97 folder, and also restores this when you are finished.

 

Note that if you manage to make the logger terminate abnormally (say you had a power cut), the backups won't be restored. Make your own if you think you need to.

 

Output is the usual comma seperated data - First three values are the XYZ co-ords of where the bullet went. Next three are the co-ords relative to the unit that fired them. The next value is the angle of width (positive means the bullet drifted to the right, negative means to the left), and the final is the angle of height (positive means it drifted down, negative means it drifted up). A direct hit on the target will produce angles of 0 degrees, as the soldier is perfectly in line with the alien.

 

The results file if "firelog.txt", stored in the "bb_tact" folder.

 

Note that the angles recorded aren't precise. This is because multiple angles of fire can be used to hit any one tile (or the alien, for that matter). In theory with a big enough map you could get some spot on accurate values. Unfortunately UFO map sizes are limited, hence so is the ability to record these angles.

 

Also included in this pack is an AutoHotKey script file. To use it, just double click "bb_fire.ahk" before starting the logger itself. As soon as UFO starts up, the script will take over, firing the shots, saving the game, and repeating until you intervene by tapping "1" when the logger window appears. To kill the script once the logger has ceased work, right click the green "H" icon in your system tray, and select "Exit" off the context menu. (Don't try killing the script before the logger - The script will fight to the bitter end for control over your mouse!)

 

I had some trouble in that with the script running so fast, the logger would record results before the game had time to save them (due to the write back caching feature of Windows). This sometimes meant that the first result would be stored as a missfire. Missfires (which means the shot either wasn't made, or went right off the map) are recorded as landing on tile (0,0,0), so they're easy enough to spot in the results file and hence remove.

bb_fire.zip

[MikeTheRed]

Sounds GREAT, BB!

 

Unfortunately other things have come up so I hadn't even posted my results...

 

What I'm seeing is a "bugle shaped" function for mid-range final Firing Accuracy (let's call it FFA). Here it is for 45% FFA:

 

 Dist   PctHits
01	99.6%
02	80.2%
03	68.0%
05	58.6%
10	51.3%
20	44.2%
40	41.5%

N was 2000 shots or more for all points but D=1, which was 1000. (Why test it in depth if it's so clear?)

 

See how it is just about right, at Distance 15? I had been thinking maybe the programmers were quoting FFA for Distance 20... a reasonable average firing range for outdoors (but not indoors).

 

Given the bugle shape, I started thinking about two components to the equation: If you get a hit roll, it (almost?) always hits. But if you get a miss roll, it defines a cone radiating out from the shooter, sort of like the Line Of Sight cone, except that its "width" (actually the angle defining the cone) is defined by percent miss, being larger if there's a larger percent. Then on top of that, the alien is still in that cone, and if you're real close, they're taking up a very large percent of it. Is that clear as mud?

 

I did some crude attempts at modeling it, but I'm greatly hampered by two things: It's hard to be sure how wide the spread of misses is, especially when I have the speed jacked way up. Second, I don't know that the misses really are "random" (randomly spread throughout the entire arc of angle one can miss by)... if they are instead centered more on the center (where the alien is) as in real life, or conversely, are deliberately "supposed" to miss somehow, it would need a much more complex model. Although clearly "deliberate misses" is either not working, or very complicated, to produce what I saw.

 

This is why I hoped I could get a wall counter map from you, BB. It's not critical, since simple testing will still let one interpolate a graph and know how well most any FFA works. But it would be a lot more difficult to make an actual working/predictive equation without good data on just what's happening to the misses.

 

Based on that one set of data above, I found a pretty good fit if the target is 0.68 of his tile "wide", and each Distance adds half a tile to the "miss range" at the point where the alien is. (How many tiles off that hits might go, to the left or right.)

 

In case it's not clear, what my simple model is doing is basically considering the alien to be like a shooting-range target on a wall, and the "miss range" is how wide shots might possibly go, that hit the wall to either side of the target. In one sense, the "target and wall" are really only being modeled as a two-dimensional line where e.g. the alien occupies 68% of that line at Distance = 2. In other words, it does not take into account that bullets might e.g. whiz right below his crotch (whoa, betsy!) instead of hit him... there's absolutely no "3D alien representation" in my simple model. Still, I can tell you that you never hit the ground until you have some distance... maybe 10, certainly 20. BUT, conversely, the very few misses at distance 1 seemed to always hit the ground! (Put that in your conceptualization of how misses "work"!)

 

Anyway, on to an example: With 45% FFA, 55% of shots miss. At Distance 2, the "miss width" is 1.0 tiles (2x0.5). The alien occupies 0.68 of this, so 68% (.68/1.0) of the 55% "misses" also hit him. So .68x.55=37.4% additional hits, due to the "misses" actually "accidentally" hitting. 45% guaranteed + 37.4% accidental = 82.4% hits predicted by this approach, vs. the 80.2% seen.

 

I also played with the possibility that some of the 45% hits might actually miss, which was simulated by simply playing with the FFA after I set up the above model. I found that for FFA 39%, my little model fits very well (e.g. 80.5% at Distance 2). It does very well up close and far away, but is off in the worse case by -4.0% (model predicts 47.3%) in the mid-range (this worst case was Distance 10).

 

Also I tested the lowest FFA that ALWAYS hits, for a given distance. The thought was that it might help in a model I might build, if I could do all the "miss range" testing I wanted. So this is a "ceiling test" sort of like the psi testing where you're trying to find the value that no longer EVER misses. For each distance, I would work up from lower FFAs, going higher the instant I saw a miss, then test very heavily once I thought I found an FFA that never missed. For this, I used at least 1000 shots... if not one of them missed, yer pretty damn close, if not spot on.

 

I found - amusingly - that it's very constant. Dist 2 is FFA 100%, Dist 3 is 101%, and basically FFA increases by 1% for every 5 additional tiles away (e.g., Dist 40 needs 108%). BUT, Distance 1 (FFA 66%, N=3250) is INCREDIBLY fickle... there are very few misses from 45, where I started from, to 65. (It really po'd me... just when I thought I finally found it, there'd be another miss.)

 

Not sure what to do with this ceiling info yet... it's what I told you about, BB, that didn't need miss ranges, since it's just testing a ceiling. Anyway.

 

One other thing I've found: Only FFA matters, at least for weapon and soldier FA. I tried 40% weapon acc. and 250 soldier acc. (and vice versa), FFA 100%, at Distance 3, and both gave the exact same result: Extremely few misses, as expected for 100% at D=3. (The ceiling tests were done with simple 100% weapon and 100% soldier FA.)

 

It's better to use either very low or very hit expected percents for tests like this, because there is the least variability there... the greatest variance is at the 50% point with binomial (hit or no hit) data. If the results had bee, say, 45% hits for 40/250 (weapon/soldier FA) and 55% for 250/40, you'd be scratching your head wondering if weapon FA mattered more... or was it just chance?

 

I use DOS X-COM, although I have WinCE. I have yet to have luck getting the WinCE version to work, but I'll give it another try. Interesting how you had to drag the mouse in WinCE... I could never get AutoHotKey to work with the DOS version, probably because the DosBox wrapper just utterly mucked everything up. I had tried to do AHK with WinCE myself, but could never get WinCE to work right... the versions folks gave me were all messed up by XcomUtil or something... anyway.

 

DosBox lets you increase the speed of whatever is running in it, and the game itself has a firing speed control. The DosBox speed lets you play the game at many, many multiples of its usual speed. For close range shooting, I can get off 1000 shots in about 5 minutes, but it's significantly longer at longer range, especially if the game has to draw multiple screens for each flying bullet.

 

With the speed cranked like this, it's hard to see where misses go.

 

Hopefully I'll have some time to try your automated thing, BB. I guess you can't do the numbered walls, eh? Does your Bullet Logger work with DOS XCOM? (And/or its AHK macro?)

[Bomb Bloke]

Given the bugle shape, I started thinking about two components to the equation: If you get a hit roll, it (almost?) always hits. But if you get a miss roll, it defines a cone radiating out from the shooter, sort of like the Line Of Sight cone, except that its "width" (actually the angle defining the cone) is defined by percent miss, being larger if there's a larger percent. Then on top of that, the alien is still in that cone, and if you're real close, they're taking up a very large percent of it. Is that clear as mud?

Yeah, except I always considered the cone rule to be in effect all the time- No "hit" or "miss" rolls, the game just comes up with some random angle of fire based on your accuracy, and if you're lucky, it hits. The range of the angles decrease as accuracy increases, meaning that more angles within the set will reach the target.

 

For example, I had one rather poor soldier fire an auto shot at an alien. The first shot was fired (missed), the soldier turned away from the alien before firing the second shot (which also missed), and then turned back before firing the third (which missed as well).

 

A veteran soldier never fires shots on that large an angle, and so is more likely to hit his target...

 

I've never believed that the displayed firing accuracy directly relates to your chance to hit, due to the large amount of extra factors - Obstacles between you, distance, and the size of your target.

 

In other words, it does not take into account that bullets might e.g. whiz right below his crotch (whoa, betsy!) instead of hit him... there's absolutely no "3D alien representation" in my simple model. Still, I can tell you that you never hit the ground until you have some distance... maybe 10, certainly 20. BUT, conversely, the very few misses at distance 1 seemed to always hit the ground! (Put that in your conceptualization of how misses "work"!)

The 3D shape of a given unit is as yet undetermined, but my bet is it's something simple such as a tube. You either go around, over, or under it.

 

I know that the shorter a unit is, the more likely a ground shot becomes. This is because you're aiming down. And the closer the short target is to you, the lower you must aim to hit it's center of mass - Making ground shots still more likely. I dunno what you were aiming at, but an X-Com soldier is slightly taller then many alien types.

 

On the other hand, as distance increases, chance to hit decreases, meaning lower shots are more likely to miss and go on to hit the ground. Hence the chance is lowest at some middle distance point.

 

Hopefully I'll have some time to try your automated thing, BB. I guess you can't do the numbered walls, eh? Does your Bullet Logger work with DOS XCOM? (And/or its AHK macro?)

Again, the numbered walls couldn't be used to accurately record how many hits were made against them - Only how much damage was dealt.

 

The logger works with either version of UFO, but the AutoHotKey script is CE only. I'm afraid my machine doesn't seem interested in running the Dos version, so I can't create an alternative, but there's plenty of info in this thread as to how you can do it yourself.

[zaimoni]

.....

Yeah, except I always considered the cone rule to be in effect all the time- No "hit" or "miss" rolls, the game just comes up with some random angle of fire based on your accuracy, and if you're lucky, it hits. The range of the angles decrease as accuracy increases, meaning that more angles within the set will reach the target.

Or angles. If the misses really were generated physically, the empirical choice of "pair of deviation angles" would be altitude-azimuth (a horizontal angle deviation, and a vertical angle deviation).

 

Spherical coordinates on the bearing (phi-theta) would also be tempting, but that's not what happens with real firearms.

 

....

The 3D shape of a given unit is as yet undetermined, but my bet is it's something simple such as a tube. You either go around, over, or under it.

Or through it. Floaters have a narrower collision model than their graphics intimate.

 

Shots do go between the legs of unarmored X-COM units harmlessly, so their collision model isn't a simple tube.

[MikeTheRed]

Greetings, BB... Hi Zaimoni! ltnt...

 

Right, it's clear that the final Firing Accuracy (FFA a.k.a. what you see on the weapon-firing popup) can't possibly relate to one's actual intended shot. After all, you might have several aliens (or none!) that you might shoot; some near, some far, some half blocked. FFA would have to deliver its estimate after you selected a target, to be target-specific. It has to be some sort of general or average estimate. My current guess is that it's for distance 20 on a clear outdoor shot at an "average size" alien, or something.

 

FWIW, all my numbers are vs. Mutons.

 

Unless I'm misunderstanding you BB, accuracy being determined by a simple angle width can't be the case. Look at how my data levels off by about D=20. If one has a simple cone (or 2D angle in a plane or whatever), there would be no levelling off... there would be a continued dropping to almost nothing at great distances (D=40). This would probably be a linear drop in a linear model (which it probably isn't) or a faster drop when including the vertical dimension, although I doubt it uses a true 3D conic model, seeing as how I didn't see many ground hits unless I got real far (I can't remember if they started hitting the ground at distance 10 or 20).

 

Zaimoni, maybe you have some insights here relative to when they might hit the wall and/or how hits would drop off in a very simple angle model (vs. distance). Reference my earlier "linear" (i.e., 2D in the plane of the target and shooter - both were on the ground) estimates of how much I missed by, versus distance, if it helps. My impression was about 0.5 tile width's miss for every tile of distance; for example, at distance 6 it was my impression that shots were spraying an area of "wall" (if the alien is a target on a shooting range wall, at his point) of 3 tiles wide. This 0.5 estimate is what it looked like in the game (I tried to guestimate it at each Distance, then drew a line), but it's an awful rough guess given how fast the bullets move. My best fit was to consider the alien 0.68 tiles wide, and, again, it's a simple planar model. If you know what I mean.

 

Ultimately, the target (however its size is defined) is not changing, as my shooter moves away. His size remains absolute, and thus drops as a percentage vs. "all available shot space", including misses. What exactly the means in "real" X-COM, though, who knows, at this point.

 

Anyway, my "guaranteed" plus "accidental" hits model seems to do quite well, if I played with the numbers a little. It's also important to point out that it is not a 3D model, whereas X-COM apparently does include the third dimension.

 

Let me know if I'm not understanding you right, pls!

 

Another couple of sets of FFA vs. distance data could help elucidate it a lot... I'm probably either very close, or it was an entirely lucky coincidence that I could match observation to concept that well. Another set or two of other FFAs vs. distance would probably quickly show which was the case.

 

FWIW if you extend my model (a curve fitting the data I showed) to infinity, that's where the 39% guaranteed hits come in, for a FFA 45% soldier. With that best-fit model.

 

I find it extremely odd that a soldier turned right in the middle of an Autoburst. (I can't recall it happenning, but could've simply missed it.) Still, I'm not sure what implications (if any) it has for one model versus the other. Either way, they could've figured where the shot went (or what angle its going off in), then turn(ed) the soldier to face it. Sound reasonable?

 

Yay! I finally got CE to work (fingers crossed). That's the good news...

 

I tried to get your logger to work in CE (and split the EXE) but got the error message, "can't find xcloader". So I rewrote your batch to point to mine, ldr_XCOM1.exe. (I can't remember where/who I got this CE from.) Then, at the line it tries to run ldr_XCOM1, it gives the error "Couldn't CreateProcess".

 

May I borrow your loader, sir?

 

I also tried it with the DOS version. But here it's pointing directly at the XCOM executable, which gives very odd results on my PC (that's why I got DosBox)... the game only seems to accept some mouse clicks (probably b/c the machine is way faster than intended), then takes a while to respond. (It took a half a minute to get the firing popup, b/c you have to wait and don't know if it got the input.) It makes it slow plus frustrating to try to do anything. Finally, it crashed when I lifted off. However, I did get the following Firelog.txt:

 

7,47,3,-17,2,1,-83.25665282,26.55436324

7,47,3,-17,2,1,-83.25665282,26.55436324

 

It sounds like real data, if I'm reading your explanation correctly. Although I don't know why I got it twice; it was only one test.

 

If your loader works for me, that may be the simplest way to resolve it. And if Firelog + CE will then work, I can take a whack at AHK, too. If it all works great, there shouldn't be any need for the numbered walls... if I understand Firelog correctly, it's giving incredibly more-accurate data than any "damaged wall averages" might provide.

 

Another thing is that although the logger sounds like it's not real fast (vs. up to 1k shots in 5 minutes for my manual DosBox testing), I don't think a lot of testing will be needed to get the general idea of how misses work. However, it may take someone like Zaimoni to translate the Firelog data conceptually into "if this alien was a target on a firing range wall, what would the wall (i.e., the misses) look like 'around' the target?" Eh (shrugs), I'm brand new to Firelog... what do I know at this point.

 

BTW how the HECK did you get the firing data? It sounds like you must have a TSR reading code as it's being processed? Or?? It sounds rather amazing to me!

 

Zaimoni, thanks for bringing your set of math skills to the table. Now I see better how trigonometry enters into firing. Can I ask - somebody's absolutely sure they saw a shot go through a soldier's legs?

[Bomb Bloke]

Or angles. If the misses really were generated physically, the empirical choice of "pair of deviation angles" would be altitude-azimuth (a horizontal angle deviation, and a vertical angle deviation).

 

Yes, exactly. At least, that's what I was thinking when I crafted this latest logger, which records those two angles. It's the simplist way of programming it - Sure, you can pick a point where the bullet will go, then calculate the angles between it and the shooter, but how did you know that point was legal without first calculating the angles? You didn't. Hence, I assume they calculated the two angles (based on the angles between the shooter/shootee, with some randomness thrown in by the accuracy percentage), allowed the bullet to travel along them, and waited for it to hit something. No "predetermined targets".

 

The 2880 units to the circle rule you found plays a big part in how precise the game can be, but unfortunately I can't think of a way to record results precise enough to match to a formula involving those values. The game just doesn't save them to disk.

 

The exact place a bullet lands must be stored in memory at some point, though, right down the the LOFTemps element that got hit. A memory monitoring tool should in theory be able to find the relevent offsets, but I have little experiance with such things, hence it'd take me a while to get anything useful out of one.

 

On the other hand, I'm pretty sure I've never seen a shot go between a units legs... But, if it's true, then it means that most likely UnitRef truly does hold LOFTemps maps. Hmm...

[zaimoni]

On the other hand, I'm pretty sure I've never seen a shot go between a units legs... But, if it's true, then it means that most likely UnitRef truly does hold LOFTemps maps. Hmm...

I have, but it was something like DOS V1.2 (whatever was extant in 1995). All that's really required is for the unit type to index LOFTEMPS data.

 

Trivium: at 49 squares range (maximum non-diagonal range on a 50x50 map), the floating-point error from missing by 0.125 degrees is between 1/9th and 1/10th of a square. I'm not sure how that will work under integer math.

[Bomb Bloke]

We know UFO uses integers whenever possible, but that doesn't mean they are used exclusively. Integers just take up less memory is all, so the other data types would only be used when required.

 

As a general rule, if you perform mathematical operations on integers, the result returned will be an integer (the answer will be rounded if required).

[MikeTheRed]

There's a clear place where a simple approach is not used: manufacturing timing. I tested an important point here (fifth bullet), and found no simple integer rounding. It would've made a big difference. I bet there are many other instances. A few savegame variables are stored as two byte values, as well, although it's not always clear why. FWIW results returned as integers usually result in truncation, not rounding, at least for X-COM IIRC. For a recently-found instance, see this.

[zaimoni]

List of questions....

* Do we have a divide-by-zero error (or other weirdness) at FFA 0?

* How wide is the cone at FFA 0? (or 1, if 0 divides-by-zero)

* The 45 degree horiontal angle error point would also be interesting. I'm thinking it's somewhere around 20 FFA, but would like a more explicit calibration.

* Is the shape of the "cone"'s base rectangular, or elliptical? What kind of distribution do the error angles have (uniform, bell curve? can we pin down the bell curve?) If ellipitcal, are we using phi-theta from spherical coordinates after all?

 

Assuming that we have a two-angle model (horizontal and vertical error), I'm inclined to think of FFA as a divisor. That is, doubling the FFA should halve each of the horizontal and vertical errors.

[MikeTheRed]

Huh, interesting question, Zai... FFA 0% could also tease out the "miss silhoutte", if X-COM does use a simple guaranteed-vs-accidental hits model...

 

I took it for a quick whirl, by setting Soldier FA to 0, and they had FFA 0%. It did "work" (they did shoot)... here are results with 4 soldiers, where each soldier made 250 shots. Hits are from Unitref[81]...

 

 Dist   Hits	%Hits   %Misses
  1	232	92.8%	 7.2%
  2	146	58.4%	41.6%
  5	 68	27.2%	72.8%
 20	 12	 4.8%	95.2%

 

Unlike in the past (FFA 45%), misses clearly hit the ground close up, even at Distance 2. Not a majority, but certainly a significant fraction. At 45%, one had to be at Dist 10 or 20.

 

BB - this is the kind of result I would expect for the model you originally suggested (i.e., without a "guaranteed hit" component to the model). If I was understanding you correctly.

 

At Distance 20 with FFA 0, the farthest afield that I saw shots go, was approx. 6 tiles to the side of the target, at the Distance of the target (ie, if he were on a "firing range wall"). Compare how with FFA 45, they were about 5 afield (radius; "diameter" 10). I would think that this puts significant constraints on the maximum possible miss angle. However, my Mk. I eyeball measures are not very reliable... bullets whiz by really fast when I've cranked up the DOS speed. I hope to get BB's firing logger up and running soon.

 

It looks like there are a lot of questions about where the misses are going. Zai, if you get a chance to turn BB's fire logger output into a "projection" that'd be greatly. Namely, if the alien were a target on a firing range wall, where did misses hit the wall, relative to him? Something in Excel would be preferred by me. The user could enter the distance to the target... if I'm understanding BB's output correctly, it doesn't include this.

 

In truth, I'm not sure how much this would be a simple curiousity, and how much it might actually be useful to figuring out what's going on. Probably the angles of fire are the most important data. Anyway.

 

BB, can you send me your loader? Also it's occuring to meet that it might be useful if your Fire Logger output absolute coordinates of shooter and target, as well as Unitref[81] - IE, whether the shot registered as a hit. It could be very informative to see whether a shot always and only hits if the angle of fire is exactly 0,0 .

[Bomb Bloke]

Whoops, sorry, I somehow managed to completely miss your previous post requesting the loaders.

 

The results include the exact location on the map where the bullet landed. If this equals the location of the alien (24/24/2 or something similar), you know it was a direct hit. You can't hit the wall or floor in that position of the map, as there is none. The alien is floating in the air, so if the bullet is recorded as landing in that area, you know it was hit (there aren't any walls or ground tiles in that square).

 

Yep, the logger uses UnitRef[81] to see if the alien was struck. If the alien did not get hit, the map data is compared to see which tile of the map the bullet ended up in.

 

The soldier is at position 24/49/2, if memory serves. Moving the units around isn't advised, the logger is hard coded to calculate the angles based on these positions.

 

Keep in mind that this logger doesn't read memory at run time. It merely grabs what information is available in save files, namely, the location of what got hit - But not where that object was hit.

 

You see, there are multiple angles that can hit any given tile on the map. The logger is bright enough to spot that the tile got hit, and works out the direct angle between it and the soldier. However, it can't spot the exact angle that the bullet actually followed - Hence all results are approximations. You can easily see how many times a given tile was struck, but not how many different angles led to there.

 

For example, if the shot manages to miss the alien, but still hits the wall directly behind it (that being 24/0/2), the logger will give angles of 0/0. However, it's highely unlikely that this will be precise. Likewise, all hits against the alien will register as hitting the same tile, at the same angle, even though multiple angles of fire can and will occur in reality.

[MikeTheRed]

Got it, BB - it seems to be working now, with those loaders. GREAT! Next up will be to get AHK working with it...

 

I'm seeing an odd result; here's FIRELOG after a number of shots, with Accuracy set to 1 (=Snap FFA 0):

 

0,0,0,-24,49,-2,-26.08492469,-2.33636548

0,0,0,-24,49,-2,-26.08492469,-2.33636548

0,0,0,-24,49,-2,-26.08492469,-2.33636548

7,47,3,-17,2,1,-83.25665282,26.55436324

0,0,0,-24,49,-2,-26.08492469,-2.33636548

0,0,0,-24,49,-2,-26.08492469,-2.33636548

0,0,0,-24,49,-2,-26.08492469,-2.33636548

 

That odd one in the middle hit the "floor" of the map. The other 6 either hit the target, or went off into "space" to the left of the floater. I'm saving to Slot 10 each turn. Am I doing something wrong?

 

Otherwise... I understand better now, what the logger is doing. Thanks for the explanation. You must be looking for damaged tiles in the savegame, right? Will it also catch damaged walls? And what if it flies into space (left or up)?

 

Thanks again! - Mike

[Bomb Bloke]

Yeah, it consider walls to just be a different type of tile.

 

Most of those results you have there are what I'd expect to see if the shot went right off the map. But the only way that should happen is if the bullet goes up too high - I couldn't be bothered adding a roof to the map.

 

Send me some of those save games if you continue to have trouble. As far as AutoHotKey is concerned, all you need to do is install it, then activate the included script prior to starting the logger.

[zaimoni]

In principle, we could map each tile hit to a frustrum [set of space angles]. Note that when designing a test map, windows are useful (because shots go through them some of the time). Fences, less so.

[MikeTheRed]

BB, when I run your fire-logging scenario, both the alien and the soldier are at the "bottom" of the map. So any misses to the "left" disappear off the map.

 

Also, in the 7 datapoints above, about half of the 6 repeated ones hit the alien, and the other half disappeared off to the left. I thought hits were supposed to say 0,0?

 

I am confused Both of this things sound wrong relative to what you've been saying.

 

I have emailed you a game I saved while your scenario was up. Let me know if you want any other files.

 

Thanks if you can help!