Anyone can spoof the API response from https://clientsettingscdn.roblox.com/v2/settings/application/PCDesktopClient though. How are you going to remove that?
Me when I don’t understand why FFlags exist:
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).