In normal circumstances I wouldn’t want to hard cap anything but in this specific circumstance let’s say that I have a specific function that sends an event to the server and the ideal amount of times it should be fired is at 60FPS, otherwise it would be too inefficient for practical use.
Yes I know this sounds like a bad idea, but it is actually extremely important that it is done this way.
I simply need to have the SendEvent function only be called at the same rate as it would be if someone was running at 60FPS and not any higher (as with an FPS Unlocker).
Just detect whenever RenderStepped returns a step value of less than 1/60. Alternatively, compare the FPS value with 1 / step. This is mainly on the client, not server.
You can’t throttle it without hurting the experience, but you could always do something else to work it out(i.e. kicking the player).
Unfortunately, your best bet is to make no assumptions of the framerate of the user. RenderStepped and Stepped should never be assumed to be any fixed frequency. If a user is running at 30hz, 60hz, 75hz, 90hz, 120hz, 144hz, etc or has any variations due to inconsistent loads (i.e. varying frame times), any assumption made about how often a function is called will be invalid.
RenderStepped (or potentially Stepped if you don’t need to run before the frame is rendered) with the frame time (time to render the frame in seconds) is what you should do whenever possible.
Sure. I created my own solution which was not exactly ideal but it will serve its purpose unless I find a more efficient method.
What I’m doing is sending the location of the client from the client to the server through an event to adjust the position of the character model more quickly. This provides a lot more accuracy in the position that the character model is placed for all other clients.
local sum = 0
game:GetService("RunService").Heartbeat:Connect(function(dt)
sum = sum + dt
if sum >= 1/60 then
SendEvent()
sum = sum - 1/60
end
end)
If theres a laggy frame it will account for the lost frames by sending events every frame, even if its not necessary, if there are too many frames it will wait multiple frames until sending the next event
Its no fixed rate but it will attempt to reach the goal of 60 posts per second, and will catch up or slow down to reach the set goal
You could even edit this to have a for loop which sends multiple events in one frame but I didnt think it would be necessary, itd be an easy addition if you do want it