Sitting in Anchors excludes you from ColliderUserTracker

[AshtonSparx]

Is your tweak request related to a problem? Please describe.

When you're sitting in an anchor, ColliderUserTracker can no longer track you, even if the anchor is inside of the collider. This can be problematic, especially when wanting to setup culling systems for optimizations, disabling certain parts of the world when a user is in it, ect

Describe what would you like tweaked

I would like ColliderUserTracker to be able to know when you're in the anchor. Users have chairs and stuff on their avatar all the time, it can ruin the fun if things get culled while you're in it.

Describe alternatives you've considered

I'm not sure of any alternatives. Can try working around it with different culling methods but that wont fix the issue.

Additional context

Standing in the BoxCollider Sitting in the anchor that's in the BoxCollider (Ani is a friend standing in the collider)

[H3BO3]

I agree with Ashton's assessment - Culling structures need to work with users in anchors. However, I have concerns over trigger collision behavior that would reparent users (such as characterparenters, if that even is a problem). I'm curious to see what Frooxius says regarding potential conflicts. Preventing the reparenting of users in anchors seems viable.

I also know @Enverex would be interested in this.

[AshtonSparx]

I've seen worse situations where anchors break things or the user. I know a user who uses ColliderUserTracker to enable parts of the world when you enter a portal. But if the user gets into an anchor, that entire section vanishes, which is made twice as bad if you parent users under that area for which ever may that reason be.

[shiftyscales]

I can definitely understand the use-case in this, noclip also presents a problem for a similar reason.

For personal projects I've gotten around this issue by using a MultiBoolConditionDriver (Transform > Drivers) to account for these scenarios coupled with a couple of small Logix strings to act as detectors for when a user is in noclip or an anchor:

[TehTurk]

Isn't this a bit impossible tho? Generally when your in Anchors you have No CharacterCollider or CharacterController whatsoever right? Wouldn't you need that currently while in anchor to work?

[H3BO3]

@TehTurk hence why we are saying this needs to function somehow...

[AshtonSparx]

I can definitely understand the use-case in this, noclip also presents a problem for a similar reason.

For personal projects I've gotten around this issue by using a MultiBoolConditionDriver (Transform > Drivers) to account for these scenarios coupled with a couple of small Logix strings to act as detectors for when a user is in noclip or an anchor:

Super informative, however, this feels like a hacky work-around till this is patched when froox is off his well-deserved break <3

Side Note: aren't boolean latches global? Like, you can't localize the output without other hacky methods?

[TehTurk]

@H3BO3 Well that's the thing, when Character Controllers are added they have an inherent Collider tied to it (You can't see or interact with it, but it's always there(wish we had debug visuals for it)). But the Anchors also act as a good way of keeping data/performance synced/accurate but also cutting back on overhead (Less Character Physics, the Anchor becomes in charge of tracking player position). So I figured you can't have both naturally combined in a design sense.

Did we ever try just having a Character Controller on an anchor? (Putting the User into the Simulating User) I think it would behave in the same fashion no? That's how alot of the vehicles behave right now. But unsure if the Capsule Collider effects carry over for user Tracking. I suspect the UserTracker Goes Collider->User->Tracker but with the Anchor it'd be something like User->Anchor->Collider->"No User"->Tracker

So ideally you'd be forcing the collider in some scenario. Maybe something like "Forced Controller" -> User -> Anchor -> Tracker

[H3BO3]

The charactercontroller is already a hacky way of making vehicles. This isn't a question of what workarounds could be done, or even about charactercontrollers at all. Please don't pollute the discussion.

[shiftyscales]

@TehTurk - You're proposing using the character controller component out of its intended scope. It's being used for vehicles as a shortcut to physics, but that's outside of its intended use-case/will likely eventually break.

That aside- that's the reason we keep things generic rather than pitching specific solutions is so that our developers can assess/understand what the underlying issue is, and how best to address it.

It appears that anchoring a user applies that anchor onto the SupressSources (list): on the LocomotionController component found on the user root slot. If the suppress source is removed, the user is tracked in the collider user tracker, but when that happens, your avatar falls through the anchor as it becomes physically simulated again/has gravity applied.

This is an intended mechanism, but perhaps one that could be re-evaluated/re-designed slightly.

And you do have a character controller while anchored still if you are in a physical locomotion. You can demonstrate this by entering an anchor and using the Find Character Controller node to demonstrate this. The issue appears to be that it is suppressed while inside of the anchor, presumably designed to do so to prevent other issues.

[TehTurk]

I'm not polluting the discussion. I'm bring up these points to consider what options are, or what's required in scope. Please H3BO3

@shiftyscales Nah I know that, it wasn't like an "intended" ideal scenario I wanted to entertain, but to also bring up some of the pain points with the issue. Hmm Ok, but it still seem like the Problem of User Collider and Anchor interfacing are a bit opposite of one another. I mainly brought up the Character Controller as whether it's Capsule Collider is interacting with the Physics Loop or not. Anchors are typically outside that realm of being apart of the loop, so it's either you have like both active, or you choose one and stick with one.

Collider User Tracker I'm aware largely relies on the Simulated Capsule Collider that is made when the CC is "On" so it's like combining the two sounds tricky

[H3BO3]

@TehTurk Like Shifty said, it's not a good idea to overanalyze the problem or try and figure out a specific solution - All of what you are discussing assumes the confines of the way things are. We have no idea how Froox might approach this low-level behavior, so it is not necessary to discuss it.

[AshtonSparx]

I'm sure Froox will be able to brainstorm a way to allow for ColliderUserTracker to work in anchors. It's probably a simple fix and we're just trying to think inside of the box instead of outside of it.

[Frooxius]

Fixed in 2021.6.7.794!

• A dummy character controller is now activated when no locomotion module is active (e.g. when sitting in an avatar anchor or when all are disabled by permissions) -- This fixes users in avatar anchors not being tracked by ColliderUserTracker and being excluded from culling systems and events -- If you run into issues where you need the user to be excluded from events and such with your avatar anchor, let us know and we'll add a mechanism to provide this. Currently I'm not sure if there are any use-cases for this.