However, I’ve been able to reliably reproduce definitely noticeable delays in Touched events on an empty BasePlate in test mode. In the following clip, I’m using the default LinkedSword to quickly swipe at the other player, and the hit is only registering fractions of a second after the blade touched the target. This causes a delay in damage/death:
The repro file used can be downloaded here: Repro.rbxl (14.9 KB)
The sword itself was inserted through free models, as the one in the toolbox is not functional in Studio (requires a module), after verifying that there was nothing abnormal with the source code. The LinkedSword from the toolbox can be used to reproduce the same problem in online mode, though you’ll need a second player to test with. To reproduce the issue using the repro file:
Start a test server and two players
Equip the sword
Lunge (double-click) and swing by the target player quickly
The hit will register fractions of a second later, as will the damage/death
Is there a way you can rig up something that prints out the delay? It’s hard to perceive it visually. Naturally there is SOME latency between your signal arriving on the client of the player you are hitting and jumping back. But I can’t see visually anything out of the ordinary.
I’ve created a new repro file that prints out the delay, and also slowed down the video so it’s easier to see the delay.
Here’s a clip of the original video slowed down to 0.25x (YouTube will also allow you to change the play speed to 0.25x, slowing the video down in total to 0.06x). As you can see, the first hit is registered pretty quickly, but the next one takes about a second in that video to register (~0.25 seconds realtime), so I don’t think this is an issue with latency.
Here is the updated repro file: Repro.rbxl (15.8 KB)
Both the client and the server listen for touch events. When the client detects a touch, it pings the server via RemoteEvent (LocalGui line 34). When the server receives OnServerEvent, it starts a countdown (SwordScript line 170). When the server Touched event is fired, it calls the blow function, and the delay between when the server received word of the touch via RemoteEvent and when the server received word via a server touch event is calculated (SwordScript line 34).
This should not be affected significantly by latency as the countdown only starts when OnServerEvent is received on the server. If the touch delay is < 0.2 seconds, it prints out normally, but if it’s >= 0.2 seconds, it displays a warning. Here is some sample data (from single, killing sweeps):
Hmmm, I wonder if the measurement could be seeing things in the wrong order. This 8 second delay happened after I stopped for a few seconds and attempt to measure it again. If the server event arrives AFTER the touch-event triggers on the server, there may be a weird mis-calculation.
I’ll see if I can clean this up tomorrow. Event UIDs could clean this up a bit.
Yeah, that’s an outstanding issue with the repro – I made sure to mentally filter those out. My thinking was that even if it was off by an event, that still wouldn’t cause a ~0.3 second delay mid-swing. But yeah, cleaning up the measurements would provide more concrete results.
Also, I’m not sure how you’re swinging the swords to repro, but it seems sweeping lunges that quickly leave the character (as displayed in the above videos) cause the delays noticeably more often than just an idle swing.
I’m having a hard time using the repro level you gave me due to overlapping events. I made one myself.
So apparently Touch Event replication happens at around 10Hz, so there could be a delay of around 100ms, however I noticed that TouchEvents between CanCollide = True parts were almost perfectly in sync, while TouchEvents for CanCollide = False parts took ~100ms to arrive after the remote signal.
Try out this test level and let me know what you think. However the highest I ever got it to go was a delay of 0.15 seconds.
Yeah, I’m not getting any issues in that place. Like I hinted at in my previous post though, the kind of movement seems to play a role in the delay of touch events. In the repro level I provided, just going back and forth at the target in a straight line didn’t reproduce the issue well – only the quick sweeping movements did.
It may not be presenting itself in that level because of the type of movement, or maybe because there’s some humanoid/etc-specific code for touch events that doesn’t reproduce the issue in that level, but as displayed in the YouTube video above there’s definitely something going wrong.