Yet another super-long RPG to TAS. There's loads of dialog so it probably wouldn't be the best to watch but routing it seems interesting as we can abuse RNG manip to pull off strategies that would never work or be too risky for RTA.
There are some speedrun notes for RTA here I'm looking at as a starting point:
https://www.dropbox.com/s/3nvsq816rkztmhv/SoAL%20Notes_V5_ArcadiaLegend.doc?dl=0
An example potential rng-based improvement (as noted in the notes) could be to guarantee one or two electri boxes from the opening battle, and use them against Antonio. Each one does about 20% more damage than Aika casting Pyri, and can be stacked on the same turn as they don't use MP. However, spell casting animations seem to take longer than normal attack animations, so forcing crits with Vyse may be overall faster still.
I have partially reverse engineered the RNG as it applies to random drops:
- The roll for whether to drop an item starts at 8002bad8, and is called as an enemy dies, before the animation of them taking fatal damage occurs.
- If the drop chance is greater than 100, this isn't called, and the item drops immediately instead.
- The PRNG used is free of side-effects such as cpu time dependence, and does not appear to be affected by controller inputs while animations are playing in battle.
- With a breakpoint at 8002badc, the random number rolled is in r3; the percentage chance to get the drop is in r27.
- If (r3 % 100) < r27 the item drops
- The PRNG value does not advance at all by waiting on the battle menu, and advances by 1 when you choose attack.
The random number rolled is unfortunately never in memory (though the LCG state is, and it could still theoretically be calculated from that) so it's hard to put a watch on it. The memory address of the item's drop rate depends on which enemy is dying so watching registers at a breakpoint is unfortunately the most sensible way to do this.
The rng function is found at 8025ECC4, with state at 803469A8. It is a standard LCG with parameters: multiplier 1103515245, increment 12345.
As the rng does not advance at all in battles, it looks like you have to set up the rng state before entering the battle at all, which is going to be an absolute pain...
Update: it looks like the rng is reseeded from the CPU clock (low 32 bits of the timebase register) on entering a battle; this happens at 8000a1d4. The timebase register increments multiple times every frame, and not always the same number of times, so as far as I can tell this restricts RNG manipulation to pure trial and error, as well as making battle rng dependent on system time...