Skip to content

Add mutual invisibility for vanished staff - #237

Open
Zaldaryon wants to merge 1 commit into
indevfrom
feat/vanish-mutual-invisibility
Open

Add mutual invisibility for vanished staff#237
Zaldaryon wants to merge 1 commit into
indevfrom
feat/vanish-mutual-invisibility

Conversation

@Zaldaryon

Copy link
Copy Markdown
Contributor

Fixes #213.

What

/vanish hideothers on|off|toggle, a per-viewer preference. When on, a staff member stops seeing other vanished staff, without touching what anyone else sees. Also /vanish status, prints your own vanish state and this preference, changes nothing.

/vanish                          unchanged, toggle own vanish
/vanish status                   new
/vanish hideothers on|off|toggle new

New config default, Commands.VanishHideOtherVanishedDefault (bool, default false), the starting value for a staff member who never touched the preference. Default keeps today's behavior, vanish holders still see each other unless someone opts in.

Where it hooks and why

ShouldHideEntityFromClient(entity, client) already takes the viewer, not just the subject. The whole feature is one added branch there: non-staff still get an unconditional true, staff now return their own HidesOtherVanished(viewer.PlayerUID) instead of the old unconditional false. Nothing else calls this predicate directly, so no call site needed to change.

The tracking sweep in PhysicsManager.cs.patch won't despawn a hidden entity on its own at the range this issue is actually about. It has a hysteresis window, an already-tracked entity stays tracked as long as it's inside 1.21x the tracking radius, which is exactly two staff standing next to each other. So the toggle needs its own packet push or it silently does nothing at close range while appearing to work at long range. RefreshVanishedVisibilityForViewer is that push, the inverse of the existing HideVanishedPlayerFromOthers/RevealPlayerToOthers: those loop every client for one subject, this loops every vanished subject for one client.

HandleNear had its own inline copy of the old visibility rule (IsVanished(...) || PlayerHasAccess(...)), so it would have kept listing a staff member the viewer just chose to stop seeing. Updated it to match.

Testing

No test project in this repo, same live-boot convention as always.

  • dotnet build, zero warnings on the touched files.
  • Fresh boot reaches RunGame, no fatal errors.
  • Live test, one connected account (a second wasn't available this round): /vanish, /vanish status, /vanish hideothers on, status again to confirm the flip, /near with nothing to hide (no crash), /vanish hideothers off, then bare /vanish to confirm it still toggles vanish and not the preference. stratum-audit.log shows vanish hideothers=on actor=Zaldaryon, confirming the command path end to end.

What that doesn't cover: the actual mutual-invisibility effect needs two vanished staff who can see each other's screens, and RefreshVanishedVisibilityForViewer's despawn push is exactly the part most likely to be wrong in a way single-account testing can't catch (see the hysteresis note above, wrong and it's an invisible bug at close range and a working one at long range). Worth a two-account pass before merge if that's easy on your end, happy to do it myself if a second account gets easier to arrange here.

@trevorftp @tehtelev

Fixes #213. ShouldHideEntityFromClient already took the viewer, so
the whole feature is one added branch there plus the state that
branch reads: a per-viewer Dictionary<string, bool> override
(HideOtherVanishedByUid), falling back to a new config default
(Commands.VanishHideOtherVanishedDefault, false).

The mid-session flip needed its own push. PhysicsManager's tracking
hysteresis keeps an already-tracked entity tracked inside 1.21x the
tracking radius, so at the range this issue is actually about
(two staff standing next to each other) the natural tracking sweep
would never despawn a newly hidden neighbour on its own.
RefreshVanishedVisibilityForViewer is the inverse of the existing
Hide/RevealPlayerToOthers helpers: those loop every client for one
subject, this loops every vanished subject for one client.

/vanish hideothers on|off|toggle, plus /vanish status. Shares
Commands.Vanish, no new privilege. HandleNear's inline duplicate of
the visibility rule updated to match, so /near stays honest.
@Zaldaryon
Zaldaryon requested review from tehtelev and trevorftp August 7, 2026 01:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant