Damage Modifiers for Aliens

[Bomb Bloke]

Sometimes (I'd guess about 1 in 6) when I click the "Alien Turn" button, the screen will go black with an error window, saying UFO has caused an error *yada yada yada*, would you like to send this information to microsoft *yada yada yada*...

 

If I click 'No', it will simply open the logger window, asking to Continue or Ctl+C, and if I continue, it goes back into UFO as if nothing had happened...

 

Hmm. That's an odd way of error handling...

 

I don't see why that error turns up at all... The file which crashes is a direct copy of the one I use on my machine. But, given the way we used to 'install' it, perhaps there's some difference between the rest of your game data and mine?

 

Dunno.

 

While you should be able to cycle between alien and xcom turns without trouble, I didn't really plan on people doing that with this logger. Of course, the logger doesn't run when the game does, so that shouldn't cause error messages.

[MikeTheRed]

What is this "logger", anyway? Got a post or something that describes it?

[Danial]

It simpy loads a savegame, and you do your "test" and click 'Abort'. It then logs most of the unitref offsets into separate TXT files. You can then go back into your save and "test" again, and it adds to the text files each time. You can then import the files into excel or whatever and correlate the data. It's pretty cool

[MikeTheRed]

So where is this fine piece of software? Enquiring minds want to know, BB!

[Zombie]

Here, I grabbed this from my personal archive.

 

bb_log.zip

You need Sun's JAVA to run it.

 

Don't want to have JAVA on your computer? I could be persuaded to put an old copy here too.

 

old_bb_logger.zip

 

[Edit: Both attachments are BB's loggers by the way. *hint, hint*]

 

- Zombie

[Stun Grenade]

By the sounds of things... BB's products arn't stable. I tried his map viewer and wouldnt start.

 

Kidding BB

[MikeTheRed]

Thanks for the zips, Z... heh Stun I know BB, he made an excellent little applet for his great numerical tileset... just gotta know which setting means you're totally f*d, hehe...

 

No instructions for that logger, Z? Maybe we'll wait til the great BB hisself shows up. Hope he's not away for a long weekend. Folks who know XCOM real well are often going on vacations paid by corporations with deep pockets. We hope.

[Bomb Bloke]

No, actually I'm off work this weekend due to a cold - And I don't get paid for it, either.

 

Most of the software I write these days is written in Java, unless I want to spit out something simple very quickly, in which case I go for QBasic. Although I write my code under an older Java SDK, that doesn't mean you need to use an old Java VM to make it work.

 

QBasic is a lot more capable of crashing a computer then Java is (because the DOS VM, for some reason, gives you enough power to use RAM at will - which upsets Windows if it thought it was using it for something else), but for some reason, I have more trouble with Java.

 

For some reason, my map editer crashes SG's computer... He says it entirely locks it up, to the extent that he has to reboot. I can't reproduce the problem on any machine I've come across.

 

Getting Java programs to run at all on Danial's computer was a headache, due to his OS refusing to run Java programs unless you ran a command to say 'look in the current directory for class files' before RUNNING said class files... Even typing in absolute paths to the files in concern wouldn't do the job! Stupid Windows...

 

Now he finds the logger is crashing... Well, as I pointed out, it's not actually the logger that's crashing, but one of the split EXE files XcomUtil creates when you install it on the CE version of UFO - Still bad PR, though.

 

Of course, those are the only two programs I've got floating around that don't really count as 'finished'... I think.

 

The only real install guide I wrote for the logging program was sent as an email to Zombie when I first wrote the thing. The program has since then evolved into something a bit simpler to upgrade.

 

In it's current state, it only works on the CE version of the game, which I gather you don't have, Mike... It'd take me about half an hour to create some new batch files that will work on either version of the game, but by then it will be morning, so you'll have to wait a while.

 

You won't be able to run it through DosBox, either, but the tactical game engine runs well enough under Windows, so that shouldn't be so much of a problem.

 

I'll polish it up, write an install/usage guide, and dump it in the Files section.

[Zombie]

The only real install guide I wrote for the logging program was sent as an email to Zombie when I first wrote the thing. The program has since then evolved into something a bit simpler to upgrade.

The install guide was actually included with your original logger as a readme file. I have it for anyone interested, but the first logger only saved health values so the install guide only partially applies to the subsequent revisions which log multiple stats. Guess we'll just wait till version 4 comes out. Yet another logger to add to my archive!

 

----------

 

I suppose it's time to get back on task. I just finished testing out the damage inflicted by the Reaper. The reason why it took so long was because I had to run only one trial at a time. Multiple "roars" might cover up the fact that one Reaper didn't attack. Yeah, the attack was normally immediate, but every once and a while it took 10 turns for the Reaper to muster the courage necessary to attack.

 

So to make sure we understand things, 250 trials were run on the Reaper. When I looked at the data, I was confused. Then I figured out why the damages were not in agreement with the OSG: I was using an unarmored soldier which takes 1.2x listed. To make a long story short, after factoring in the damage modifier, everything checks out! Me thinks I will try a soldier wearing a suit of armor next to see if that agrees. It should, since the modifier is 1, but I'll have to edit armor strength to 0 for my tests.

 

- Zombie

[Danial]

So the Reaper did 0-180 damage then? Do you know if it increases with Strength per skill level?

[Zombie]

You are correct on both accounts, Danial.

 

Actually, I didn't test on Beginner skill level. I wanted a challenge so I found a Genius level Reaper on a terror site. So damage follows the strength rating of the creature at that level. The damage range is between 0 and 2*Strength, just like we thought. Gotta love it when a theory holds.

 

Oh, here is something funny: the darn Reaper was missing attacks. Yep, I forgot that HTH accuracy was less than 100 at Genius. That kinda messed up my results a bit by adding extra zero damage hits. Luckily I realized this and took HTH accuracy into consideration. For my next test I'm changing melee accuracy to 100%. I really hate testing with multiple variables.

 

- Zombie

[NKF]

Zombie, I've been meaning to ask, since you're doing melee tests at the moment:

 

You gave some melee costs for the aliens a while back, such as a Chryssalid using 15 TUs for an attack. Do you know if these were fixed costs or percentage costs?

 

- NKF

[Zombie]

Thanks for reminding me, NKF!

 

I just nabbed a Beginner level Reaper and edited current/max TU to 14. Just like at Genius level, the Reaper didn't want to attack. When I edited current/max TU to 15, the Reaper was more than happy to gnaw at my soldier. Since the Reaper has different TU for the different skill levels, the HTH attack is a fixed cost. To verify, a Genius level Chryssalid was edited to 14 and then 15 TU. It only attacked at 15.

 

I'm not sure how to get aliens to stand still (rooted to one spot) like you do NKF. I'm assuming I should set unitref[035] to 0, but what about current/max energy? Does that play a role? Anyways, it's lucky I didn't root that Reaper to one spot. For the first round it decided to use its 15 TU ro run away and charge back. This left the 2x2 Reaper facing my soldier on a diagonal. *Roar* Reapers can attack on a diagonal too!

 

- Zombie

[NKF]

I root aliens to one spot by setting their current energy to 0 and their energy recharge to 0.

 

As long as the energy recharge is set to 0 and the alien uses up all its energy, it will no longer be able to walk to other tiles.

 

- NKF

[Bomb Bloke]

I suppose you could also use that to prevent aliens from turning?

 

The logger is now in the downloads department.

[Danial]

Actually, I didn't test on Beginner skill level. I wanted a challenge so I found a Genius level Reaper on a terror site. So damage follows the strength rating of the creature at that level. The damage range is between 0 and 2*Strength, just like we thought. Gotta love it when a theory holds.

Sure do!

 

Oh, here is something funny: the darn Reaper was missing attacks. Yep, I forgot that HTH accuracy was less than 100 at Genius. That kinda messed up my results a bit by adding extra zero damage hits. Luckily I realized this and took HTH accuracy into consideration. For my next test I'm changing melee accuracy to 100%. I really hate testing with multiple variables. 

Is it true that HTH Accuracy for Terrorists is fixed at 80%? And that it doesn't increase with skill level?

[Zombie]

Thanks for the help NKF, and for the new logger Bomb Bloke! You two are top-notch!

 

Danial: Let me be perfectly clear here. HTH accuracy is NOT a fixed stat. No sir. It goes up as skill level increases. So just ignore what the OSG mentions for the higher skill levels. It's wrong yet again. See why it's important to test stuff like this?

 

----------

 

Okay, I have a special treat for everyone: I just tested how many TU are necessary for the aliens to use their psionic attack one time. What did I say it was before, 22? Wrong. It takes 26 TU. Here again, its a fixed stat. Guess I made some more work for myself in the wiki.

 

- Zombie

[MikeTheRed]

I've been a bit busy lately... great stuff here, though!

 

Thanks for the update on the logger, BB. I took a look at it... looks great. Fwiw, I've already been directly sucking data out of Unitref and Soldier into Access. This was crucial to my experience work. Speaking of which, your ReadMe said suggestions are welcomed... you might want to put Unitref experience counters in there. These are important for telling how many hits actually landed (even if no damage resulted), etc. For the Psi counters, users need to know that failed psi attempts add 1, but successful ones add 3, to the counter. You can always back-calculate number of successes and failures since you'll know how many attempts you made.

 

Anyway, just a suggestion. And you don't need to do it for me. But others may like it. In addition to the experience work, they showed me that e.g. occasionally you get an extra reaction count, and that prox grenades credit hits to the person that set the prox mine off, not the person that threw the grenade.

 

NKF and others - a very minor point re: rooting aliens - be careful of rooting them on an elevator. Elevators don't require energy to move up and down. You'll never guess how I got reminded of this point.

 

Zombie (or anyone), I am modelling the number of hits needed to kill critters and would like to make sure I understand things correctly. Mind if I ask some questions here?

 

1) You will recall there were some apparent simple errors in the OSG (aka Aztec's spreadsheet) vs. what was found in Geoscape.exe (and Xcomutil.cfg). Would you be able to check the items in "Bytes that are always different" here to confirm that OSG is wrong and Geo is right? Or, like you said, should I simply go with Geo, eh?

 

2) Likewise, for the second bullet under "Systematic Differences" there - was OSG also incorrect across the board for Celatid and Chryssalid, Firing Accuracy and Armor? (OSG got the 2x increase backward?) Again - go with Geo?

 

3) OSG has zombies, but Geo does not. If you have confirmed any one level's stats for zombies, the rest can be extrapolated.

 

4) I see you folks have been talking about Damage Modifiers some. Are they all up to date on the wiki?

 

5) In your damage analysis here, you talk about "order of computations". It seems to me though that the bottom line for being accurate is not the order per se (min before max before average), but the observation that Integer rounding occurs separately for the modifier. Would this be a correct conclusion?

 

6) Along these lines, I'm not sure why you broke out the range from the average. Can't the average be stated as simply (Min+Max)/2? This accurately produces the average of 9 to 29 inclusive, 19.0. (Why do you say 19.5? Did your test results indeed have this average?)

 

Thanks greatly for your help if you (or anyone) can address the above... before I go crunching tons of numbers.

 

Fortunately for my modelling, target Health does not change across difficulty levels, and armor only changes once. I know I'll model vs. HE, but not sure what else to model... maybe a select few weapons, like standard pistol, laser pistol, heavy plasma.

 

The weak ones were specifically chosen because they're the reason I'm doing this - to see which approaches to damage let you hit a target the most before killing it. In particular, standard pistol vs. edge of standard grenade blast.

 

But now that it's set up, I can throw in whatever else folks would like to see. Any other particularly popular weapons? Maybe laser rifles?

 

I probably haven't made it clear - I've set up a model that does trials of, shooting a target with a particular weapon. It includes armor and health being shot away (or not) with each hit. So it needs to handle min and max damage and modifiers correctly. It also includes a choice to always hit one side of armor (e.g. front), or to always target the highest armor side, out of whatever is left (a.k.a. continuously turning the alien for each shot, to kill as slowly as possible and maximize experience). Then I see how many hits are needed to kill. Run it a million times, and take the average.

 

MTR

[Danial]

Can't you calculate that data from the damage formula?

 

Seeing as Health always stays the same, and we know the Modifiers, and that weapons do 0-200% damage, Armour is really the only variable.

 

I mean, if you use the formula, can't you calculate that a Pistol will kill a Beginner Muton in:

 

Min. Hits To Kill = 125HP / ((26 x 2 × 0.6) - 10) = 6 shots

 

Maximum shots would be impossible to know because you might get several 0 damage hits in, and Average shots should just be the above formula without the 2 in the middle, so 23 in this case.

[MikeTheRed]

True, it's something like that. But notice how e.g. your minimum hits - the simplest possible case - doesn't include the effect of armor "eroding". The minimum for pistol killing a Muton is actually 5. (Armor gets eroded.)

 

This is especially important with the weakest weapons (and/or high armor), where armor blockage can be very significant. Silacoids have armor of 25 (at Beginner), equal to half a pistol's damage. Using an "average" would make weird results. Same holds for a grenade at its edge vs. a Muton; average HE is 10, same as Muton armor at Beginner. These are just the kind of cases I'm most interested in - where the inevitable might be delayed as long as possible.

 

Also formulas won't accurately model the possibility of trying to hit different sides of the target or the more realistic likelihood that probably a couple of sides will be hit, for the most part. Again it can be estimated with a formula, but real life might be weird, especially when armor and hit strength are close.

 

I originally did try a formula but after attempting to grapple with armor erosion etc. I thought, "wth, I'll just model it".

 

My trials also are just an estimate - but they are considerably less error prone in the most interesting cases. And a much closer estimate of the real value, in any event.

 

Anyone care to try a formula for the average number of hits to kill a muton with pistol, or grenade at its edge (average HE=10)? Then I'll compare my findings with ya

 

MTR

[Zombie]

1) You will recall there were some apparent simple errors in the OSG (aka Aztec's spreadsheet) vs. what was found in Geoscape.exe (and Xcomutil.cfg). Would you be able to check the items in "Bytes that are always different" here to confirm that OSG is wrong and Geo is right? Or, like you said, should I simply go with Geo, eh?

 

2) Likewise, for the second bullet under "Systematic Differences" there - was OSG also incorrect across the board for Celatid and Chryssalid, Firing Accuracy and Armor? (OSG got the 2x increase backward?) Again - go with Geo?

Where do I begin? First, I'd go with the geoscape files instead of using the OSG. (Aztec's spreadsheet is nothing more than blatant plagiarism of the OSG and has the same data). However, until I can verify what my geoscape.exe stats say, I can't comment much on this (see my email, Mike).

 

3) OSG has zombies, but Geo does not. If you have confirmed any one level's stats for zombies, the rest can be extrapolated.

Geoscape.exe may not have Zombies listed simply because they are technically not an alien. Zombies are produced only in the Battlescape via a successful Chryssalid impregnation, and thus, a Geoscape entry may not be used. It is possible that the tactical.exe might have this info instead. (Tactical.exe and Geoscape.exe are the files split off by Xcomutil from the main UFO Defense.exe). From my research into zombies, all their stats are a constant when going to a different skill level.

 

4) I see you folks have been talking about Damage Modifiers some. Are they all up to date on the wiki?

So far, yes. All the verified modifiers are up-to-date. I will periodically go through that section of the Wiki as more info is gathered.

 

5) In your damage analysis here, you talk about "order of computations". It seems to me though that the bottom line for being accurate is not the order per se (min before max before average), but the observation that Integer rounding occurs separately for the modifier. Would this be a correct conclusion?

If I understand you correctly, yes. There is nothing which would say that the game does the Min calculation first, the Max calculation second, etc (the average is a different animal, see below). The point is this: The susceptibility factor is not introduced until after the preliminary Min and Max have been calculated:

 

Preconditions:

Any unit which has a susceptibility to HE of 80%

HE shell modified to dish out a listed damage of 25

 

Example 1:

Calculate Min and Max of the HE-25 shell assuming the damage modifier is applied first.

 

Modified Listed Damage = 25 * 80 / 100 = 20

 

Min = INT(MLD/2) = INT(20/2) = INT(10) = 10.

Max = INT(MLD*3/2) = INT(20*3/2) = INT(30) = 30

 

Conclusion - this method is incorrect since the actual range is between 9 and 29.

 

----------

 

Example 2:

Calculate Min and Max of the HE-25 shell assuming the damage modifier is applied last.

 

N = Listed Damage (in this case it is 25)

S = Susceptibility to HE ammo (in this case it is 80)

 

Min[1] = INT(N/2) = INT(25/2) = INT(12.5) = 12

Modified Min = INT(Min[1] * S / 100) = INT(12 * 80 / 100) = INT(9.6) = 9

 

Max[2] = INT(N*3/2) = INT(25*3/2) = INT(37.5) = 37

Modified Max = INT(Max[1] * S / 100) = INT(37 * 80 / 100) = INT(29.6) = 29

 

Conclusion - this method is correct since it matches observed results.

I hope this clears up any questions.

 

6) Along these lines, I'm not sure why you broke out the range from the average. Can't the average be stated as simply (Min+Max)/2? This accurately produces the average of 9 to 29 inclusive, 19.0. (Why do you say 19.5? Did your test results indeed have this average?)

Theoretically, the modified average might not even be used but I included the calculation to show what it would be. Indeed, the anticipated Average should simply be (Min+Max)/2. However, the average that I witnessed was 19.649 (Total damage sum of 20376/1037 trials). From this, I tried to formulate a better way to explain the disparity.

 

19.5 seemed like the better choice. Why? In all my trials, the Actual average was almost spot-on the Anticipated. And with some large damage ranges (like the Laser-50 vs Quarterpod) that difference was only 0.383. With a tiny range of 9 to 29 (21 values), that average should be much closer. Still, it may just be a fluke where the random numbers generated were higher than expected. One thing is for certain, the Anticipated average cannot be calculated directly using just the damage modifier and the listed damage:

 

Example:

 

Listed damage (N) = 25

Susceptibility (S) = 80

 

Theoretical Modified Average = INT(25 * 80 / 100) = INT(20) = 20

This is why I maintain that the Average (if it is used) can only be calculated after the Min and the Max are. Either that or the damage modifier is actually 76% (19 / 25 * 100). From my 4000 HE trials with a listed damage of 50, the actual average (39.507) was closer to 40 than it was to 38 (50 * 76 / 100). Not even close. The OSG must list the correct damage modifier of 80% for HE on a Sectopod. We'll know more once a unit with normal resistance to HE is completed.

 

- Zombie

[MikeTheRed]

Thanks for your long explanation, Z. Yes it definitely clears up some things.

 

Clearly the separate modifier calculation resulted in the 9 and 29. The min and max seem very solid.

 

However, pardon my density but I am not entirely clear about the average. I followed it in the 9/29 example, and hear you say the average was 19.65. The data is the data, eh?

 

And another quick thought: given your math, shouldn't it be proper to say, the anticipated average is (Max+Min+1)/2? This seems like a simpler way of saying your equation - but I worry that I'm overlooking something.

 

In your other example of HE 50 and Modifier .8:

 

   Min[1]=25; MIN=20
  Max[1]=75; MAX=60
  Ave=(20+60+1)/2=40.5

But you saw 39.5? Did I do my math correctly? Or what am I misunderstanding.

 

There's definitely something going on under the hood in regard to averages. But you know your data far better than I. And apologies if you've already said stuff in this thread, which I didn't read (back) to.

 

I'm uncertain what to do with my model, in regard to averages. I totally believe you when you say that you did not get the simple math average. But then, what should I do in my model? Right now it is simply rolling randomly within the min to max, inclusive. I have tested to make sure it's doing that. (Always a smart thing to do with random rolls. ) It is - and the average of that, is the simple math average (min+max)/2.

 

May I ask you this... I don't know how you store your data, but have you looked at it in histogram form? In particular, I am wondering if the "edges" (min and/or max) might be under- or over-represented. In other words, while something's going on that DOES lead to e.g. the 9 to 29 min to max, just the same, maybe those edges are not entirely as likely to occur, as all other points. Or maybe there's something even a little stranger, like odd-numbered values are slightly more likely than even ones - or God knows what. As hard won as your many datapoints are, though, I don't know if they would be enough to tease out. Even when I run a million simulations, there are still some differences between the min and max counts for particular points. What's important enough to matter? I don't know. But I do know that the percentage by which they are off is quite small. More importantly, it varies from trial run to trial run.

 

You know your data much better than me. And we both know that XCOM may very well not truly store or work with any "average" per se; it probably just sets up its damage ranges etc. and plugs away. Which is to say, their approach may be "good enough for government work", even if it might give data maestros like yourself pause for thought. It would never matter in a regular game, and that's the bottom line for the programmers.

 

I'm not sure where I'm going with this, but any thoughts are appreciated

 

Mike

[Zombie]

However, pardon my density but I am not entirely clear about the average. I followed it in the 9/29 example, and hear you say the average was 19.65. The data is the data, eh?

The value of 19.65 is called the "actual average" (aka "arithmetic mean"). It is found by averaging many, many data points. In this case, it is 1037 data points with a sum of 20376. 20376/1037=19.65. The other average is the "anticipated average". That value is found by adding the accepted min and max and dividing by 2.

 

And another quick thought: given your math, shouldn't it be proper to say, the anticipated average is (Max+Min+1)/2? This seems like a simpler way of saying your equation - but I worry that I'm overlooking something.

Sure, you could say it that way. But, I have doubts whether this is what the anticipated average for the damage calculation is. Most likely, it is just the traditional average: (Max+Min)/2. (So for the case with a min of 9 and a max of 29, the average should be 19). Don't know why I decided that 19.5 would be good. Sure, it explains the results better, but it could just be natural variance in the random numbers produced by the game. I was on a roll with the INT rounding error, and probably took it one step too far.

 

I'm uncertain what to do with my model, in regard to averages. I totally believe you when you say that you did not get the simple math average. But then, what should I do in my model? Right now it is simply rolling randomly within the min to max, inclusive. I have tested to make sure it's doing that. (Always a smart thing to do with random rolls. ) It is - and the average of that, is the simple math average (min+max)/2.

I'd just use the simple math average. It should work fine. Like I said above, I'm probably in error for using the "+1".

 

May I ask you this... I don't know how you store your data, but have you looked at it in histogram form? In particular, I am wondering if the "edges" (min and/or max) might be under- or over-represented.

I was pretty careful in my analysis of the data. Indeed, I ran a histogram of the data and each damage number within the range had roughly the same count for each one. That is to say it is a "continuous uniform distribution" (aka flatline distribution). A normal (or Gaussian) distribution was not seen (the famous bell-shaped curve).

 

- Zombie

[MikeTheRed]

Thanks Z, that clears it up for me. Sorry for all the questions! I know you've mentioned flatline distributions before, but I couldn't remember if you had mentioned it for these particular data.

 

I'll just use a pure random roll - Sounds like a plan! Unless and until anything more clear pops out, eh?

[Zombie]

Does anyone remember this post I made a while back? In it, I was trying to explain why my tests with a Quarterpod standing on the ground had less HE damage than one in the air:

 

			   Quarterpod vs. HE ammo

	   Both on Ground	Both in Air
		 Damage=50		Damage=50
Minimum:		16			  20
Maximum:		48			  60
Ant. Ave:	   32			  40

At the time, I thought that the ground actually "sopped up" some HE damage. Then I tried to explain it away as either file corruption or tester error. None of these theories "felt" right. Fast forward to today. With all my newly acquired knowledge from testing out explosives over at the xcomufo forums, I decided to revisit my tests and take a closer look at the data.

 

Okay, the "listed" power of the HE shell was 50. That means this number is the average damage produced at ground zero (GZ) in the blast. The min would be 25 while the max would be 75. Now the damage to a unit one tile away from ground zero (GZ+1) would be less due to distance. In this case, the average would go down by the regulated 10 points, while the min would go down by 5 and the max 15. But we have to remember that this would be the damage inflicted to a unit having a susceptibility to HE of 100%. The Sectopod has an 80% susceptibility rating lowering the damages accordingly:

 

		  100% Susceptibility	 80% Susceptibility
		Min   Ave   Max		Min   Ave   Max
GZ		   25	50	75		 20	40	60
GZ+1		 20	40	60		 16	32	48

Ah ha! From this data, the HE shell was obviously impacting one tile away from the intended ground zero target. So is this tester error? Perhaps. It could also be a targeting error by the computer. Either way, I now have a deeper understanding of what the problem is. Seeing as I still have the original saved game, figuring out which one should be fairly easy. So what do these errors have to do with damage modifiers? Not much. But if the computer is making some bad targeting decisions when a Sectopod is split into parts, that could have a profound impact. I'll let you know what I find out.

 

- Zombie