Modding the Random Number Generation

[DaGawdfadda]

The issue I have with the RNG (as you might have gathered from my prev post) isnt with the randomness but more the impact it has on your decisions.

I stopped playing for a bit but when I get back to it ill be 90% of the time hunkering my guys in full cover and ignoring half cover and just waiting for the aliens to come to me basically.

This is the suggested method on a lot of boards- using one guy to lure the aliens to you by moving back out of their sight- although I have seen it fail as I've been killed by aliens shooting at me from the fog of war (my guys werent hunkered, they were on overwatch). Forget flanking or anything of the like.

I wouldnt feel so upset over missing an 80%+ shot while flanking if it didnt mean my guy gets killed even though he is in full cover.

This is why I'm much more interested (and believe it would be simpler) to mod the cover bonuses rather than mess around with the RNG.

[zerothenumber]

I actually kind of like how the RNG works now. If you guys recall the quantum theory with the cat-in-the-box, the RNG in this game works exactly like that. Except when you have 100% change to hit (in wich case you KNOW the cat is alive), the rest of the times are just wild guesses, bot hitting and missing being true and possible at the same time. When your soldier's turn comes up you see a 70% change to hit. But the roll on that chance was already set before the actual turn, that means you can have two outcomes: you either hit or you miss. You cannot tell wich will be untill you actually take action and shoot, but both outcomes are possible (even with a 90% chance to hit). Of course, you will think a 90% chance will probably set the odds in your favor, but bear in mind that the possibility of missing still exists and it has 50/50 chances to occur (because something either happens or it doesnt).

 

I don't know how much of my comment makes sense to anyone as english is not my primary language but I hope you get the idea. The only change I would want is for full cover to "COVER" your soldier entirely. That means, when you get shot nothing happens, you don't take damage at all (except the actual cover being blown to bits). That would make you run like hell from there, OR, if the enemy has more troops, to shoot you and hit/kill you. I would probably also want that to-hit chance (percentage) to be removed completly from the game and only the flank indicator/icon to be shown when there's the case.

[aggies11]

...but bear in mind that the possibility of missing still exists and it has 50/50 chances to occur (because something either happens or it doesnt).

 

While I appreciate the Schrodinger's cat reference (awesome), the above statement unfortunately does not accurately use the word "chance". There is a not a 50/50, ie. equal chance for either event to come. You are stumbling on to a very important part though: "chance is meaningless with respect to a single event". It also brings up a larger debate about determinism in general (very interesting, although an age old philosophical question), but that it definitely for another place ;) "Chance" implies "if you do it many times, the numbers will tend to match this chance". You are right in that, at the moment, either event can happen. But on a 99.999% shot, you can still miss, just that if you were betting, you could make that bet many many many times over, and only very rarely lose.

 

Probability is a statistical concept, one that really only applies "after the fact". That doesn't mean we can't make useful predictions before hand, but it is really only accurate "looking back". The guy who won the lottery last week, had a 1 in 10million chance to win, just like you. Yet he won, and you didn't. Just like the surgery that has a 98% success rate, the person it didn't work for had same "chance" and "odds" as everyone it did work for, yet for him it didn't work out. It's a tricky subject.

 

Back on topic

 

UPDATE: After more digging it seems like this will be a rather difficult thing to accomplish. All the "to hit" calculations are done in UnrealScript, outside of the call to the Random Number Generator, which is inside the EXE itself. Since all we can do is hex edit the compiled UnrealScript byte code, we really can't modify the contents of scripts outside of changing literals. But inside the game, all the calculations are hidden inside the Bytecode interpreter, and even injecting code into the game itself, would only allow you to alter the RandomNumberGenerator itself, NOT how the game uses it (which is what we want). So you could make it that the toHit chances work out the way we want, but all other probability in the game (eg. Random events in the Strategic game, like UFO appearance, etc) would also be affected. Which seems like way too big of a side effect.

 

So unless we get some sort of Script Compiler (or less likely, a Bytecode editor that allows code injection), this idea has to go on the back burner.

 

Shame, because I really think it would be interesting to see how people react to it. Like the post before, it'd be neat to see if the simple change in probability would actually do what you want (change the effectiveness of cover).

 

For Example: With a 65% aim, -40% tall cover, you have a 25% chance to be hit. Where with a modified hit calculation, it would end up being more like only 12%. So that could make tall cover quite the improvement. Would have to see it in action to be sure though.

Edited November 2, 2012 by aggies11

[FonzieD]

This is why I'm much more interested (and believe it would be simpler) to mod the cover bonuses rather than mess around with the RNG.

 

same. i've been digging around for a bit in the UPK files and I can't seem to be able to find anything that changes cover bonuses. i can find a few references to the cover bonus (i.e. COVER_BONUS_LOW 20) but it doesn't appear to do anything when i try to change it.

 

there was also supposed to be a second wave option that would increase cover bonuses as well, but it can't be enabled for whatever reason. if someone who knows what they're doing could look into it, that would be pretty ballin.

 

edit: seems like cover bonuses are hardcoded into the game, so i don't think editing UPK files can touch those values. dang.

Edited November 2, 2012 by FonzieD

[zerothenumber]

...but bear in mind that the possibility of missing still exists and it has 50/50 chances to occur (because something either happens or it doesnt).

 

But on a 99.999% shot, you can still miss, just that if you were betting, you could make that bet many many many times over, and only very rarely lose.

 

 

 

You are correct. That is why I would like NOT to see those percentages, that way I can relate to the distance to the target, wether if it is in cover or not, flanked or not, etc, and give my own predictements based on those visual indicators alone. The outcome being a complete random chance event in the end (well not completly but close enough). That and also the fact that we can't do anything about it anyway, being hardcoded and stuff.

[DaGawdfadda]

This is why I'm much more interested (and believe it would be simpler) to mod the cover bonuses rather than mess around with the RNG.

 

i can find a few references to the cover bonus (i.e. COVER_BONUS_LOW 20) but it doesn't appear to do anything when i try to change it.

 

 

It was brough up in another thread but its possible the changes are working but just not being displayed on the UI. Not sure if this test would work but try and set up a shot that hits with the regular cover, edit the cover up to something like 99% (ie would make the shot chance zero) and see if it still hits. Unless you've already tried this...

[FonzieD]

This is why I'm much more interested (and believe it would be simpler) to mod the cover bonuses rather than mess around with the RNG.

 

i can find a few references to the cover bonus (i.e. COVER_BONUS_LOW 20) but it doesn't appear to do anything when i try to change it.

 

 

It was brough up in another thread but its possible the changes are working but just not being displayed on the UI. Not sure if this test would work but try and set up a shot that hits with the regular cover, edit the cover up to something like 99% (ie would make the shot chance zero) and see if it still hits. Unless you've already tried this...

 

i don't think so. based off the almost non-existent programming knowledge i have, cover values in this game are constants, so it's hardcoded into the game. i think i would have to decompile the code itself, change the values, then recompile the code.

 

but if anyone knows how to change it, i would definitely like to know, since IMO the game would be 10x better if cover was more balanced.

[Koshea69]

Almost a year later I come back to see if there's anything like this on the Nexus, I still don't see anything that modifies the random number generator in a way that magnifies the middle and minimizes the extremes.

 

Is there anyone able to produce a mod like this? I would love to go back through the game but still much rather play it as a tactical operation game rather than almost completely random chance.

[Amineri]

It's possible to mod individual random number generation calls into something else, but the core random number generators (there are at least two, one for integers and one for floats) can't be modified. Plus, if they were directly modified it would affect a LOT of things, generating a lot of side effects that probably wouldn't be so great.

 

I have already modded two things in this vein:

1) The damage variation, making it not just a flat +/- 1 but making the variation scale with the base damage

2) The rocket scatter, making the scatter amount a normal distribution in both range and azimuth, with the pdf variance based upon the unit's aim stat.

 

As was previously pointed out in the thread, the core function that rolls the to-hit value is in XGTacticalGameCore.RollForHit. I've experimented with this code, temporarily making this a test against a fixed value instead of a random number in order to verify different aspects of the to-hit system (e.g. that combat drugs really does provide a +20 to-hit bonus), and it works just fine.

 

The main trick is that most of the to-hit calcuations (including all of the cover bonuses) are done in the native code (instead of the upk), making it very difficult to mod.

 

The other (slight) problem is that the AI uses the to-hit values in order to determine its actions, so changes to the to-hit distribution (changing it from a linear distribution to some form of Bernoulli distribution) might have unintended side effects in terms of AI performance.

 

--------

 

Anyhow, the main trick would just be that the RollForHit function isn't very big, so there's not enough room to make 2 independent calls to the save-seed PRNG to generate two number to average together as originally proposed.

 

The pseudo-random number call takes up 44 bytes:

fRoll = class'XComEngine'.static.SyncFRand((string(Name) @ string(GetStateName())) @ string(GetFuncName()))
0F 48 E2 76 00 00 12 20 BC 4D 00 00 2A 00 6F 4D 00 00 00 1C 71 4D 00 00 A8 A8 38 57 01 04 FA FF FF 38 57 61 1C 16 16 38 57 1C B5 FC FF FF 16 16 16 

The first five bytes are for the assignment operator and local variable fRoll.

 

The simplest way to change this would be to give up on the save-seed PRNG and just use the Unreal Engine's in-built primitive PRNG instead (which is much smaller).

The inbuild FRand() command in hex is just:

C3 16 

So (FRand() + FRand())/2.0 in hex would be:

AC AE C3 16 C3 16 16 1F 00 00 00 40 16 

Only 13 bytes!

 

Next comes the slightly arcane bits ... the original call to the saved-seed PRNG was 43 file bytes and 63 memory bytes (the code has to take up more space when loaded into memory than it takes on disk, apparently).

 

The new code is 13 file bytes and 13 memory bytes. We currently can't change the number of file bytes in any of the functions (would basically require recompiling the entire upk, which is beyond us).

 

However, we can pad out the size in order to make it bigger, both by adding 0x0B null-op codes (each is 1 file and 1 memory byte) and adding 'dummy' variable calls (each is 5 file and 9 memory bytes).

 

The new hex is 30 file and 50 memory bytes smaller, so would require 20 additional memory bytes to match up, or 5 dummy variable calls. 5 dummy variable calls would take 5 * 5 = 25 file bytes. So, in total it would take 5 null-ops and 5 dummy variables to add 30 file and 50 memory bytes to preserve the function size.

 

I'm going to use the fChance variable from the function as the dummy variable to call, which is : 00 E5 76 00 00

 

The filler code would be:

00 E5 76 00 00 00 E5 76 00 00 00 E5 76 00 00 00 E5 76 00 00 00 E5 76 00 00 0B 0B 0B 0B 0B 

So the original code/hex is:

fRoll = class'XComEngine'.static.SyncFRand((string(Name) @ string(GetStateName())) @ string(GetFuncName()))
0F 48 E2 76 00 00 12 20 BC 4D 00 00 2A 00 6F 4D 00 00 00 1C 71 4D 00 00 A8 A8 38 57 01 04 FA FF FF 38 57 61 1C 16 16 38 57 1C B5 FC FF FF 16 16 16 

And the new code/hex is:

fRoll = (FRand() + FRand())/2.0;
fChance
fChance
fChance
fChance
fChance
0F 48 E2 76 00 00 AC AE C3 16 C3 16 16 1F 00 00 00 40 16 00 E5 76 00 00 00 E5 76 00 00 00 E5 76 00 00 00 E5 76 00 00 00 E5 76 00 00 0B 0B 0B 0B 0B 

Of course you'll have to use XShape or ToolBoks to either recompute the checksum or disable it entirely, as described elsewhere.

 

This is just me piecing together some stuff and tossing it in the post ... I haven't tested any of these changes :smile:

 

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

 

Functionally this change will of course skew the resultant PRNG toward 0.5, making shots above 0.5 more likely to hit and shots below 0.5 less likely to hit. I think this is a specific instance of the multinomial distribution which in this case would be a "triangle-shaped" distribution with the peak at 0.5.

 

This should make the probability of a 0.75 shot be 87.5%, while the probability of a 0.25 shot would be 12.5%.

 

In general the AI's cut-off for a "decent" shot is at 0.3, and it considers anything above 0.5 to be "good".