Server-Side BasePart.Touched event not fired when part is deleted by client

If a part is created by the server, then deleted by the client. When a part of the client’s character touches the part, it is not fired on the server even though it still exists there. Normally, even though the part doesn’t exist on the client, the BasePart.Touched event should still be fired on the server because the part still exists there.

This bug happens 100% of the time, the touch is never detected by the server.

Here is a repro of the bug:
Touched Event Repro.rbxl (558.7 KB)
The server has a part with a script inside with an event that is triggered when the part is touched. It will print “TOUCHED” whenever it senses a touch.
In StarterPlayer, there is a LocalScript which deletes the part on the client’s side. The part still exists on the server.
When the client touches the brick, even though the part exists on the server, the touched event is not fired.

15%20AM

This happens in-studio and in-game. I would link a game but you can’t see the output there anyways.

This bug still occurs whether or not the part is CanCollide.

I am running macOS Mojave 10.14.5

I am unaware of when this bug started happening, but I found it by trying to make bomb hit-boxes non-existant on the client but still exist on the server so that you could shoot through them.

1 Like

This is not a bug – this is because of how physics work. The reason your character moves instantly on your screen (and not after some ms due to latency) is because it is in charge of its own physics. There are a lot of rules that determine whether you (the client), another player (another client), or the server own physics for a given part, but in general, your character and nearby unanchored parts are simulated by you.

When you have physics ownership of a part, the server just listens to what the owning client says is happening. This is why physics exploits like teleporting exist, and in this case, since the client doesn’t have any touch events to report, why the server is not firing any touch events.

8 Likes

If the part is anchored, you cannot set network ownership of that part. Therefore, you are unable to detect those touch events with the server. Do you know a way to get around this?

There is no other way around this, you either have to set the network owner of the character to the server(which is a veryyyy bad idea) or not rely on touched events at all. Another option would be to use Region3, however you would need to use an infinite loop.

If roblox were to allow us to set network ownership of anchored parts, what would be the downsides? Why are we currently unable to do so?

I honestly don’t know, but based on experience, Network Ownership is supposed to handle mostly physics. Unanchored parts need this system to create better environments that are physics based, otherwise we’ll all be in a laggy hell when driving vehicles, using constraints systems, render falling parts, etc. Anchored parts on the other hand do not need this because they do not simulate a lot of physics other than static velocity, conveyor belts for instance.

You could try posting a feature request about this issue, I think it should be considered that if a character touches a part on the server and not on the client, the server should detect the touched event because setting the network owner of characters to the server is just… no.

1 Like

Alright, I’ve created an engine feature request. Thank you for the detailed response.

1 Like

I just read your post and I just wanted to clarify some things with you because I think I may have caused some confusion. If you set the network owner of the anchored part to the server, it wouldn’t solve the issue, this is the current behaviour of anchored parts, the server automatically manages anchored parts, but the changes aren’t replicated if the client changes the position for instance. I also mentioned that:

Additionally, if the client has network ownership, the client manages the position, velocity etc. If the server has the network ownership, players can’t directly modify the mentioned properties. This is all just replication magic, except with physics involved.

Also it’s quite late for me, I’m gonna be off so I’ll probably answer any more concerns in a few hours or someone might answer them for me.

Alright, I’ve edited it to be specific to the touch event. Thank you for the clarification.

Anchored parts do not have touch events – they cannot move to trigger touch events. If you hook up two anchored parts with touch events and move then together with CFrame, no event will fire.

In this case, since one part is anchored, only the other part can trigger the touched event. This other part, part of the character, doesn’t know the anchored part exists, so it never fires a touch event.

The ability to set network ownership of anchored parts is not possible because anchored parts do not calculate physics (and if they did, all games would perform awfully)

1 Like

Anchored parts definitely do have touched events, I’m confused of what you are saying?

Anchored part touch events can only be fired by unanchored parts. Anchored parts do not do any physics calculations.

1 Like

Alright, so is there any solution to this? Shouldn’t server-owned unanchored parts be able to relay those touched events to the server?

Yes, but neither of those are the true in your case. The part you want to know has been touched is anchored, and the character controlled by the player is not server-owned.

Yes. Don’t delete the part on the client. Set Transparency=1 and put it in a collision group that can’t collide with anything. It will be ignored by raycasts because it can’t collide with the Default collision group, it will not physically interact with anything, it won’t be visible, but it will still exist and fire touch events.

1 Like

Why do you even need this to work? If you don’t want the client to see it just change the transparency/cancollide of the part client-side

The part is invisible and no-collide but it still gets in the way of the mouse and raycasts. I can’t easily add these parts to the IgnoreList either without considerable extra work.

Either way you would need an ignore list because you would (hopefully) then still have to verify the client-side raycast on the server.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.