But apart from that random variable (which really cant be random) I believe he got most of the mechanics correct. So i guess my actually interest is that "random" one and its actual behavior.
http://en.wikipedia.org/wiki/Pseudorandom_number_generatorIt is a "random" variable... for a given meaning of random. However, just because they used a fancy algorithm doesn't mean it's a *GOOD* random number generator. In fact, it's a pretty crap random number generator. *All* of FF7's generators are crap. The only reason you're noticing *this* one is because only a few things call it, as opposed to other generators in the game that are called almost all the time, muddying the results.
Your 2nd variable is the seed, from 0 to 255. This is used to look up a table containing 256 numbers already distributed from 0 to 255 in a seemingly random manner... which is pretty much how FF7 gets almost all its random numbers. Every time it wants a "random" number, it increments the seed by 1 and gets the next "random" value in the table.
Your 3rd variable is the offset, which is an extra little thing FF7 is doing to further muddy the waters. Once it gets its "random" value, it subtracts this offset from the value. And there it has a "random" number.
So for your example, with a seed of 76 and an offset of 0, it'd look up the 77th number in the table, which happens to be 3, and then subtract 0 from that. So it returned the "random" number of 3. This has to be less than [Danger Counter * Enemy Lure Value / 256]. A Danger Counter value of 1023, when divided by 256, would return [3.996] = 3. So no battle, since the "random" number is not less than that. But if it were 1024, that would return 4. Since 3 < 4, well, there's your battle.
You noticed that it actually incremented the seed by *2* per Battle Check... the first of those is actually it comparing the first "random" value it picks to the Pre-Emptive chance, to see if you get a Pre-Emptive battle. Yes, it does this each time, even before it knows whether you'll be getting a battle or not. There's also a bunch of other things that also use this seed, as well as a couple of things during the Battle Check that use the same random table but with a different seed (like an even *simple* PRNG that decides what battle you'll get next), but it all gets kinda immaterial after that.
===
The bottom line is this. Yes, it's not *truly* random. It's not even a good use of a pseudo-random number generator - it's among the crappiest I've seen, really, seeing how it's a bad random number generator (strike 1) that's used in a terrible manner (strike 2). (Of course, even good random number generators used in a terrible manner can suck: just take a look at Golden Sun for an example there)
However, without actually doing the maths every time you want to check something, there is absolutely no way to predict when and where you'll battle beforehand. The rules may be simple, but they produce complex results and the only way to know what you'll be battling is to run through the numbers. So there is no benefit to knowing how this works, and as such, I will likely never cover it in any of my guides seeing how it's far too technical.
Do you remember why I continually recommend to people doing Chocobo Breeding, that when they continually keep getting the same Chocobo when they really want a different one, they should run in and out of the barn a few times to 'generate' new random numbers instead of just resetting and reloading? It may be a different random generator, but it's the same principle here: it's a pseudo-random number generator that doesn't have its seed updated every millisecond, and the only way to have things happen differently than before is to have more "random" things happen that depend on that generator.
So if you're going to do any analyzing, I'd suggest you focus on what is actually happening in the game, rather than on the numbers behind it... because with a 256 order seed with 256 possible values for the offset... that gives you a sequence of 65536 random numbers before it repeats. There's also a few uses of that particular seed that increments the seed by 1 but *doesn't* increase the offset if it overflows, which can *further* complicate this whole mess. Given different Area Encounter Values, whether you're walking or running, and how many other things update the seed, I don't think you're going to get any useful information out of the mechanics behind it all.