Fix/Rotatable Shutter Placement#116
Open
rebaserHEAD wants to merge 6 commits into
Open
Conversation
ShuttersFrame had `noRot: true` on its Transform, which made Robust silently drop the placement rotation when the construction frame was spawned. Since the construction graph copies LocalRotation forward to each subsequent node, the finished shutter always ended up at the default facing regardless of how the player rotated the ghost. Commenting out `noRot: true` lets the frame keep its placement angle, which then propagates to the completed shutter.
The Shutters construction graph's frame1 node had no actions, so the freshly-spawned ShuttersFrame - an unanchored Dynamic body inherited from BaseStructureDynamic - was never anchored. When a shutter was built on an impassable tile (e.g. over a window, which the recipe allows via canBuildInImpassable), physics ejected the loose frame off the tile during the first construction step. The BlastDoor graph already does this correctly: its frame1 node runs SnapToGrid + SetAnchor actions on creation. Mirror that on the Shutters graph so the frame is snapped and anchored the moment it spawns.
Interaction reach checks raycast from the user to the target and treat
any anchored entity in the way as an obstruction. A reinforced window
sharing the shutter's tile blocked that ray, so construction steps
(e.g. adding cables to the frame) and later interactions silently
failed when a shutter was built over a window.
The engine already solves this for windows and firelocks with a
WallMount component, whose only effect is to exempt intersecting
anchored entities from interaction obstruction checks. BaseFirelock
uses `arc: 360` for exactly this reason ("interact despite grilles").
Add the same WallMount (arc 360) to BaseShutter and ShuttersFrame so
the whole construction lifecycle - frame, cable step, and finished
shutter - is reachable when a window or grille shares the tile.
Bring BlastDoorFrame and BlastDoorXenoFrame in line with the shutter fixes: - Remove `noRot: true` so the frame keeps its placement rotation, which then propagates to the finished blast door. - Add WallMount (arc 360) so construction steps and interactions work when a window or grille shares the frame's tile. No anchor fix is needed here: the BlastDoor construction graph's frame1 node already runs SnapToGrid + SetAnchor on creation, and both frames are static bodies, so neither drifts.
github-actions
Bot
added
S: Untriaged
YML
No C#
Triad-Sector
changed the title
The Shutters construction graph's frame1 node now runs SetAnchor on ComponentStartup (a706bcc), which flips Transform.Anchored to true and the Physics body from Dynamic to Static. PrototypeSaveTest diffs the spawned Physics component against the prototype yaml (Transform is skipped, Physics is not), so the Dynamic -> Static delta failed CI. Mirror BlastDoorFrame and declare bodyType: Static on the prototype. Prototype and runtime now agree, and the static body also prevents the unanchored frame from being shoved off impassable tiles.
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.
About the PR
So we had a few small but annoying shutter bugs piling up, and the blast door frames had the same shape of problem... bundled the fixes so it's one review instead of four.
Shutters
Blast door frames (
BlastDoorFrame,BlastDoorXenoFrame)noRot: trueso the frame keeps placement rotation and the finished door inherits it.WallMountarc 360 so construction steps (cables, etc.) and interactions still work when a window shares the tile.Why no anchor fix on the blast door side: the
BlastDoorconstruction graph'sframe1node already runsSnapToGrid+SetAnchoron creation, and both frame entities are static bodies. They don't drift, so no fix needed.Why / Balance
Pure QoL/bugfix, no balance impact. Shutters being non-rotatable and refusing window tiles made the whole "shutter for a window" use case impossible without console hacks. Blast door frames just inherited the same rotation lockout and lost interactivity any time a window shared the tile, so cabling them up was a coin flip.
Media
Small fix, exempt.
Requirements
How to test
BlastDoorFrameandBlastDoorXenoFrame, including the cable step on a tile that already has a window.Breaking changes
None.
Changelog
🆑