Is it possible for 2 consecutively fired events to have a smaller wait time between them than expected? [Solved]

[Mioxity]

Bit of a weird question but would it be possible for 2 events like this to be received by the server with a time of less than 5 seconds on the server side :

	game.ReplicatedStorage.RemoteEvent1:FireServer()
	task.wait(5)
	game.ReplicatedStorage.RemoteEvent2:FireServer()

The reason I ask this is because I am thinking of having an anti cheat system like this to prevent players from firing the two effects too quickly one after the other on the server side :

game.ReplicatedStorage.RemoteEvent1.OnServerEvent:Connect(function(plr)
	
	local StartTime = tick()
	
	game.ReplicatedStorage.RemoteEvent2.OnServerEvent:Connect(function(plr)
		
		local timeDiff = tick()  - StartTime --Time difference between when event was received and event 2 was received
		
		if timeDiff < 5 then
			plr:Kick("Second Event fired too quickly")
		end
		
	end)
	
end)

This seems to be a very good way from my perspective but I am worried that if the player is on very high ping during the first events firing then their ping drops a lot when the second event fires, the second event will arrive sooner than expected due to the original event being delayed. So it is important for me to know if the firing of an event can speed up mid way through its travel to the server or not. I don’t want people being kicked just for having unstable internet.

[batteryday]

Yes.

If the first event takes a long time to arrive, and then the second event arrives quickly then the delta will be less than 5 seconds.

[Mioxity]

Do you think it would be reliable to send the ping of the player during the first event in the parameters of the second event and adding the time to the delta to account for ping or is it too risky? Because you see I need the second event to give me the players mouse position after the first event is fired and I don’t see any other way to make this less exploitable. Something like this :

game.ReplicatedStorage.RemoteEvent1.OnServerEvent:Connect(function(plr)

	local StartTime = tick()

	game.ReplicatedStorage.RemoteEvent2.OnServerEvent:Connect(function(plr,ping)  --Gives ping when first event was fired

		local timeDiff = tick() - StartTime + ping --Time difference between when event was received and event 2 was received

		if timeDiff < 5 then
			plr:Kick("Second Event fired too quickly")
		end

	end)

end)

[batteryday]

No. Any information coming from the client can be changed and tampered with.

[batteryday]

Also unrelated, but you never want to have event connections inside event connections (maybe there are rare exceptions, but almost never)

@Mioxity

game.ReplicatedStorage.RemoteEvent1.OnServerEvent:Connect(function(plr)

	local StartTime = tick()

	game.ReplicatedStorage.RemoteEvent2.OnServerEvent:Connect(function(plr,ping)  --Gives ping when first event was fired

		local timeDiff = tick() - StartTime + ping --Time difference between when event was received and event 2 was received

		if timeDiff < 5 then
			plr:Kick("Second Event fired too quickly")
		end

	end)

end)

Each time the client fires the first remote a new connection to the second remote is made. You want to take that out.

[Mioxity]

I could ensure the ping the client sends is not a negative number to make the tampering of the ping not useful to them since making the ping higher will just result in a kick anyway?

[Mioxity]

I make sure that the second event is a :Once() and not a connect to ensure no memory leaks already, that was just an example script

[batteryday]

The client can send any value as their ping. If you kick them for taking too long to respond then you will also kick regular players who just have high ping. There are no ways around it.

---

@batteryday

If you kick them for taking too long to respond

Referring to tracking ping with a RemoteFunction

[Mioxity]

But is that relavent since they will get kicked for responding too quickly not for taking to long and since ping can only be a possitive number in reality, adding any amount of ping to the delta wont result in a kick, only subtracting
Edit: I am dumb , just realsied what i said XD

[batteryday]

Just read the Exploiting Explained thread.

Exploiting Explained

Exploiting Explained: Second Revision This post is a general information source on common exploiting terminology, tools, and methods. The formatting is in sections for each specific topic, and is in no specific order. If you’re not aware of exploiting by this point, you’ve probably been living under a rock that the pioneers used to ride for miles. While Roblox is seen as open grounds for free reign of exploits, this isn’t the case, and I attempt to tackle this wrong assumption in this post. Th…

[Mioxity]

How would you propose I get the players mouse after a certain amount of time after the first event is fired?

[batteryday]

If you want the clients mouse, they have to send it to you. (remember they can send you anything)

[Mioxity]

So is there no way I can avoid the double event to get the up to date mouse value when the 5 seconds are up?

[batteryday]

I strongly recommend reading the Exploiting Explained thread. Specifically the part about communication with the client. This thread will tell you everything you need to know. Good luck!

@Autterfly

Filtering Enabled & Exploits

A good way to get started is to echo what you always hear: under no circumstances should you trust the client with authority over your server game logic. When implementing your RemoteEvent and RemoteFunction code remember to think as the attacker. Your code should be built around thinking, “if I had absolute control of my client, what could I send over this bridge to break everything?” Design should be based around asking the server “can I”, and not telling it “I can”.

Think Offensive

A simple example is a store; ask the server, “can I buy this sword?”, and don’t tell it, “I can buy this sword.” The server should be the one checking everything from currency to experience points to levels, since it has the final say in what’s really happening. You should always be ready for someone on the other side of the bridge to outsmart you, and make absolutely certain the code you wrote is well tested for cases like someone throwing a NaN at you or expecting an object and getting a table that looks like an object.

A really common pitfall is the attempt to “secure” your remotes, or “validate” your data, and anything that is done client side. As a pro-tip: anything coming from your client will not be secure. It doesn’t matter how clever your system looks, or how much time it took you, you’re not the one in control of your client. If it makes you sleep better at night, the extra headache is okay, but you should not be relying on it to ever really work.

Think Defensive

Some exploits don’t actually rely on remote exploitation, but instead in simple things like Roblox’s rules of replicating properties. You might encounter these exploits in the form of flying, super jumps, or speed hacking. The issue stems from the fact that players have physics ownership over their characters for smoothness and fast feedback, but in turn this gives them the ability to move them anywhere. You can mitigate these on the server, or add basic checks on the client, but be sure to remember you can never actually rely on the client.

Stop Thinking

Lastly are maybe some of the peskier exploit types which are just plain local enhancements. These are usually undetectable via conventional means, if at all. You might see these in the form of aim-bots, auto-hotkey style scripts, and general automation of game-play.

[Mioxity]

Sorry again this is just an interesting topic, but I just realised , since the ping can be tempered with, why not just get the ping on the server side by doing Player:GetNetworkPing() like I have done here

Edit: Ignore the errors, just some other script

[batteryday]

I just went back to the top of the thread and reread what your goal is.

@Mioxity

to prevent players from firing the two effects too quickly one after the other on the server side

If you don’t want something like a bullet to be fired more than once per second then what you do is you track the time on the server. Not the time between events.

We have been talking about the wrong thing this whole time.

But it’s my fault because I didn’t read your whole original post carefully to see what you were trying to accomplish and immediately just answered the question in the topic subject.

A basic setup looks like this:

local debounces = {}
remoteEvent.OnServerEvent:Connect(function(player)
      if not debounces[player] then
          debounces[player] = true
          ----
          -- Action code here
          ----
          task.wait(1)
          debounce[player] = false
      end
end)

This is a basic debounce which ensures that only one “action” will run per second no matter how many times the remote is fired. It doesn’t require knowing the clients ping. The server doesn’t really care when or how many times the client fires the event, it will only run the function once per second.

Sorry for going down the rabbit hole and ping, this is the answer you were looking for.

[Mioxity]

Oh but how should I get the new mouse.Hit value in this case? Because I want the player to be able to aim at the end of the throwing animation, not the start.

[batteryday]

Send Mouse.Hit as a parameter in the RemoteEvent. Only fire the Remote at the end of the throwing animation. You don’t need to tell the server when the animations starts.