Today, the question that was brought up to my attention was "How does the text box matching method of the Trainer-Fly glitch work ?".
After a bit of research, it appears that when you encounter a Trainer, the following happens (all memory addresses are taken from Pokémon Blue) :
[li](he may approach you, or not)[/li]
[li]his dialog appears, blah blah blah[/li]
[li]Now is the instersting part : the game sets address $D059 to the internal Trainer ID.[/li]
[li]The fight begins.[/li]
This address ($D059) is an instant encounter. As soon as the overworld script reads a non-zer value, the game triggers the corresponding encounter. But what's interesting, is that the Trainer-Fly glitch actually is built on this.
As soon as you enter the map flown from (which probably has its map script pointer changed ?), the last text box in memory pops up, then the encounter begins.
If looking at this sequence with a memory point of view, it gives the following :
[li]The text box which has the ID contained in $CF13 is displayed[/li]
[li]The instant encounter value is set. The textbox itself writes the value (at the same moment the music changes), but if it doesn't handles it, the value at $CFFC is written into $D058[/li]
Question 1 : During a TFly glitch, why is the value picked up from $CFFC ?
Answer : I don't know. I'm looking for that in the disassembly, see that later.
Question 2 : May this be used for ACE ?
Answer : I don't know either… It would mean a text box (with an invalid ID, I presume) runs code in player-controllable RAM. I'm looking both in the disassembly and testing on BGB. Stay tuned !
That would require $CFFC to hold an incorrect value… is that possible (like with Super Glitch ?)