Fishing gauge native read - #12
Merged
Merged
Conversation
Five panels scattered across the screen is a lot of furniture to arrange every
session, and only one helper is ever useful at a time -- you are in exactly one
minigame. Two docked layouts stack them against an edge instead: 'left' in a
column, 'top' in a row.
Docking takes over positions but does NOT overwrite the saved px/py, so
switching back to 'free' puts everything exactly where it was. 'free' stays the
default, so an upgrade moves nobody's panels; the layout is picked from a
segmented control in the suite panel.
Two behaviours ride with it, both only active while docked, and both disabled
in the UI when they cannot do anything:
* "One helper at a time" -- opening a helper collapses the other helpers. The
clicker is exempt, since it is useful alongside any of them, and so is the
suite panel. Off in the free layout on purpose: there the panels are
wherever you put them, and collapsing one you never touched looks like a
bug rather than a feature.
* "Auto-open active" -- opt in, off by default, and the helper whose minigame
is on screen opens itself. Driven off each helper's OWN detection: hoops
exposes whether it can see the platform, fishing the lane, darts the board,
all variables their loops already maintain. No second copy of any detector
here to drift out of step with the real one. It acts only on a change of
which helper is active, so a manual collapse is not instantly undone, and
waits 600ms before believing a change, because the detectors flicker while
a screen loads and a layout that flickers with them is worse than one that
lags.
Dragging a panel out of a dock drops the layout back to 'free' rather than
snapping the panel back, which would look broken. "Reset panel layout" now also
returns the layout to free.
Re-stacking is coalesced to one pass per frame -- collapsing one panel moves
every panel below it, and chrome() is called per panel -- and runs on resize.
Nothing in any helper's own code changed: the docking lives entirely in the
hand-written shell, and the only per-module additions are a dockOrder, a
helper flag, and the one-line active() hook in each -post.js. The generated
suite diff removes exactly six lines, all of them shell.
NOT YET SEEN RUNNING. The build is clean and the lifted regions are untouched,
but the browser was down when this was written, so neither layout has been
looked at. It should be before it is trusted.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The docked layouts laid panels out in one straight run: five across the top, or five down the left. That holds on a maximised window and falls apart on the smaller side-by-side windows the suite is actually being used in now — a half-width window cannot fit five panels across, and a short one cannot fit them down a column once more than one is expanded. A panel past the viewport edge is the exact trap the clamping in place() exists to avoid: it cannot be reached, and a panel that cannot be reached cannot be dragged back, so there is no way to recover it short of clearing localStorage. The run now breaks into a second row (or column). `run` carries the thickness of the current one -- the tallest panel in a row, the widest in a column -- so the next one clears it rather than overlapping. The first panel of a run never wraps: if a single panel is bigger than the whole viewport there is nowhere better to put it, and wrapping on it would spin. Each panel is measured before it is placed. Its width is pinned by style.width so its height does not depend on where it lands, which is what makes measuring first safe -- and the wrap has to be decided before the position is written. Still not seen running. The build is clean and the generated diff touches only the shell, but no debug browser was up to look at either layout, so this inherits the same caveat as the commit that added the docks. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Cursor mode aims at lastX/lastY, and those only move while the pointer is over this window. Put the game in a second window -- side by side, or just not the one being pointed at -- and they go stale the moment the pointer leaves, and they are 0,0 before it has ever arrived. The clicker then clicks the top-left corner of the game forever, looking like it is running fine. That is not a harmless no-op. A click on bare ground is a walk command, so a corner click sends the character strolling, which is the same failure the fractional fixed target exists to avoid. It also cost a misdiagnosis today. Asked why the fixed-position click "was not working" in a side-by-side Firefox window, I reasoned about legacy configs, off-viewport coordinates and docked panels eating the click -- three plausible theories, all wrong. The config dump said mode: "cursor" in its very first field. Nothing was broken; the mode was simply not the one being debugged, and nothing on screen said the mode could not work from there. So: in cursor mode with the pointer elsewhere, tick() holds instead of clicking, and the readout says "cursor is in another window" rather than "(follows cursor)". The timer keeps running, so it resumes by itself when the pointer comes back, and fixed mode is untouched -- a fixed target does not care where the pointer is, which is exactly why it is the right mode for a window you are not pointing at. Presence is tracked by mouseout with a null relatedTarget, which is the pointer leaving the document altogether; leaving for a panel or any other element names that element instead and does not count. One edge worth knowing: if the pointer is sitting over the window but has not moved since load, no mousemove has fired, so it reads as absent and the clicker holds. The status line says so and the first flicker of movement clears it. Treating "never seen" as present instead would let the 0,0 case straight back in, which is the bug this is here for. Not seen running -- no debug browser was up. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…lick Two gaps found by actually looking at the docked layouts running. Everything arrives expanded. Nothing enforced "one helper at a time" except the collapse button's own handler, so entering a dock with four helpers already open produced a column tall enough to need a second one -- the exact sprawl the dock exists to remove. enforceSolo() now runs on entering a docked layout and closes all but the first open helper, so the invariant holds however the state was arrived at, not only when a panel is clicked. And there was no way to roll everything up at once. "Hide all panels" hides them, leaving nubs and nothing to click; what was missing was collapsing them to their title bars, which keeps every panel on screen and reachable. The new button toggles, reading "Minimise all" or "Expand all" the way the hide button already does, so it says what it is about to do rather than what it is. Verified in a live browser at 960px wide, which is narrow enough to force both wraps: the left dock fills a column and overflows into a second, the top dock fills a row and wraps Darts below it, panels come out in dockOrder, switching layouts re-docks everything live, and the clicker reads "cursor is in another window" when the pointer is elsewhere. The button and enforceSolo are NOT yet seen running -- they postdate that injection. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.