That is physics rate, not client FPS if im not mistaken.
Me when you donât understand lets say roblox added a security fix to the client and there was a FFlag to disable it.
Anyone could technically write their own operating system and emulator, and use a memory viewer and circumvent any form of client-side protection Roblox has. Anyone can mod the engine if they really wanted to, given enough time and effort. But, compare spoofing an API response to⌠just saving a .json
file? They are very different things. They take require very different amounts of effort to achieve. Someone could easily justify adding 1 folder and 1 file to 1 specific directory that the client blindly reads, they arenât even modifying an existing file. But, spoofing an API response with some packet modifier or what have you, in the context that the client is actively trying to prevent you from doing so? I think thatâs beyond the line of âexploitingâ for most people that donât use the problematic FFlags.
These flags are for the engineers. They shouldnât have been accessible to us in the first place, because theyâre there for them to debug potential issues with new features.
The physics rate would definitely not be something clients should be able to change, because setting it low enough will actually slow down the simulation:
The networking FFlags were added there for debug or testing purposes anyways but people decided to abuse them. I donât think it is convenient for Roblox to just remove them because some people decided to abuse them. So disabling the ability for people to change their own flags locally in the client is a better solution.
You all should be grateful that FFlags exist on Roblox and that users can easily adjust them locally because no other game offers that.
I understand people that adjust their FFlags for good intentions, I do too. I hope all the good and useful FFlags get enabled when Roblox stop allowing people to locally adjust their FFlags.
Blox strap inserts some âexploitsâ using fast flags according to a friend
i wouldnt say bloxstrap inserts exploits, it only makes adding fastflags easier (ive been using flags way before bloxstrap was made)
This is false, I believe you mean the default flags that Bloxstrap adds to your ClientAppSettings.json
file like FLogNetwork
which allows Bloxstrap to read your log files for Discord RPC and DFIntTaskSchedulerTargetFps
to change the target framerate.
I cannot expect nor depend on Roblox (based on experience) to be the single entity debugging my games at run-time. I have put up with some intentional locking down of the Client/Studio, but this would probably become the final straw if implemented poorly. I do not have high hopes.
Maybe, solve the real problem and start banning cheaters, something I havenât ever been able to say has happened in any of your surveys that ask about âEngine Securityâ. You donât have to take away every debug tool to prevent cheating. Certain & particularly abusable flags were removed, which is seemingly the most that has to be done. Or, put more resources into developing Hyperion.
Are a couple of cheaters seriously more important than the developers?
Itâs not a couple and from what Iâve seen from live cheaters, itâs still fairly easy to detect and take care of server side without needing to nerf the client down so much.
The problem is that flags were mainly for engineers, and that flags allowed roblox to toggle things without having to push entire client updates. In the engineers case its necessary for debugging certain things. for example, network debugging flags have been here as far as 2016, only getting noticed and abused now. Having these flags removed only because of the community isnât exactly ideal for them, which is why itâs easier for roblox to remove local flag loading altogether. itâs just an unfortunate case of people using it for bad. We were lucky to have it in the first place, hyperion wouldnt do much either as its only an anti-tamper⌠meaning flags would have to be removed either way.
As a developer who wants cheating mitigated from my game(s),
Yes, âa coupleâ cheaters are seriously more important than âdevelopers.â
Consider writing feature requests for features the engine is lacking if youâre using flags to debug your games. Donât rely on tooling that needs tools to enable.
Thank you, I remember seeing something similar to what I originally said regarding changing physics rate server side from studio, not the client. The ability for clients to set a framerate cap however is something I hadnât heard of.
One day my head is going to explode because of people like you.
You still clearly donât understand why they exist.
I donât think you realize how problematic native fullscreen is. It would probably never be an official feature because of the amount of inconvenience it causes simply because of its nature, and Roblox would get loads of people complaining about why it causes things to not work properly (like i regularly do, despite already making its problems known)
(post deleted by author)
Unfortunate, I know of those issues youre talking about but I completly forgot it existed from how stable it is from me, but I know itâs not the same case for others
I do think the usecase of testing beta features in-game is important, because Studio is not and never will be a live game. Performance is hampered dramatically in Studio compared to a live game.
I talked about this internally using this thread as an example and I think the temperature is amicable to beta features in live games. No promises and absolutely no timeline though (and certainly nowhere near when local flags get removed).
Local flags should never get removed.
If you require them you should list your use cases and why you need them. Also theyâre only being removed on the client; youâll still be able to change them in Roblox Studio.