‘Legit Exploits’ my [CENSORED].
They are still using an external program to use/modify FFlags.
That’s basically exploits but worse and with less (or more, idk) steps.
Would it be possible to have a list of fflag in setting or where ever, that can be changed. Anything else added to that file would be ignored. Flag such as “DFFlagOrder66” and “FFlagGameBasicSettingsFramerateCap” are quite good one. Else if possible add a setting to disable in game purchase (basically what order66 do). I don’t know why it’s not a setting already, tbh.
FFlagGameBasicSettingsFramerateCap is intended to be flipped wholesale.
Everything is subject to change, so take it with a grain of salt, but this is, in a nutshell, how the new redesigned FFlag system will work.
Yeah, it is a NECESSITY this days to have a flag to block purchase prompts, every time I go into any game I’m spammed with Favourite prompts, purchase prompts and more, it is really annoying to play ANYTHING with them like that
To confirm:
Rōblox will decide which flags users will be able to modify in the future.
However, there are dynamic flags – which Rōblox can change in the middle of a play session.
I can imagine a similar system where the ability to change individual FFlags can be toggled by Rōblox intermittently. Is this something that you anticipate?
This is correct.
The new design allows it.
Since this topic is about FastFlags and I don’t have much access on DevForum I figure I could ask here.
Why does FFlagMovePrerender
exist and why is it on by default on mobile devices? It basically removes the reason developers use RenderStepped which is to run code before rendering as it gets moved to run after Heartbeat.
(Micro Profiler from Android)
There’s a game I’m aware of that has been broken for a long time on mobile devices because of this flag and it would be nicer if this could be controlled by developers instead of being forced.
I don’t wanna sound like a supervillain but this ain’t happening until you guys release some sort of graphics setting update bru. Im tired of having to be locked at 60fps despite having a higher end pc and using a fill the gap as my graphics setting selector instead of having distinct graphics options I can choose from. This is why fast flags are mainly used but now unfortunately exploiters ruin it
this is about exactly what roblox is doing (when it comes to fps) already before they lock flags entirely
Bloxstrap really killed us. I hated bloxstrap always, but now I hate it even more.
In that case, could you also have the graphics API/rendering mode flags added to the list of allowed flags as well? More specifically, FFlagDebugGraphicsPreferD3D11FL10, FFlagDebugGraphicsPreferD3D11, and FFlagDebugGraphicsPreferOpenGL flags.
I’ve noticed that Roblox on some rendering modes perform better than others depending on the device. On my device specifically, Roblox on DirectX 10 performed best with a 1.25x performance improvement in terms of FPS. The ability to change the graphics API would be really nice to have.
… it just edits a file… its not that deep.
If I can suggest something to be kept in, GUI toggles make for a great game de-bloater.
The same goes for some rendering flags, I know people with very low-spec PCs who use them to improve performance.
I’d heavily apply the “Better to have, and not need, than to need, and not have.” principle to this, locking away features that power users commonly utilize because “they can be used for bad things and nobody uses them” isn’t the best mindset.
I have a suggestion. What about allowing certain fast flags to be used? Ones that can not be used for cheats
That’s uhh… not the greatest idea, in my opinion. If we may know, why is this the option you are going with instead of, for example, blocking normal users from using ones that could be used maliciously?
I answer this earlier in the thread:
It would instead help to know what FFlags you enable so that we can improve those use cases.
Personally, I find Hide GUI toggles incredibly handy, especially when diving into games with excessive clutter. I also utilize them for taking screenshots and tailoring my experience, like tweaking UI colors on the desktop app. Such as “FFlagLuaAppUseUIBloxColorPalettes1” or “FFlagUIBloxUseNewThemeColorPalettes”. Occasionally, I also use them for tweaks, like reverting the Roblox escape menu to older versions.
I’ve also noticed my friends with lower-spec hardware opting for performance-oriented fast flags. These little tweaks, such as disabling grass or shadows, tweaking render distances, or enabling frame buffers, and the 21-stage graphics slider can significantly enhance their performance.
Additionally, I’m a fan of retaining flags that grant early access to certain features, like Chrome UI and Captures.
I personally feel like something like an “Advanced Settings Menu” hidden behind a key combination where you could toggle certain approved flags would be a good idea.
The big problem here is that those flags will be removed one day, and it will not be out of malice, but simply out of protocol. Flags are added to roll out code smoothly–when that code is properly rolled out and stable, the flags get removed because otherwise the code becomes a nightmare to maintain. So allowlisting those flags will only delay the inevitable.
I’ve revisited the post with a new proposition that, in my view, offers a simpler and more user-friendly approach compared to relying on third-party software just to toggle flags.
In my opinion, incorporating an “Advanced Settings Menu” accessible via a key combination or launch flag could simplify the process and significantly enhance user experience. This menu would serve as a user-friendly gateway, allowing users to easily toggle approved flags without the hassle of navigating through complex manual adjustments.
Moreover, by introducing this feature, we could render third-party software used for flag toggling obsolete. Users would no longer need to rely on external tools.
This approach not only fosters accessibility for all users but also empowers power-users to explore early features or fine-tune their experience according to their preferences. I’m confident that implementing this solution would require minimal maintenance efforts, especially given the ongoing development of a new escape menu (ChromeUI), which could seamlessly incorporate this feature.