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.
But we need to know what flags you’re using are to know what would go in that settings menu. It would not, for instance, include anything relating to UIBlox color palettes.
As an example, we knew that DFIntTaskSchedulerTargetFps was extremely common to set, so now it’s an official feature.
I use several other flags, Such as:
DFIntVoiceChatRollOffMaxDistance (changes voice chat hearing distance)
FFlagDebugDisplayFPS (displays FPS at all times without the use of shift+f5)
FFlagVoiceBetaBadge (makes the voice chat beta badge visible or not)
FFlagFixGraphicsQuality (has a graphics level 1-21 slider instead of 1-10, like studio)
I think that: As long as a flag does not give an unfair advantage, it can be used)
I appreciate the clarification and the insight into the criteria for including flags in the settings menu. It’s interesting to learn about the transition of DFIntTaskSchedulerTargetFps into an official feature, which I hadn’t noticed until now, as I’ve been utilizing that flag for some time already.
Concerning the proposition for an Advanced Settings Menu, I must admit that I’m not the most avid fast flag user, so I may not be the most qualified to determine which flags should be incorporated. However, as Bitdancer previously highlighted, utilizing community input and exercising informed judgment appears to be the most effective method for selecting which flags to include.
Thank you once again for your attention to this matter, and I eagerly await the progress on these initiatives.
There are a bunch of fast flags which I’d like to keep, like forcing Future lighting, bringing back the old Roblox menu from 2020 (people just hate change - it’s not that bad!) and 0-21 for quality. They should be merged in officially before they actually go and block FFlags from the public.
Oh, so you’ll be optimizing the default config so it runs well on old/low-end hardware?
Also making the graphics slider 21 bars instead of 10, letting people use the old escape menu, make rendering not go to 720p when using a high DPI scale, and letting people change their game render engine?
Or will you just make the experience of playing much worse because one or two people?
I’m fan of that one as well (even tho it doesn’t have all settings), but it also posed a major flaw. It allowed players to reset and bypass the callback without exploits, which caused glitches with games blocking resetting on certain circumstances.
I believe this is the menu for reference
Roblox should absolutely keep this flag allowing people to personalize the menus to their personal needs. I am a kind of person that needs to have everything transparent in the process to feel comfortable (and not have to feel being trapped in a box when I open the menu). If they would ever remove flags, then they at least should keep this. In addition, it actually has a really nice organization and thought out UX. Why not let us have it?
Also, please still allow 21 graphics quality bar as it’s much more precise and it allows me to get peak quality on peak performance for my crappy i5 PC!! I usually play on 4/21 or 7/21.
It’s still impossible for them to somehow implement “private” flags. Maybe as they said they would prevent people from locally changing FFlags, then they could just make certain flags only readable off of the user’s value on the site. I don’t get how FFlags work since I don’t work at Roblox, but I’m pretty sure there’s better way to prevent abuse than closing the whole park because one person vandalized and didn’t get caught.
They could probably remove the access of settings set in AppClientSettings, and enforce Hyperion so that you can’t inject modify the flags, basically locking them
It would be awesome to have some kind of UI-hiding mode while playing, a FFLAG alternative similiar to “DFIntCanHideGuiGroupId” which hides all of Roblox’s UI.
It would be very nice to have this feature in the client, along with some (optional) shortcuts to hide any and all Roblox UI, or game GUI. Such functionality isn’t here with the fflag. But instead with the group, make it a toggable shortcut while playing! Especially Roblox CoreGUI.
Key | Act |
---|---|
Ctrl + Shift + B | Toggles GUIs in 3D space (BillboardGuis, SurfaceGuis, etc) |
Ctrl + Shift + C | Toggles game-defined ScreenGuis |
Ctrl + Shift + G | Toggles Roblox CoreGuis |
Ctrl + Shift + N | Toggles player names, and other BillboardGuis that show up above a player |
Yeah… people just dislike change which is why it was so “hated”, people are super picky and it got canned and I’m not very happy about it. I remember seeing it was being worked on behind the scene but I’m pretty sure it got scrapped internally because it never got pushed out again. Hopefully they reconsider this menu… looks way better
I have a proposed solution to this issue. Remove the ability to change them on the client, but allow them to be set on the server. The client then periodically gets the new set from the server and checks with the old one to make sure that they haven’t been changed. The server can actually check for a client message to indicate this and block/kick/ban the player. The check would happen randomly every 15-60 seconds.
Furthermore, by allowing FastFlags to be set on the server, a developer can further configure what feature they want in their game.
Some of these FastFlags were removed but a lot are still remaining. I wish Roblox wouldn’t allow non-testers to use these Flags.
It seems doable to offer a way to disable Roblox CoreGui and player names but I can’t see disabling developer UIs happening. What do you use this for?
We definitely are not going to let developers control fast flags on the server. There is no stability contract for them.