Fire Emblem6 Rng Data

I already looked through FEUniverse and I could not find anything when it comes to the RNG routine in FE6 when it comes to hits. Only some details about it in FE7 and FE8. I am curious as to why that is since the FE6 routine is slightly bugged to rarely pull the number 100, which leads to staves missing with 100% hitrate(technicly also applies to weapons,but that will never realisticly happen because that part of the rng-routine uses 2 RNs). I would also be glad if someone came up with a solution for the bug, but I don’t want to pressure people with that unlike how I did it for the Hectormode rankingsfix for FE7.

1 Like

If I recall correctly, what causes hit rates of 100% to miss is an error in the formula/equation for RNG, which is actually also present in some of the early Generation 1 Pokemon games.
The game erroneously checks for whether the drawn number(s) is less than the hit rate, and only if it is “less than”, and if so, the attack hits. The issue then comes in when the number 100 is drawn. Since 100 is not less than 100, the game registers the attack as a miss, leading to a 100% accuracy missing(which gives staves an actual accuracy of ~99.6%). This gets fixed in later games when they adjust the formula so that it checks whether the drawn number is “less than or equal to.”
I am not personally aware of a fix, though if the location of where this routine is located and which byte to change to cause the game to use “less than or equal to” instead of just “less than” is known, then it should be easily fixable.


Attack: Change E89 from DD to DB
Staff: Change E4D from DD to DB
Matthis is correct in his explanation.


blt time

1 Like

Thanks for the explanation :smiley:

I’m sorry. But Matthis is incorrect in his explanation, and Teq’s change, while indeed “fixing” 100% misses, will also allow 0% hits to land (at a higher rate than 100% misses even).

I have read other people assume the same thing Matthis does, possibly because it is fairly easy to understand the issue in those terms, but it is wrong. The game does check correctly against the generated number for hits. The issue is a bit less obvious, and lies in the generated number itself. As Matthis suggested, 100 can be drawn, but the issue is that that shouldn’t ever happen at all. The number should range from 0 to 99.

The reason 100 can be drawn lies in the implementation of the formula that converts a number that ranges from 0 to 65535 (what the actual rng generates) to that number that should range from 0 to 99:

result = rand(0~65535) / 655;

(note: this division here is an integer division that rounds towards 0).

As you can maybe see, that isn’t a very sound way of doing the conversion - as any random number above 65500 would result in a 100 (that is an effective 36/65536 = 0.054931641% chance of rolling a 100 and 655/65536 = 0.999450684% chances of rolling any specific number in the 0 to 99 range). FE7 and onward would fix this by changing the formula to the following:

result = rand(0~65535) * 100 / 65536;

If you need this applied to FE6: at DF0 paste 64 21 48 43 00 0C ( mov r1, #100 ; mul r0, r1 ; lsr r0, #16 ) (untested).

I assume the reason why fe6 does this silly looking rand / 655 thing is because the code originally looked like rand / (65536 / 100) as it does look mathematically correct, but it isn’t because of integer division rounding.


That actually is quite interesting to know. I always read that it had to do with what I wrote above, but I never have seen anything related to your explanation; does mean that what I have written is an old theory, or that an incorrect assumption was made that made sense? How did such a theory come about in the first place?
Somewhat related, but do you know if that is the same issue that is present in the Generation 1 Pokemon games, or is it different?

1 Like

So basicly, it does not like #100,so that stays at the vanilla value. I wanted to test if that fixed it or not since that detail is diffrent. But when I tested and set an automatic RN-burner,100 just did not appear in either the rom with the change nor the rom without the change. It feels kinda weird to not have concrete confirmation that everything is working as intended.

Thanks for the correction, Stan!

1 Like