FPSSetter:SetFPS(player: nil|Instance[Player], fps: number)player - Can be nil for all players or a player for just a single player (Defaults to all players)fps - The new FPS of the target player (Defaults to 60)I can see this being used in a old roblox simulation
Why use unnecessary OOP and a whole module just to set a client’s FPS when you can just use this function? The below function is better as it uses os.clock for the highest accuracy and as a replacement for tick since it will get deprecated soon.
local function SetFPS(fps)
local MAX_FPS = 1 / fps
coroutine.wrap(function()
while true do
local before = os.clock()
RunService.RenderStepped:Wait()
repeat until (before + MAX_FPS) < os.clock()
end
end)()
end
It “worked” in my tests. I could tell my fps was lower, though I have no idea if it’s the set value. Furthermore the approach taken here works because it allows SetFPS to be called and set from the server rather than the client which avoids remotes.
i.e. this in a script in ServerScriptService works:
local fpsSetter = require(game.ReplicatedStorage.ModuleScript)
game.Players.PlayerAdded:Connect(function(plr)
fpsSetter:SetFPS(plr, 60)
end)
Please re-read my post clearly before posting something completely irrelevant to what I said. There is 0% use of this as you can just use the above function and it doesn’t matter if it is server compatible, there is no usefulness in having the server deal with stuff that is supposed to be handled on the client directly.
But what I’m saying is it works, it works called from the server or the client, but doing it on the server can prevent exploiters from changing it or deleting it, which is completely relevant to games…
Just a small mockup to show that the fps is the set value.
My test isn’t testing for whether or not it’s “healthy” or efficient as that’s basically the opposite of why it was made it seems, considering roblox is locked to a maximum of 60 fps without an fps unlocker.
This is false information - doing it on the server will not make it any more secure. The exploiter can simply delete the local script being added or do anything with the attribute. This is why doing it on the server is useless, and you shouldn’t be handling FPS from the server anyways.
That’s not my point, my point is that you can detect the deletion server side and reimplement it. If the entire thing was on the client, they could just delete the script that adds the fps setter.
Your point still is false. An exploiter can very easily check if the script is added back again, and simply destroy it. There is literally no point of checking on the server side the deletion of the script because of this and you shouldn’t be. You would be essentially repeating your self.
If the entire thing was on the client, they could just delete the script that adds the fps setter.
They are ruining the game for themselves, not others.
PS: Let’s not derail the topic by further arguing, I’ve given enough valid points for your point being false. If you want to continue, PM me.
That’s why I said
not experienced exploiters who actually know what they’re doing.
My point still 100% stands on a valid base. This still can be easily bypassed by an exploiter and there is no point in checking from the server anyways.
That isn’t the point. You could simply
while wait() do
-- set FPS of exploiter
end
and it’d be practically impossible for them to delete all instances of the script. Unless, they are not script kiddies and create their own script to combat it.
Doing that from the server won’t do anything and that code is inefficient anyways. The exploiter can still hook up a event easily and destroy the added local script, or further more: have an inefficient while loop that constantly deletes any local scripts.
It doesn’t matter if it its an script kiddie or not, my point still 100% stands that it can still be spoofed with no effort. Further on, a exploiter can hook up a __namecall metamethod and have RunService.Heartbeat:Wait() return something else which would break the local script entirely. There is nothing you can do about it and hence, you should have your game still be somewhat playable with low / high FPS. :I
PS:
You shouldn’t have silly and inefficient implementations that can literally be bypassed with 0 effort. Your serverside code it self ( which is extremely redundant) is very inefficient and uses bad practices.
Hey, at least he tried making something cool. We aren’t focusing on security. This seems cool and I probably would use it.
Oh by the way, can we see it in action and explain this line of code?
Again, read my points clearly. My points were in response to Steven, not this module. Security shouldn’t even discussed in the first place here anyways of course.
Just a function which caps FPS with no unnecessary use of modules or the server dealing with stuff that is supposed to be dealt on the client.
wait what i am confused how can u get high fps while playing smthg like a showcase on a potato i am pretty sure i understood it wrong can u pls elaborate in the main post?
What he means is really limiting framerate. I don’t recommend doing it, but it’s useful for simulating old Roblox and stuff like that. The problem is really that you can’t limit it properly via Luau code.
If you want good fps limiting there’s the Roblox FPS unlocker.
but doing it on the server can prevent exploiters from changing it or deleting it, which is completely relevant to games…
You shouldn’t be handling FPS on the server, as this is a client issue. If you want to do it for a retro game feel, that should be up to the client to handle and should really even be an option in a settings menu. If you want it as a “punishment” for bad people, don’t… It’s toxic and better just to kick.
The reason why FPS specifically cannot be handled by the server is because the client receives their own physics simulation, just that is connected to the server. The server does not send the client any frames, just information on how to affect the simulation.
I hate to beat a dead horse but this is horrid, and I’m sorry for that awfully harsh remark, but this just isn’t how it should be done.
Don’t use OOP when it’s unnecessary. It’s crowded and harder to read in most cases.
Servers should never have to set your FPS. The server is just wasting resources using this.
Remotes vs. replicating the entire Bytecode and Serialized script to ALL clients. You choose.
To Elaborate on 3, a remote using :FireClient(Plr, int) has a far, and I mean FAR smaller byte allocation than a serialized Local Script being cloned and replicated. It also consumes server memory to hold these items until garbage collection deallocates that memory address. PostEvent(TargetPeer,RemoteID,PostSerialized) vs. !pseudocode! for Client in Players do PostReplicate(Client,SerializedLuaSourceContainer) end
I noticed this late, but you using Attribute changes is also replicated, therefore even more bandwidth wasted.
Use proper pre-definitions for future code, it’s a good practice and will generally help further along.
local Players = game:GetService("Players")
-- Also note, do not use absolute paths like game.Players, this is bad
-- practice. Use safe functions i.e game:GetService('ServiceName')
And to top this all off, thank you for your attempt. This may be a resource category but we’re here to review, critique, and to provide constructive (usually) criticism.
I hope you’ll read this and take some pointers off of it.
I myself accept any criticisms the community has, be it on something about replication/remotes I was incorrect about or missed entirely. (EDIT: *or anything repetitive I may have done, I’m quite tired at the time of writing this, Early morning 7/1/2021)
Sincerely, IDoLua.