I'm not sure whether I understand your question. The data structure that represents a boxed pokemon is fixed, it is made by the programmers, I can't change where each value is stored in memory. All I can do is manipulate the stats of it in a clever way. Some values are easy to manipulate (like the DVs), others can't be manipulated easily (like the Health, it depends on the level and levelling is slow). The last easy-to-use values in this structure are EVs and DVs (see http://datacrystal.romhacking.net/wiki/Pok%C3%A9mon_Red/Blue:RAM_map for a RAM map). The RET will bring me back to where I want, correct, but there is no RET until I manipulate one. And since these are the last useful values, it's the natural place for a RET to go. Using more pokemon would allow for more manipulation potential, but is unnecessary in this case and slower.
My question was: why are you using the *last* useful value, when you could use any of them? Is it the fastest way to have these values stored in the memory?
Hello, subscribing on the forum because some details of this video trouble me
TASVideoAgent wrote:
The EVs and DVs are the last useful information that is stored, so it needs to be the ending of the routine:
Why? Why don't you try to execute those two instructions as soon as possible? The RET will get you back where you want anyway. If I'm right (but I guess I'm not, you have thought way more than me about this), that would save you a lot of trouble. Can't you try to somehow have those values on that squirtle?
TASVideoAgent wrote:
The last point in the list is added because of an undesired side effect that the use of that glitch move can have, which is commonly called the "TMTRAINER effect". It is caused in the following way: Even though the move itself is perfectly stable and harmless, its name is not. There is no name for the move, so the game looks for it past the actual move name list. Where it ends up is determined by the number of end of string symbols (0x50) in the game's RAM at that point, which is highly unpredictable. This random portion of RAM (20 bytes) is then copied to the name buffer and from there to the string buffer. This last copy operation is where the problem occurs: the programmers assumed that each name always ends with an end of string sybmol, so the copy operation continues until it is found. The random move name that is picked from the memory may not have such a symbol, so the game copies far too many bytes, overwriting other important memory areas, glitching out the game and most likely crashing it.
Can't you exploit this like any regular buffer overflow? I.e., trying to erase the return value of current function in order to execute arbitrary code. How is it unpredictable? Is there really no way to predict it?
Thanks for this awesome TAS, anyway :)