Mechanism to exclude anchored users from collision events/CharacterParenter

[shiftyscales]

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

Following up from build 2021.6.7.794:

-- 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.

A scenario has recently come up in which the tweak to enable collision events in anchors has caused issues.

In particular, if a CharacterParenter is overlapping an anchor, the character parenter will re-parent the anchored user under it, causing issues when the anchor is moved- the user remains in place/is separated from the anchor, and if the anchor is using pose nodes, their avatar is pulled away from their current position.

Relevant issues

2358

Describe the solution you'd like

Add a mechanism for the dummy character controller/anchor to ignore collision events for components such as CharacterParenter

Describe alternatives you've considered

Additional context

Replication world: http://cloudx.azurewebsites.net/open/world/U-Shifty/R-e6eb55e1-c34e-472a-8317-3505ee77d73e Replication:

• Enter anchor (box)
• Note you aren't nested under it/don't move with it
• Exit anchor
• Disable character parenter
• Re-enter anchor
• Note you do move with it/are nested under it

[TehTurk]

I ran into this initially last week I'm happy there is an issue for it already. If anything It'd be neat if it could be toggleable in some form as I could see this being a useful feature if users could control it.

[H3BO3]

This is getting some more attention, it would be good if characterparenters didn't work on anchored players - At least while the player is in an anchor. If they get out within the same characterparenter they should get parented underneath it, I'm unsure how complicated that would be however.

[Sharkmare]

Would be good, but should be optional, personally want this too yeah

[H3BO3]

I disagree, players shouldn't be getting pulled out of anchors like that. Anchors originally excluded players from collision events, but since that was changed to let anchors work with various collision-based culling system, it introduced this side effect. There are likely other things that might cause issues related to this, but characterparenters are the most common.

[Sharkmare]

I disagree, players shouldn't be getting pulled out of anchors like that. Anchors originally excluded players from collision events, but since that was changed to let anchors work with various collision-based culling system, it introduced this side effect. There are likely other things that might cause issues related to this, but characterparenters are the most common.

So what if someone wants that behaviour though that is the current one?

[H3BO3]

It was never an issue in the first place because it didn't happen. Nobody wanted that before.

[Sharkmare]

It was never an issue in the first place because it didn't happen. Nobody wanted that before.

Guess thats a good point

[TehTurk]

Ideally the default (On Anchors) should be "no interaction" (Since that is what the default used to be, and will work backwards pretty well) and on the anchor itself there should be an option to enable its ability to still "keep" the character collider on while one is in the anchor. Allowing for Character Collision Interactions.

[H3BO3]

No, I think there needs to be filtering for specific components that are known to disrupt anchors, like the characterparenter. What you suggested will not work backwards if people have set up culling or other trigger zones as part of their world for whatever reason and need them to operate with vehicles.

[TehTurk]

I mean it's a bit of both, what if someone makes an item to not be affected by CharacterParenters? World Compability vs Item Creator

[Frooxius]

I think this is best solved by adding a few options for creators to setup their content based on the needs:

• Ignore anchored users (or otherwise with suppressed locomotion) in CharacterParenter
• Unanchor the user (the current side effect, e.g. if you want to scoop the user out)
• Parent the root of the AvatarAnchor with the player in it - e.g. if the user is in a vehicle, make the whole vehicle parent itself in the new space. That way some of the uses of CharacterParenter can be preserved. AvatarAnchor would probably need to specify the root though and whether there is one, so it knows what to parent.

We can add option to AvatarAnchor to not have the collider at all, but that would bring back the old problem of breaking the collision events, so I think that's less preferable than a more fine-grained solution that would solve the issues, while keeping the new benefits.

[H3BO3]

I think those options sound good for avataranchors. Maybe the default could be ignore?

[TehTurk]

This sounds good, but If your open to it I would still suggest we have the option for AvatarAnchors to toggle the collider. Afaik Anchors were actually desired for their ability to not have collision events initially. Unless it's unideal to have both solutions.

Because when you hop into an anchor you as the user shouldn't really be expected to be "yoinked" out of it unless you decide to exit. It also adds back compatibility for most anchor creations as right now some older systems have broken afaik. (I was running around with the old Corgi's Gearbell had issues I think due to the change.)

[H3BO3]

How are the corgis involved in this? Last I remember, the lances on those used logix and nearest user head to unanchor the user so they got around that. If you're referring to another mechanic it would be good to know more about it.

I can agree that option should be there, but it should default to interacting with trigger colliders for obvious reasons. If that was implemented along with the other options I would be fine with that. I would especially love the third option since it means my ships could interact with characterparenters, etc.

[TehTurk]

The actual movement of the corgis. Apologies as they were some of the earlier ones that had used CC physics for vehicles so I know some of those interactions broke with the anchor change. (But honestly I need to double check it's been awhile and I want to actually have repro or confidence in that being the case) I was just considering back combatibility with previous anchors setups in mind.

[H3BO3]

That's basically what all vehicles do for now. What specific interactions broke?