✓ Accepted answer
Due to this script being executed on the server machine, you will need to remember that data takes time to travel -- thus nothing is immediate. From the given information I can assume that the reason for this delay is exactly this, latency. All parts that have their network ownership set to a client will have their physics as well as collisions calculated by that client. When you set a Touched event listener to an anchored part, the peer (a client or a server) starts listening for collisions on the object.
Now going back to the first statement of data taking time to travel: moving client parts and server parts will always be a little off-sync. This means that a server listening to collisions of a part will always get the signal a little later than the network owner sent it (unless the network owner is the server, but in your case I'm assuming the "toucher" is a player's character). There's simply no way around it, that delay will always exist. The faster the parts are, the more noticeable the effect is.
However, there is another issue in your code which has to do with the very same topic. A server making a change (such as changing a part's transparency) has to be replicated to the clients. It takes time for a client to receive this information thus causing a delay.
When you add these two together, you might reach a one second delay. The length of it depends on your connection to the server.
What you can do instead is have the clients listen to the collisions of the part by themselves. This removes the second replication step completely and works purely based off of what the client sees. Everything in that client's eyes will be smooth. In case you want to do something that isn't just visual effects, such as awarding the toucher 100 coins, you will of course want to have the server listening to the collisions as well.
There are great resources in the answer of this question if you want to study video game networking a little more.
1 comment
change your wait to a lower thing as like .5