Write two scripts, one for anchoring & unanchoring player’s character on client-side. Another one for handling Touched event & printing when the player’s character touches the big part. Let the player spawn and get inside the big part (has no collision)
Expected Behavior
The Touched event fires and prints “Touch Detected” once because the player only spawn and get inside the big part, as long as the player doesn’t go out and come inside, it should print once, even when the character is constantly anchored & unanchored
Actual Behavior
The Touched event actually fires every time the character is anchored & unanchored.
Where It Happens
In studio & In experience.
Date
Began Experiencing: February 9th 2024 - 12:46 PM (GMT+4)
I think what’s going on with the client-side repeated anchoring is related to how the owners of parts are the ones that tell everyone else when a Touched event occurred. In this case, that would mean your client telling the server when your character touched a part to fire .Touched, a side-effect due of the owner of a part being the one running it’s physics simulation.
What I noticed was that anchoring it on the client caused the client to think someone else took control of it, but the .Anchored property doesn’t replicate, thus the client was still in control of it, the server acknowledged it as so, and I speculate that the physics information about what parts the client is touching gets lost because the client disowns parts it should be in control of, attempts to transfer the information, find nothing, and throws it into a black hole. Thus, when the character is un-anchored and the client resumes control of it, it thinks that the client just started touching the parts it was already touching and re-fires the .Touched signal.
But, that’s just my theory. It seems to be supported by the physics debug visualizations showing that the server never assumes ownership of the character when it’s anchored clientside, as anchored parts do not have any physics simulations and thus do not get the ownership outline visualizations. Meanwhile, the outlines disappear on the client because it’s anchored from their perspective.
Yeah, I think a good analogy would be thinking you’ve ended a call (the client anchoring their own character), but then missing the “End Call” button (the server is never told about the anchoring) and putting your phone away (the client forgets the touching data) instead, then wondering later why you have a call open (and the server never telling you what the conversation was, because it thinks it’s still going on, because you never hung up, so you repeat the conversation i.e. the .Touched event).
Assuming my theory is correct, and, yes, I absolutely take all my analogies to the bitter end.
The Anchored property determines whether the part will be immovable by physics. When enabled, a part will never change position due to gravity, other part collisions, overlapping other parts, or any other physics-related causes.
When you anchoring a part, it disables physics simulation. touched is a physics simulation based event. Internally, whenever a contact is detected/undetected, a touched or untouched event will be fired. So every time when you unanchor a part, the physics simulation is activated on the part; then a contact is detected, and touched event is triggered.
