the pointers that I reffered to, simply point to later in the file where the action data (amongst other things) are stored. if there is a bunch of actions taken (frequency doesn't matter), you'll need a larger offset in the file (because there's more data, when you need to point to the end of it; i.e. if you needed to say "look after the action data" when there are only 10 actions vs when there are 10,000). At some point, the amount of data stored exceeds the offset representable in the number of bits allotted for that pointer, and the replay can't function.
Cool, I get it now.
Shorter pointers would be more easily overloaded with data and would fail, but longer pointers would be able to carry much more data before they failed.
That means, theoretically, a pointer could be long enough to remember a 99 stock match without failure, but I'm guessing that having pointers long enough to do that would be a bit much for the Wii's RAM.
Here's an interesting thought --
Encoded in a replay must be data for every button press and random event like item appearance.
All these events have to be placed within a time-frame, so that means the replay must be able to perform a player's quickest or most precise movements.
With this in mind, a hacker could construct button data for a match that never occurred or alter an existing match.
Can you imagine taking a replayed match where you lost due to your timing just being a little off and tweaking it until it appeared to be a match where you had perfect timing and won as a result?
If the Wii can make you lose a battle you actually won with one faulty button reading, then isn't plausible that a "faulty" button reading could make you win?
