This is likely how we'll destroy SEI-RYU. Minus my goofing around in the menus in a most unTASlike way.
As for the MOSQUITOs, a group of 3 instantly dies to GAZE. Strangely, encountering 1 or 2, quite possible while still grabbing the Mana+5, lets them attack first, but a group of 3 lets our GAZE mutant strike first. Additionally, the spot I loaded the game from is the near-optimal tile, as it lets the guard step towards us without any delay as demonstrated. Any closer, and we must wait a frame or two; Any farther, and we'll need to take an extra step, eating 16 frames.
Finally, the last hurdle, the Monster Trio, couldn't have ended better even if I want it to. The second fodder dies (
if she doesn't use ESP) without a fuss, and the monsters die without any time-wasting actions other than killing our fodder for us. This is pretty much perfection, right here.
And with that, after BYAK-KO, our two mutants suddenly don't matter. It's all down to a newcomer, and his stats are completely independent of everything we do up to getting him. So we don't need to think about World IV until we finally get there.
So you ended up busier than expected. That's fine. If you get nothing else done this week, at least find some time to suggest the names we should use. Blank names all the way through (
fastest)? Single letter names with carefully thought anagrams (
Don't forget -- we're getting a fifth member eventually)? Full-blown names? We still have time to think about this. When we finally start, changing the names become rather inconvenient.
I am impressed with Sara at Tower Reversed. Promptly creating the encounter list for FFL after someone was asking about it, definitely a nice thing. If even posts here are being watched, then I suppose my thanks here would be quite noticed. So, uh... Thanks! You certainly put an effort right into it.
EDIT: I forgot to mention I've been getting a few PMs from Kuwaga. The discussion is mainly about the RNG, and we concluded that there's no easy way to create a lua script that predicts the RNG values when we reset. Well, short of running the emulator and going through the reset process and recording what comes out.
Address
FF04 is based on a hardware timer, which is where the RNG is getting its source of "random" numbers when we reset. Directly reading it probably isn't going to give us the precision we need to unravel the RNG, and good luck trying to count opcodes.
We've got just about everything planned out. We already know what RNG values we want from resets, so there's little we can get from deconstructing the RNG further.
Incidentally, take a look at address
CB00. In fact, take a look at the next one at
CB01, too. Actually, Tools -> Debug -> Memory Viewer -> Address
CB00 and friends, all the way out to
CBFF. I wouldn't have expected the entire RNG table being
right there in memory, of all places.
