So I’m using giant invisible parts to detect when a player reaches a stage, it has to be done on server because quite a lot happens when a player reaches a stage (they receive money, the stage runs a script, and the players graphics change)
The issue is the HUGE wait time for the server to detect that the player has hit a stage. I’m not sure if the issue is directly .Touched() or something to do with latency, but its massive in both studio and real game.
In this test, I have made the players boat get anchored when the server detects the hit. As you can see this is a huge delay.
(The issue is unrelated to the build being anchored as I’ve tested it with print statements and it had the same delay, this is just so it can be visualized better)
If I was to move the touch onto the client, how could I effectively detect when a player reaches the next stage? I could do a loop and check the X Position but I feel like that would be laggy as it would have to refresh relatively fast.
If this boat is connected to the character, then perhaps you could detect touch locally, anchor the player (again client side), then fire a remote to handle the other things associated with reaching a new stage.
Yeah I think I’ll do it like that, just curios through, is it heavy on bandwidth to pass through parts as a parameter? The easiest way to do this would be to fire every part the client touches if it matches a specific name, and compare it on the server to see if its a real part and if the client is allowed to even touch it.
.Touched is not a good option for what you’re trying to achieve - it just fires too late. Not sure why it lags so long in this case, but you should try other methods anyway. The fact that ping is relatively low means that checking this locally would yield undesired results as well.
Something like this could be a good option:
local boat = workspace.Boat.PrimaryPart -- a BasePart (eg)
local ChangedEvent
local function CheckPosition()
if boat.Position.X >= 4000 then
boat.Anchored = true -- insert code to make the boat stop
ChangedEvent:Disconnect()
end
end
ChangedEvent = boat:GetPropertyChangedSignal("Position"):Connect(CheckPosition)
The function will fire everytime the boat’s position is changed, but is way more reliable than .Touched. You can change that “4000” directly to a number or even better, to a value that changes everytime a user reaches a new stage.
As prevously suggested, operating with raycasting or Region3 could provide good results too, but you don’t need complex (and less performant) code since you’re working on a single axis (you just need a number value).
Then we would be in the same situation. If we used for example a while loop, the script will not give an answer on time once the boat reaches the target position, meaning that there would still be a noticeable delay (much less than rn tho) until the boat stops.
From your video, I do not exactly understand where you have placed the giant invisible part, that I assume has a Touched trigger. - If it is the “black solid gate”-thing, that the boat is passing through at time 0:03 in the video, then yeah, there is indeed something strange going on with your Touched event.
Have you tried doing just a print("Touch part triggered") as the first thing for the Touched event, and then when doing testing within Studio, looking at the output-panel, to see when the print occurs compared to where the boat is at that moment?
Perhaps you have code in your Touched event, that isn’t quite optimal? - Do you mind sharing this code?
Does this “a lot happens” involve any wait() or yielding statements? - As that could possibly explain the delay.
Very first thing I did was print statements, the issue isn’t with what happens on .Touched(), all that really happens is the block is checked for if it’s a player, the anchoring of the boat is purely for debugging purposes
You missed clarifying my assumption; where is the part that has the Touched trigger?
And additionally; are there more invisible parts with triggers in that video?
Perhaps the invisible parts are so thin, that - due to how collision detection works in games - when the player looks like he passes through the “trigger”, the player model is actually never at-a-point-within-the-trigger-area, due to going so fast.
it’s the black bricks, the detection happens just with a massive delay. There are more parts but none of them have a function with .Touched for this test
I see that there are many parts that boat consist of.
How efficient is your code in the Touched event, to discard/ignore anything that is ‘not a player’?
Have you tried adding a counter-variable to the Touched event’s function, that gets increased at every “touch” (and possibly printed), to determine if it is simply a “massively overload of parts” that causes the “huge delay”?
I noticed another topic, which could be an alternative method to detect when player passes some area:
Though constantly checking Region3 area / zones, have the same problem as with normal collision-detection; if the player is moving so fast, that the player model never actually is inside the zone, the code won’t be able to detect it.
Maybe instead of “slim check-point gates”, you create “pathway areas/zones” where server-side code checks when a player, that has last been seen moving around in “zone A”, now suddenly is moving around in “zone B”, it could be considered as an “having passed the checkpoint from A into B”-event.