`feed_zone_events` fires `ZONE_CHANGED`, `ZONE_CHANGED_NEW_AREA` and
`MINIMAP_ZONE_CHANGED` inline into the VM. pfQuest answers all three by calling
`SetMapToCurrentZone()` whenever the map is closed (`pfQuest/map.lua:1466`), and
that verb reads `worldmap.player_zone` — which `ui_world_map::feed_world_map`
publishes, in a system that was ordered only `.after(UiInput)`, exactly as this
one was. Nothing ordered the two against each other.
Run the wrong way round, `SetMapToCurrentZone()` reselects the zone the player
has just left, because the feed has not published the new one yet. Every
map-derived overlay then stays a zone behind until something else reselects —
opening the world map, say, whose `OnShow` calls the same verb a frame later
when the feed has caught up.
There is nothing to order in the reference: `SetMapToCurrentZone` calls the
resolver `0x4a6650`, which reads the player's current area live. Reading a
per-frame feed instead is ours, so the ordering is ours to state. Stated as a
set rather than a bare `.after`, since the next consumer of the published zone
will owe the same edge.
Found while chasing grom's report that pfQuest's minimap icons do not re-seat on
a zone change until the world map is opened — which is this shape. Not confirmed
as that bug's cause: it is an unpinned order, so which way it fell before this
commit is not something the logs record.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
92b2e31577