Repository navigation
Add a setting that starts new stands out of shift use, and mark a stand while its buttons are hovered - #28
Merged
Merged
Conversation
…say what the pooling setting leaves on Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <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
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.
Every outfit stand starts in service. It reads its room, holds "Allow removing items" off and keeps its contents out of trade, whether or not the room gives it anything to dress for. A player with about 30 stands asked on the Workshop page for a way to stop new stands becoming shift stands, because the only way out was opening each stand's settings in turn. This branch adds a mod setting for that, and corrects the description of Unassigned stands are shared, which promised more than the setting does.
The same request raised a second problem. With several stands selected, each stand shows its own switch and Set owner button, and nothing on a pair says which stand it belongs to. Hovering either button now marks its stand on the map.
The setting
New stands are used for shift changes, on by default and first in the mod settings. Turned off, a new stand starts as "Not used for shift changes", which leaves it vanilla: the removal toggle is the player's and the contents can be traded.
It is read in
CompShiftStand.PostPostMake, which onlyThingMaker.MakeThingreaches (throughThingWithComps.PostMake). A finished frame makes its building that way, inFrame.CompleteConstruction. A load builds the comp inThingWithComps.ExposeDatainstead and readsexcludedback from the save, and a stand boxed and set down again is the same object (MinifyUtility.MakeMinifiedkeeps it as theInnerThing). So flipping the setting changes no stand that already exists. A stand bought from a trader takes the setting as it was when the trader's stock was generated.DebugTools_Fixtures.Spawnnow puts every stand it makes in service, so the harness and the media stages do not depend on the profile they run in.The pooling description
With Unassigned stands are shared off, the description said every unassigned stand "behaves exactly like vanilla furniture". Such a stand dresses nobody, but it is still declared in service, and the removal-toggle lock and trade withholding key on that declaration (
Patch_AllowRemovingToggle,CompShiftStand.BlocksTrade), not on whether the stand has an owner. The setting's behaviour is unchanged. The keyed string, the code comment, the README and DESIGN.md now say what it does, and point at "Not used for shift changes" for a stand that should be ordinary furniture.The hover mark
Both buttons set
Command_Action.onHover, whichMapGizmoUtility.MapUIUpdatecalls every frame the button is hovered, from the map interface's update. It callsCompShiftStand.PointAt, which draws two vanilla marks:TargetHighlighter.Highlight, which a storage link's button also shows on hover. Within nine cells of the screen centre it sits just below the stand and points up at it. Further out it is drawn seven cells from the centre and only gives a direction.GenDraw.DrawTargetHighlight, the pulsing square a targeter puts on the thing under the cursor, drawn above the building layer. It marks the stand wherever it is on screen.The highlighter can also draw a circle, but it is drawn at the building's own altitude with a radius of half the footprint, and in lab captures the stand's sprite and the selection brackets covered nearly all of it. The Set owner button is the base comp's gizmo, so its hover is chained: anything another mod put there still runs, then ours.
Testing
HarnessTriggers.NewStandSettingDecidesOnlyNewStandsmakes stands throughThingMaker.MakeThing. With the setting on, the new stand is automatic. With it off, the new stand is excluded and stays excluded once spawned. Spawned with "Allow removing items" on, it keeps it on, where a stand in service would force it off, and its contents can be traded. The fixture's own stand, made before the flip, stays in service.The save round trip (
DebugTools_SaveRoundTrip.RoundTrip) now loads its save with the setting off and asserts the loaded stand still comes back in service.HarnessGizmos.HoveredButtonsMarkTheirOwnStandspawns a second stand and callsonHoveron all four buttons. It reads the arrow fromTargetHighlighter's private arrow list, and the square fromGenDraw.CurTargetingMat, whose getter rewrites the material's colour each time: a colour set beforehand changes only if the square was drawn. Each button has to mark its own stand and not the other. Then the second stand is destroyed and a switch taken from it beforehand is hovered, which has to mark nothing, since vanilla keeps calling the last hovered button while another main tab is open.Three mutants were run against it, and in each this case was the only one to fail. With the square removed from
PointAt, the five lines that need it fail, each still reporting one arrow. With the map guard removed, only the destroyed-stand line fails, because the square is drawn for a stand that is gone. With the Set owner hover removed, both Set owner buttons fail their "has a hover action" line.Six of the gaps are mods not on the list: Outfit Stands Plus, Complex Jobs, Common Sense, Pick Up And Haul, and Rimatomics twice. The seventh is the recolor case, since only Odyssey is active. The run was on this branch's head.
check-invariants.pypasses, andcheck-shipped-dll.pypasses on the Release build the runner leaves behind and on the committed dll.Not covered
The setting's case has not been run against main, so it has not been seen failing. No stand has been built from a frame in play with the setting off: the case calls
ThingMaker.MakeThingdirectly, which is the call the frame makes.The two marks have been seen only in lab captures on 1.7 at 1920×1080 with 30 stands selected, hovering one stand's switch near the screen centre and another stand's Set owner button far from it. Those captures predate the review changes, which reworded comments, chained the Set owner hover and extended the case, and changed nothing that is drawn. The chained hover runs no other mod's code here, since no mod on the list adds a hover to the Set owner button.
Left out on purpose
The dll is not in this branch; it is built and committed at the release merge. For translators, two English keys are new (
ShiftChange.SettingNewStandsInServiceandShiftChange.SettingNewStandsInServiceDesc) and one is reworded (ShiftChange.SettingPoolUnassignedDesc); the hover mark adds none. Editing several selected stands at once, the other half of the same Workshop request, is a separate change.🤖 Generated with Claude Code