Three related call sites in the RBY/shared battle pipeline decided
in-game behavior by string-matching a message that had already been
routed through Strings()/romText -- correct in English, silently wrong
under any translation catalog, since a translated message no longer
contains the English substring being searched for:
- BattleState:sayStatusMsg played the sleep/confusion SFX by searching
the status message for "is fast asleep!"/"is confused!". Under a
translation catalog the SFX silently stopped firing.
Status.beforeMove now returns onomatopoeiaKind/onomatopoeiaIndex,
pinning the SFX to the specific still-asleep/still-confused message
it belongs to (not necessarily the last one: confusion not
self-hitting can fall through into the disabled-move check or the
paralysis roll, appending one more, unrelated message after it).
- primaryEffectFailed decided whether to suppress a status/stat move's
success animation by string-matching msgs[1] against six known
English fail lines ("But, it failed!", "Nothing happened!", "didn't
affect", "is unaffected", "protected by MIST", "already asleep").
Extended the msgs.failed flag Substitute's own two failure lines
already used (#644) to every other MoveEffects.primary handler that
can fail without landing: changeStage, confuse, statusMove, and the
single-condition guards in LEECH_SEED, HEAL (including REST),
LIGHT_SCREEN, REFLECT, MIST, FOCUS_ENERGY, CONVERSION and DISABLE --
every function actually reachable through primaryEffectFailed (only
MoveEffects.primary entries are, via performMove's power == 0 and
record.kind == "primary" gate; the many other "But, it failed!"
sites elsewhere in this file belong to secondary/full-kind handlers
on a different pipeline and don't reach this function at all, left
alone here as a much larger separate follow-up). Removed the
six-substring sniffer now that every real producer sets the flag
explicitly; "is unaffected" had no live producer reaching this
function to begin with (SWITCH_AND_TELEPORT_EFFECT's own copy goes
through battle:cancelMoveAnim() directly, a different code path).
Removing the sniffer also fixes three pre-existing test failures
(parity_substitute_anim, two assertions in parity_trainer_ball_block)
that were crashing on a TextBox.strip call this test environment
doesn't stub -- that call only existed to support the sniffer.
- statusInterrupt decided whether a blocked move came from PAR's own
63/256 full-paralysis roll (which clears bide/thrash/charge/
trapping) by checking mon.status == "PAR" together with the message
containing "fully paralyzed". mon.status == "PAR" alone isn't a safe
replacement either: a paralyzed-and-flinched battler also has
status == "PAR" while canMove == false comes from the flinch, not
the paralysis roll. Status.beforeMove now also returns
statusBlockedId, set to the status record's own id only when that
record's own beforeMove handler is what returned canMove == false.
Extended tests/parity_status_onomatopoeia.lua with regression cases
for confusion overriding both ROM text labels with non-English text,
confusion stacked with a disabled selected move, and confusion stacked
with paralysis. Verified against the existing paralysis cases in
tests/mod_battle_tests.lua and the full test suite, no regressions.
TypeChart.displayName(typeId, data) already resolved a merged type_chart
translation for the Gen 2 Summary screen, but the Gen 1/RBY SummaryMenu and
HallOfFame call sites never passed their data table, so opening either
screen before the first battle fell back to the untranslated TypeChart.TYPES
table even with a translation mod loaded.
WideBattle.lua's and this file's own in-battle move-details panels get the
same explicit data argument for the same call convention, though it is a
no-op there today: battle.data/self.data is game.data by reference, the
same table TypeChart.load(game.data) already caches from at battle start,
so both paths already agreed before this change.
The RBY OPTION screen's ZOOM, MAX FPS and the three GameSpeed rows also drew
their dynamic value labels straight from Zoom.offsetLabel/FrameCap.label/
GameSpeed.levelLabel, bypassing Strings() entirely, unlike the Gen 2 OPTION
screen's equivalent rows added earlier in this branch.
A Pokémon's level is printed on four Gen 1 surfaces -- both battle
healthboxes, the party rows, and both status pages -- and every one of them
prints it unconditionally. There is no seam, so a mode that wants the number
gone has two options today and both are bad: paint over the engine's own
pixels from render.hud (four rectangles, a background shade to match, and
the palette flashes and healthbox slide to survive), or monkey-patch the
render modules from inside the sandbox, which works and is exactly what
CONTRIBUTING-mods.md tells mods not to do.
The motivating case is a battle royale that scales every party to a shared
rung rising with its fog: the number is the same for everyone, it changes on
a clock, and it reads as a threat it is not -- a Lv37 opponent looks
dangerous to a player who has not worked out that their own team is Lv37
too. A randomizer keeping an encounter unreadable, a challenge run that
forbids level-checking and a blind Nuzlocke want the same switch.
New hook `pokemon.level_visible`, taking the shape the presentation
predicates on the battle screen already use -- battle.status_hud_visible,
battle.bottom_ui_visible, battle.caught_marker_visible: consulted behind
Runtime.wantsHook, default visible, only an explicit false suppresses. It is
not named battle.* because a level is not a battle-only readout, and it
carries the surface that asked (battle.enemy / battle.player / party /
summary) so a mode can hide an opponent's level and keep its own.
src/ui/LevelDisplay.lua holds the one definition of "visible", so the four
call sites are a one-line guard each rather than four copies of the same
five lines that can drift apart.
No layout moves. Each site keeps its own hand-rolled PrintLevel rule
(home/pokemon.asm:335-345), it just asks first. Two details are deliberate:
a status condition still replaces the level on a healthbox exactly as in the
cart, so hiding a level never hides PSN or BRN (the guard is an elseif on
the existing status branch); and on status page 2 the <to> arrow is hidden
with the level it points at, because an arrow with nothing after it is half
a sentence.
Gen 1 only. The Gen 2 screens and the Gen 1 PC box list -- where the level
is part of a row label rather than a drawn field -- keep their own readouts
and do not consult the hook. Both are stated as follow-ups in the RFC and
beside the hook in docs/modding.md, so a mod author reads the limit before
depending on it.
Verification: tests/modkit/cases/pokemon_level_visible.lua covers the
contract through the public mod API; gate_hooks picks the hook up on its own
because it walks the live catalog; gate_meta_coverage is satisfied by the
change that introduces the seam, so it never enters the DEBT ledger.
tests/run_modkit.lua 33/33, tests/run_engine.lua 327/331 -- the same four
audio/hostshell suites fail unchanged on dev without this branch.
Co-Authored-By: Claude <noreply@anthropic.com>
Two decisions the OPTION screen and the cart make for the player, made
hookable so a game mode can make them instead: whether a faint offers the
SHIFT free switch, and whether a catch asks for a nickname. Guarded call
sites, file-local vanilla links, docs and a public-API modkit case.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N1DVpYXGabigHqMwviDoKV
A capture the party cannot hold silently falls through to the box; the
new partyFullDestination seam lets a mode claim custody at that moment
instead, and pokemon.caught reports destination "mod" so the mode can
find the mon again. Guarded call site, file-local vanilla, docs and a
public-API modkit case.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N1DVpYXGabigHqMwviDoKV
Nine message families in BattleState.lua were plain Lua literals,
bypassing already-extracted, already-translated ROM text labels --
some with a comment right next to them already naming the real label:
- storeCaughtMon(): the new-Pokedex-data line (_ItemUseBallText06) and
the box-transfer line, which used a hardcoded "BILL's PC"/"someone's
PC" as if it were a substituted argument in one shared template --
_ItemUseBallText07/08 are two full, independently translated ROM
strings, not a template with a substituted PC name.
- throwBall(): the dodged-ball and can't-be-caught lines were two
separate Strings() calls; _ItemUseBallText00 is one \f-paged ROM
label covering both. Unlike TextBox.new() (which splits \f itself),
sayNext() goes through the battle queue's own startMessage(), which
only splits on \n/\v -- confirmed live in a real build (the second
sentence overflowed off the box instead of starting a fresh page).
Resolves the label once, splits it the same way TextBox.lua does,
and queues one sayNext per page.
- onFaint(): displayName(battler) runs the enemy name through a
separate Strings("Enemy %s", ...) call, then the shared "%s\nfainted!"
literal added the rest -- but _EnemyMonFaintedText already carries
its own "Enemy" wording, so this passes the raw battler.name and
picks _PlayerMonFaintedText/_EnemyMonFaintedText by battler.isPlayer.
- enter()'s pre-battle black-out message (_PlayerBlackedOutText2, a
\f-paged pair like _ItemUseBallText00 above).
- The AI switch-in withdraw/send-out line and the enemy trainer's
first send-out (3 callsites, one shared by the link-battle intro
path): _AIBattleWithdrawText and _TrainerSentOutText.
Also investigated folding _TrainerAboutToUseText's SHIFT-switch offer
(say() then sayChoice(), both plain Strings(), which the label also
\f-pages) into one romText + sayChoice call the same way. That does
NOT work: tests/engine/trainer_shift_prompt_bug565.lua caught that the
battle queue's own text renderer pages a sayChoice string differently
from TextBox.lua's \f handling that the say()+say() merges above rely
on. Left as two calls, unchanged, with a comment explaining why.
src/ui/SummaryMenu.lua:148 and src/ui/PartyMenu.lua:824 drew mon.status
(PSN/PAR/BRN/FRZ/SLP) as a bare literal, bypassing translation. Unlike
plain text, a mod translates status labels through the statuses content
registry (mod.content.statuses:patch(id, { label = value }), the same
registry src/battle/BattleState.lua:statusLabel already reads in battle.
Route both screens through the same lookup, extracted as
Status.hudLabelFor(statuses, id) and shared with BattleState:statusLabel
so the hudLabel-or-label fallback rule lives in one place, with the raw
status id kept as the fallback when no record overrides it.
Found along the way: Status.RECORDS' five vanilla entries duplicated
hudLabel = label ("FRZ", hudLabel = "FRZ", ...) for no functional
reason. Since hudLabelFor reads hudLabel before label, and
Registry:patch only overrides fields a mod actually passes, a
translation mod's label-only patch (the natural shape for a status
catalog carrying one string per id, with no separate hudLabel data to
patch) was silently shadowed by the untouched vanilla hudLabel -- the
translation was stored but never displayed, in or out of battle. This
affected BattleState:statusLabel too, before this change and
independently of it. Dropped the redundant hudLabel field from all
five vanilla records: it's declared optional in the schema, and
nothing in this codebase ever gives it a value different from label --
setting it here only recreated the shadowing trap for no observed
benefit. Left a comment above Status.RECORDS warning against
re-adding it.
stepHPDrain counts drainHold down to 0 as the last step of every phase
(pixel slide, HP-number step, closing frames) but never let go of the
field afterward, so it sat at 0 -- not nil -- for the rest of the
battle. BattleSafety.inspect uses drainHold ~= nil as its
settled-presentation gate for checkpoint capture, so the very first HP
change in a battle permanently refused every checkpoint after it with
battle_phase_busy, even once the bar had long since caught up.
Only nil the field when the whole drain is actually over (bar pixel,
HP number and the closing-frame hold all settled), not on every
mid-sequence 0 -- a fresh HP change still needs drainHold to read as
busy so BattleSafety keeps refusing captures until that one settles
too.
bryanthaboi