Hah, looks like the creator of this hack didn't change much in the battle engine. As far as I know, it should work on every rom that didn't modify the battle engine. The issue would be obviously hooks and custom functions.
But anyway, to answer your question. Movesets past gen 3 won't work because you've put them in the wrong order in the table. Now:
in the vanilla roms after the last pokemon by ID that is Chimecho there are slots for an egg and all unowns, I'm not sure how much that is. What you could do is add, say, 40 pointers to the turtwig moveset at the end of the table and gradually erasing one, until you find which one belongs to Turtwig. What's more, you have to know what indexes the pokemon have. Most likely, the creator just went with national dex order, but stuff like forms may have strange IDs.
You can see pokemon ID in the ram, provided you've got him in the party or box (or opponent has it), if you don't know how, feel free to ask!
Also, to answer how the learnset table works:
- the location of the table is set at run-time, based on the start offset
- the table is not repointed, because the most important functions that use it have been rewritten, meaning there's no need for that
Okay, thanks for your help! Much appreciated!
However, I'm still not certain I fully understand. From what I've seen in pouring over hex and VBA memory dumps, often a reference to a table object (at least, via pointer) is arbitrary – thus, no table iteration is required, taking an action similar to this pseudocode :
However, the reason I'm not getting the right learnset now, is because, in reality, it's getting a marker/index from the Pokemon in question. Which it then, essentially, adds it to the learnset table's initial offset? A la :
Thus, at least for this this battle system, the existing Pokemon table and the new learnset table (along with others, I can imagine) need to run in parallel, having a 1:1 relationship with each other so that the indices match up. If so, this would explain the garbage output, since it's not reading from the appropriate index. It should also indicate that I can modify the lookup method, instead of throwing in 40+ TURTWIG_MOVESETs and hoping for the best.
Again, please correct me if I'm wrong! I'm likely looking at this from too much of a C-based perspective, and I know you guys are piggy-backing quite a few vanilla helper functions, so I may may be overthinking it, or I may just need to dive into the disassembly of the 'nilla functions to see what's going on. That said, once I can wrap my mind around this, I'd be happy to contribute to the project if you need a hand! (I'm a software engineer.)
EDIT: for the sake of transparency, I tried appending TURTWIG_MOVESETs ~40 times and tried to repoint Turtwig's learnset to a number of the resulting offsets to no avail. I also tried adding variable numbers of EMPTYSLOT_MOVESETs as padding, prior to a TURTWIG_MOVESET within the learnset_table, and that didn't seem to work once re-pointed either. Perhaps I'm misunderstanding this haha.
A couple of offset samples I'm going by to give you an idea of where my head is at (assuming the first bit of pseudocode above is accurate) :
0x08F30000 : Battle System Upgrade base location
0x08324900 : Turtwig's original learnset location (pre-patch, working)
0x08F5965C : New learnset table location (post-patch, working on <=Gen3)
0x08F59CD0 : Turtwig's new learnset location, tested re-point here (post-patch, present but not working)
0x08F59D04 : Chimeco's learnset location within new table, included for proximity (post-patch, present untested)