mirror of
https://github.com/DramaticShape/DramaticShapeVoxelMod.git
synced 2026-08-12 10:00:50 +02:00
DramaticShape
eb69bc7db8
It did not. pending() short-circuited on available(), and available() was true for any checkout carrying assets/stadium -- so when REV went to 3 for the shiny variants, such a machine was never pending, was never asked to rebuild, and quietly went on serving the old set. ready() was false, so readPack skipped the save-dir cache and read the shipped normal-only packs: every shiny Pokemon drawn in its ordinary colours, with nothing on screen saying why. A driver run sitting at "idle 0/151" for twelve thousand frames is what surfaced it. pending() is now keyed on ready(), not available(). A checkout with a ROM spends one loading screen rebuilding a set it had files for; after that it is current and never pending again. That was the cost the old short-circuit was avoiding, and it is worth paying once to make a rev bump mean something. The other half is the players who imported a ROM through the picker rather than dropping it in baseroms/. beginFrom builds from the bytes and never keeps them, so on a rev bump there is no ROM to rebuild from -- and with available() keyed on ready(), the STADIUM rungs would have vanished off the options row entirely. usable() now separates "these packs are readable" from "these packs are current": format and count, deliberately not rev. Stale packs keep the mode working and keep the rungs offered; only the recolour waits for a rebuild. Losing the shinies until then is a blemish, losing the mode is not. readPack orders the two accordingly: a current cache always wins, a stale one wins only when there is no shipped set to prefer instead -- so a cache from an extractor rev we have since fixed cannot shadow good files, while a player whose only copy IS that cache still gets Pokemon on the field. Verified by rolling the marker back to rev 2 and launching: ready=false, usable=true, available=true, pending=true, and the build runs unprompted.