THROW BALL was 63 starts and 63 blocked on v0.4.3 and SWITCH 15 of them, and the
reason is neither macro's own script. The screen reads FIGHT PKMN over ITEM RUN
and the game's index does not: wCurrentMenuItem is the row inside the column the
cursor is in, and selection adds two for the right column, so the order is
FIGHT, ITEM, PKMN, RUN. battle_entry had PKMN 1 and ITEM 2 -- the row-major
reading of the picture -- so every macro that meant to open the bag opened the
party list and every macro that meant to open the party list opened the bag.
Surveyed on the cartridge from the rung-9 checkpoint: a THROW BALL aiming at 2
walked the cursor to wTopMenuItemX 15 / wCurrentMenuItem 0, pressed A, and the
party list opened -- wTopMenuItemY 1, wTopMenuItemX 0, wListMenuID $02 -- with
the game writing wCurrentMenuItem 2 on the frame after the press.
The fake had the same mistake in its own geometry, so it could not have caught
it: its two-by-two moved row-major. It is column-major now, like the cartridge.
THROW BALL on the cartridge was 63 starts and 63 `blocked`, mean sixty-nine
frames: the cursor to ITEM, the A that confirms it, the twenty settle frames,
and then a refusal on the very next frame. Red keeps one cursor for every menu
in the game, the bag takes longer than twenty frames to draw, and `listing` was
still answering for the battle *menu* -- four entries, max 3. A ball whose bag
index was above that read as off the end of the list and the step gave up at
once; one inside it was walked for by pressing UP and LEFT at the battle menu,
which is the blind pressing section 4 forbids.
So a Listing now says which list it is (ListKind) and a cursor step says which
list its target indexes into. A step whose list is not up waits exactly as it
waits for a list that reports no cursor at all, and takes its press order and
its budget from that list on the first frame it accepts input rather than from
whatever was up when the script was built. A confirming press that has already
begun still finishes: the press is what answers the list, so the cartridge is
already drawing the next one while it is issued.
The crossings are named: FIGHT and ITEM and PKMN and RUN over the battle menu,
a move slot over the move list, a bag index over the bag, a party slot over the
party list. A shop's own screens are one list and stay as they were.
The fake gained the one thing it could not express -- a list that takes frames
to draw -- and two of its fixtures had FIGHT and a potion opening nothing at
all, which is how they passed while the cartridge could not.
The walkable predicate answered for the ten-by-nine screen window and Unknown
everywhere else. MapGrid is the same rule over every tile of the loaded map:
block ids out of wOverworldMap, a blocks-to-tiles read of the tileset header s
blockset through the new bank-aware ROM read, the tileset s collision list as
before, and the TilePairCollisionsLand values as directed walls both ways.
The reader checks itself before it answers: the decode is compared against the
window predicate over the player s own neighbourhood, and a frame where the
window can answer for none of it -- a battle, a text box, a frame mid-warp -- is
refused, because wOverworldMap shares its bytes with the picture buffer. Every
refusal is named (GridRefusal) and leaves the window predicate in charge.
Cached per map id and size, so a map is decoded once on arrival rather than once
per question, and owned beside the session ledgers: never checkpointed.
