A FireRed mod's pokemon and moves patches are merged onto the live
src.core.game3.pokemon module while the mods load (Game3:_loadMods).
Entering FireRed then runs Pokemon.install() from Runtime, which swaps
every species table for a fresh copy of the ROM pack -- names, stats,
types, learnsets, and the move names that live in the same pack. The
only reload hook, in Gen3Compat.applyMerged, re-seeded the sprites and
nothing else, so every such patch was gone before the first frame: a
translation's species_names and move_names catalogs never reached the
party screen, the summary or a battle, and a mod's base stats reverted
to the ROM's.
Write the moves and pokemon registries again onto the new tables from
that hook, the way reapplyMoves already does for the moves module. The
moves registry is part of it because its names and the battle-move copy
it mirrors into belong to the reloaded pack, and it goes first, in the
order Loader:_mergeOrder uses: the moves writer is what adds a mod's own
moves to the move index, and the species writer resolves learnsets, egg
moves and TM/HM lists through that index.
Gen3Compat's src.ui.StartMenu coverage row claimed the
ui.start_menu.items hook is "not raised on FireRed yet". It is raised:
src/ui/game3/start_menu.lua calls it from StartMenu.show with
(game, entries), the same name and arity as src/ui/StartMenu.lua and
src/ui/gen2/StartMenu.lua.
The note is what a mod author reads when asking whether the hook exists
on this generation, so a stale one costs a mod the hook for no reason.
- Rewrite the note to describe the FireRed arm: a row is { id, label }
and carries no onSelect to rewire, and a non-table return is dropped
without the Logger.error the other two generations emit.
- List ENTRIES as backed and note it: the facade passes the module's
list straight through, and show() rebuilds it on every open, so a mod
has to act per open rather than once.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
bryanthaboi