Files
benilla-octo/crates
gromandClaude Opus 5 e527931885 worldmap: WORLD_MAP_UPDATE is signalled inline, so the map opens on the player's zone
The world-map flash, and it is one frame of the wrong paint rather than a wrong selection.

`WorldMapFrame.xml`'s OnShow runs `SetMapToCurrentZone()`, and `WorldMapFrame_OnEvent` answers
`WORLD_MAP_UPDATE` with `WorldMapFrame_Update()` **only** `if ( this:IsVisible() )`. Our
`store_selection` pushed that event on the deferred lane, so it was heard a tick later — by which
time the panel was already on screen, still carrying whatever tiles the last `WorldMapFrame_Update`
left. Those are the World sheet's: `WorldMapFrame_OnLoad` runs its own `WorldMapFrame_Update`
before the player's zone is known, and a nil `GetMapInfo()` takes FrameXML's own
`-- Temporary Hack` branch, `mapFileName = "World"` (`WorldMapFrame.lua:47-55`), painting
`Interface\WorldMap\World\World1..12` into the twelve detail tiles.

Signalled inline instead, as the setter `0x4a67a0`'s own `SignalEvent` is, so the repaint happens
inside the OnShow and the first frame drawn is the player's zone. Signalling moves out of
`store_selection` — the writer cannot do it, only a caller holding the Lua state can — and each of
the four call sites does it: `SetMapZoom`, `SetMapToCurrentZone`, `ProcessMapClick` (only when the
click actually moved the selection, since the setter is the only signal site) and the engine-side
world-enter sync.

`worldmap_update_event_fires_on_next_tick` asserted the deferred behaviour deliberately, on the
reason "a binding cannot re-enter dispatch". That was not so: `UpdateSpells` had already been doing
exactly this with the same `fire_event_into`, with its own test pinning the synchronous dispatch.
Replaced by one that asserts the inline fire and one that covers the two other legs.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
2026-10-18 09:02:03 -06:00
..