Unit: no battle pad holds both NEXT and BACK, over every sub-state with and
without a potion and a ball, and NEXT is on none with a cursor accepting input
(the assertion the top-level menu failed before this branch). A battle frame
with a cursor accepting input is the fly's turn, against real WRAM, for all
four menus plus the two frames that correctly are not one. The bag deals
ITEM / THROW BALL / BACK, and BACK alone when the bag is empty.
ROM-gated, from the live rung-9 forest checkpoint: no pad with both buttons, no
NEXT while a menu accepts input, the longest NEXT/BACK alternation under four,
and every battle entered also left, each on a bounded number of macros. The
battle rules ask the scene the pad was dealt for rather than wIsInBattle, so
the $ff frame a lost battle passes through -- which reads Unknown, whose pad is
NEXT and BACK by contract -- is not accused of a battle rule.
The test fails on v0.4.2 from the same checkpoint with "NEXT was on the pad
while a battle menu was accepting input", NEXT dealt on battle/main, and a run
that never leaves map 51.
Live on rung 9 thirty-five minutes after v0.4.2: NEXT 1264 macro starts, BACK
1241, the log alternating NEXT start/done, BACK start/done every hold, on map
51. NEXT on the top-level battle menu is an A press on the cursor, and the
cursor sits on FIGHT, so it opened the move list; BACK on the move list closed
it again. Each button was legitimate where it stood, and the pair undid itself
with nothing else changing, so the turn never resolved.
NEXT is now on no pad with a cursor accepting input. It keeps the between-turns
row alone and the forced switch, which has no BACK beside it to undo it. MOVE 1
is the top-level menu's backstop instead: the question over that menu is 12.8's
"is there a move list to open", FIGHT always opens, and the script there is
confirm FIGHT and stop, which reads no move at all.
The bag is the fly's own turn, because a cursor accepting input is one, and its
pad is the bag's own three answers: ITEM, THROW BALL, BACK. Section 12.10.
A ROM-gated run from the checkpoint the stream stalled on, gated on its
own variable because the two checkpoint tests beside it assert the map
their envelope is on and one envelope cannot be both.
What it holds: the objective is Pewter City, the road there is on the pad,
BACK is never on a battle pad with no list open, no ball is thrown at a
species the party holds, the fly gets turns, a move or a ball is chosen,
and a battle ends. Which move and which way it walks are the fly's, so
they are reported rather than asserted -- including the forest's north
gate, which this run does not reach.
Two traps from the rung-9 forest checkpoint, both section 12.2's rule: a
macro that completes without moving because its precondition is already
satisfied where the fly stands.
BACK was dealt by the between-turns row, which section 13.1 gave NEXT and
BACK for the sake of the battle bag -- the bag reads as nobody's turn, so
it lands there -- and which is also every frame of battle text. With
nothing open there is nothing to back out of, so the press completes in
fifteen frames on the tile it started on: 163 of 959 macro starts in
twenty brain minutes from the checkpoint, plus twelve more on a move list
whose cursor the seam cannot place. The row is now the sub-state's: BACK
with the bag open, NEXT alone otherwise. The move list and the party list
keep it, and the top-level menu never had it.
THROW BALL gains a fourth fact: the species on the other side is not one
the party already holds. The party is the caught set, because it is the
cartridge's own lifetime record in the same internal numbering the enemy
is read in; wPokedexOwned is by Pokedex number and the table that converts
one to the other is in a ROM bank this crate cannot read. An enemy the
seam cannot place leaves the button where it was.
RUN is unchanged. Its blocked outcomes are the script and not the
cartridge: a cursor macro started as the menu closes waits out CURSOR_WAIT
pressing nothing (mean 184 frames over ten starts), which is audit row 19.
The decoder, the reward catalog, the adapter version and the compatibility
string are untouched: --print-compatibility is byte-identical at 648 bytes.
A scene histogram says "battle" and a battle deals five different pads
(docs/design/macros.md 12.6, 13.1), so a loop inside one of them is
invisible in the tables the hunt already prints. Three more: frames per
sub-state, every macro channel ever bound in each one, and the macro
starts by the sub-state they started on.
