I’m working on a shooter right now, and here is one of the checks I’m doing to prevent firing faster than your gun allows for.
runTime is defined as tick() just a few lines before this (there is no yield)., and shotTime is defined on the client as tick() again.
The point of the sanity check is to see when the client says it shot the gun, make sure that wasn’t too long ago, or in the future.
if ((runTime - shotTime > 1) or (shotTime > runTime)) then
--basically we don't accept input if their shots have more than 1s of ping
--or if shotTime > runTime, i.e ahead of the server
warn'00'
return false
end
In studio, the result of this sum runTime - shotTime accurately returns the player’s ping, what you’d expect. However, in game, this returns something just more than -3600s
shotTime will always be greater than runTime since it calls tick() later than runTime thus keeping your sum a positive number and also the desired number.
it would probably be easier to just use a server debounce
local enabled = {}
local enableDelay = 1
if(enabled[player.Name]==true) then
enabled[player.Name]==false
spawn(function()
wait(enableDelay)
enabled[player.Name]=true
end)
else
print("[Server]: Player has to wait before he can do this again")
end
and I don’t think that’s how you get the clients ping if its showing -3500.
I would not agree with this band-aid method for something as time sensitive as a sanity check.
It would work in instances where time isn’t precious but it’s not the best way to do it.
the time isn’t precious though, its an input event.
his time won’t always be the time he is looking for, and the player can use input as fast as they want.
I never said that it wouldn’t work. I’m talking about efficiency. Calling spawn on input in excessive amount could potentially lead to unwanted memory increase overtime.
wrong, the spawn() will only fire if the event is enabled, which prevents it from getting spammed in the first place. (which is the whole point this post was made)
This isn’t true - sorry if I explained myself poorly. shotTime is declared on the client, and then sent to the server, so it will always be called prior to the server.
The actual reason is because tick() is dependent on the computer’s clock which is subject to time zones. Our clocks got set forward an hour recently, so I need to find an alternative way of doing this.
The alternative I will use for this is just to ensure that the shot wasn’t sent before their last one
@codyorr4 this method fails because of the complexity of dealing with a high amount of network events or close together. If rate of fire is 60RPM, i could get two shots .9s apart because of ping fluctuations. It would be a horrible experience to not allow for that.
Ah, you could just resort to creating a world time that is being increase by each step of the server.
Client sends the world time it sent and the server uses that world time for the sanity check.
I would probably hook up the increment with a Stepped event from RunService.
I’m not sure how accurate this is to what you’re wanting tho’
lol but it’ll be the same fire rate even with your math. (not to mention players could just spoof their os time with RunAsDate injectors lol) @Nicolas_Caged
The actual reason is because tick() is dependent on the computer’s clock which is subject to time zones. Our clocks got set forward an hour recently, so I need to find an alternative way of doing this.
That’s actually very weird I didn’t think that time zone changes would affect tick() since it always counts in seconds from the beginning date to the present. I don’t think tick should of been affected by a timezone change at all because it’s not like we’re speeding up time itself.
But whatever, hopefully any of us was helpful in the end.
