Are all Events Delayed?

For some reason whenever I make an event function, it doesn’t always run 100% every time the action that’s supposed to fire it happens.

Like touched events for example, when a part touches another part, it usually fires sure, but not every time. Sometimes it will delay 1-4 seconds before firing. Why is that? Is there a workaround for it to make it cleaner?

2 Likes

.Touched can be finicky, but the event should run the moment it ends up detecting that the two parts are touching. That’s odd.

2 Likes

Well that’s the problem, it detects it really late in any script, even without debounces I have made a script before that changes part colors every time it touches (without a debounce), sometimes it will delay with that as well.

This is how I scripted it too;

Part = script.Parent
Part.Touched:Connect(function()
Part.BrickColor = BrickColor.Random()
end)

I agree wih you. This event creates a massive delay to the server. The script is changing the part’s BrickColor at a speed of light. You may want to add a debounce as you said.

1 Like

Well even with a debounce it doesn’t change the delay. I’ve tried that as well, and proved it with some games I’ve actually released that have stuff like impact explosions whenever a fireball hits a wall or a mountain.

The problem is merely just that touched functions aren’t reliable unless client sided, which is an issue. I don’t see a fix to this since the server can’t really produce smooth enough transitions + Roblox has had it for years, so I guess I’ll just have to make everything that’s supposed to be detected client sided.

Yes, it is true that .Touched can be a bit glitchy, you should try using Region3 instead, it might work better.

https://developer.roblox.com/en-us/api-reference/datatype/Region3

Yeah region3 does work better, I’ve tried it and I like it. But at what cost? Projectiles can’t just spam region3 and expect the performance to be fine. It’s going to eat up all of that.

True, I suggest you report this to Engine Bugs?

Well I’m sure people have already reported this incident since it’s always been this way for years. I’m just trying to find a workaround. Region3 is nice, but it’s costy. Using a projectile with networkownership set to the main player seems risky too.

Even with magnitude, I’m sure there’s other ways to still abuse with it like teleporting the projectile onto other players. Plus magnitude isn’t reliable since you have to loop through all of workspace to detect. I’m sure that’s costy as well.

1 Like

Raycast to the next position the projectile moves to don’t use region 3. For bigger projectiles cast multiple raycasts throughout the part, (for eg the sides of the part).

Assuming your not using bodyvelocity and using custom cframe physics like me.

1 Like

Raycasting a projectile is still inefficient. I’ve tried with a bomb script, and sometimes the bomb will go through walls. If it gets to the point where I have to use 5-6 raycasts wouldn’t that be too much as well?

The problem with rays on the server is that like touched functions they fall back a bit while something’s moving. Except touched events delay instead of fall back.

I can manage 800 raycasts per frame at 60fps raycasting it’s not inefficient.

Do you mean when the projectile is moving or an other part is moving?

The projectile, also yeah I know you can use a lot of raycasts but for some reason even using Part.CFrame.lookVector as the second goal for Ray.new, it will still go through a brick wall like nothing happened.

Not really, the performance of rays are mostly dependent on their magnitudes, not the amount and you’re putting those rays on a bomb which those rays shouldn’t have that big magnitudes to begin with so they should work just fine without any performance issues.

The projectile shouldn’t be going through walls with rays that’s a problem with your code.

Events should always fire. If you are seeing a reproducible case in which an event does not fire at all, then it can be reported as an engine bug.

In your case though, it sounds like you are simply noticing the replication delay between the client and server. The length of the delay will depend on the speed of the client’s internet.

The typical workaround for this issue is to use event listeners on both the client and the server. The client should receive immediate feedback on their input. The server should then do it’s calculations, determine the actual state of the game, and update the game accordingly.

Here’s a Wiki Article from the Developer Hub which may help you to better understand this concept: https://developer.roblox.com/en-us/articles/Fighting-Against-Lag

it’s not a problem with my code, because i check if it detects a part and if it does it explodes. and it’s a loop that uses wait(), so there’s nothing wrong with it.

@Grargror I never said that the event doesn’t fire at all, I’m just saying that it delays sometimes which feels clunky. For explosions a delay for 4-5 seconds looks like it didn’t even get detected at all.

There is a problem with your code because I can assure you 100% this doesn’t happen to me when I use the same exact method.

Do you mind sharing your implementation? Also you should probably be updating projectiles based on delta time wait() doesn’t always wait the same amount of time use tick() or hearbeat.

while part do
wait()
local ray = Ray.new(part.Position, part.CFrame.lookVector)
local foundpart = workspace:FindPartOnRayWithIgnoreList(ray, Character:GetChildren())
if foundpart then
explode()
end 
end