dev #24
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "dev"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Frontend for the Optimize endpoint. Adds to the roadmap page: * floor toggles — which savage floors the static can reclear each week, the single biggest input to the estimate since book income is per-floor; * two week counts, at today's floors and with all four open, so the cost of progression is visible without anyone predicting when the next floor dies; * a per-player book breakdown, with unreachable floors called out in amber rather than folded into a number; * proposed queue changes, diffed against what is actually on screen. Deliberately a preview. Apply writes through setOverride one queue at a time, exactly as a manual drag would, so an optimizer run has no privileged write path and cannot silently replace an order the static argued over. Nothing is applied until pressed, and queues that already match are not listed. The estimate is labelled books-only in the UI, because that is what it is: every clear banks one book per floor, so it is a ceiling that chest drops improve on. Presenting it as a schedule would be a lie about randomness. Floor toggles are offered to any claimed member and enforced Lead-side by the server, which rolls the toggles back and explains if refused. The client has no role information here, and guessing would wrongly lock out an actual lead. Changing floors re-runs an open plan, since a stale panel would now be describing a different set of floors than the toggles show. Verified against a local stack: Optimize returns a plan whose arithmetic checks by hand (a player owing a 6-book body plus a 3-book accessory finishes week 4 — accessory week 2 via converted floor-4 books, body week 4), the makespan ordering holds, and locking M3 flips weeksAtCurrentFloors to null with Body marked unreachable on both the queue and the affected players.Surfaces the backend's skippable-floor verdict in the Optimize panel, as three visually distinct cases rather than a single flag: * safe to skip — nobody needs the gear or the books, so clearing earns nothing; * keep clearing — with the count of players and books still outstanding; * not cleared but needed — the worst combination, called out in amber. Floor 4 gets its own wording when it has no weapons outstanding: "its books convert into the other floors, so skipping it would slow everyone still missing something". Without that, the panel would show a floor with zero demand next to a "keep clearing" verdict and look simply wrong. Phrasing lives here rather than on the server, which returns facts (outstandingBooks, playersNeeding, convertsToOtherFloors) — but the conversion rule is not re-derived client-side, it is a field, so the two cannot disagree about why a floor is worth clearing.