Fix(Unlock Mode): keep cascade-moved elements out of the screen center - #2098
Open
JuJuFX-dev wants to merge 1 commit into
Open
JuJuFX-dev wants to merge 1 commit into
JuJuFX-dev wants to merge 1 commit into
Conversation
ApplyAnchorPosition declared bCenterX/bCenterY inside the CENTER branch of
the placement if/else, but the pendingPositions write near the end of the
function sits outside that block. Lua read two never-set globals there, so an
element the anchor cascade moved during unlock mode stored { point = "CENTER",
x = nil, y = nil }. CommitPositions passes that straight to SaveBarPosition,
ConvertToCenterPos short-circuits CENTER/CENTER to "x or 0, y or 0", and the
saved position becomes the screen center. Invisible while the anchor stands
(the position is recomputed every apply), but the element jumps to the middle
of the screen once the anchor is removed.
Hoist the declaration to function scope so the write reads the values that
were actually SetPoint'd. Elements with their own grow direction are
unaffected: those take the growSkip path above and store { _anchored = true }.
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.
What does this PR do?
Fixes an element jumping to the middle of the screen after its anchor link is removed. In unlock mode, when an element is repositioned by the anchor cascade (because the element it is anchored to was moved or resized),
ApplyAnchorPositionrecords the new position for the eventual save. That record was being written with no coordinates: the local variables holding the computed center were declared inside theif/elsebranch that computes them, while the write sits after that block has already ended, so Lua read two globals that are never set and storedx = nil, y = nilinstead. On Save & Exit that nil pair is converted to0, 0, which is the exact center of the screen.Nothing looked wrong while the anchor was still in place, because an anchored element has its position recomputed from its target on every apply, and the saved coordinates are never used. Removing the anchor is the moment the saved position starts to matter, and the element then snapped to the screen center instead of staying where the user had left it. Elements with their own grow direction (Cooldown Manager bars and action bars) were never affected: those take a separate path that stores a marker instead of coordinates, and the marker path resolves the position from the element's live bounds at save time.
The fix hoists the two declarations to function scope, so the save record now carries exactly the coordinates the element was positioned at. No behavior changes anywhere else: the placement math, the pixel snapping and the idempotent skip guard are untouched, and the grow-direction path is unchanged.
How was it tested?
Tested in-game on live. The scoping defect was also reproduced outside the game with a small Lua 5.1 harness that slices the real tail of
ApplyAnchorPositionout of the file and runs it against stub frames: before the fix it shows the saved record holding nil coordinates while the element was positioned elsewhere, plus the two undeclared globals being read; after the fix the record matches the placement, and the grow-direction path still stores its marker.Checklist
HookScript/hooksecurefunconly, neverSetScripton Blizzard frames - N/A