Certain fast flags are being abused for various cheats in games. Some of these can be super game breaking, others can give really unfair advantages. A lot of people using fast flag editors to cheat seem to think because this is a Roblox feature, that they’re fair game to use.
A private message is associated with this bug report
Can confirm the character spin thing, someone told me that they use modified client. - happened a month ago
This is affecting my games, so I always have to disable character collision.
We plan on disabling the ability for people to change their own flags locally in the client (not Studio) relatively soon. I can’t give a timeline, there’s some stuff we want to do first to make existing good faith flag flips unnecessary, but it’s soon.
There are still quite a lot of cheats going around from FFlags to injections, on multiple platforms. I was expecting more hyperion updates… especially after we lose things like custom shaders and linux support only for exploiters to still be around
anti cheat when a single windows setting is wrong: 
anti cheat when an exploiter injects a 10 page long shakespeare play: 
Hyperion 4.0 is coming soon, it will address some of the current prevalent issues.
That’s on god, we love you bitdancer :3
Im a bit out of the Exploiting branche, but wasnt there an old employee of SynapseX, who actually made an Ejector that can go around ByFrost?
PLEASE for the love of god, allow us to play games BEYOND 60 FPS if you’re going to disable fast flags. Please. I beg of you.
It was cool to force meshes to be at the lower quality, to force Future lighting, and to force Vulkan rendering while it lasted 
Oh well, looking forward to seeing what happens regarding the “good faith” ones!
I think that’s what they meant by “[first making] existing good faith flag flips unnecessary”, since framerate limit unlocking is probably the biggest reason people initially look to configure Fast flags., and they are actively working on making it an official feature.
In one of the updates there is a note for allowing FPS caps to be raised to 90,120 and 144
Ay i love herfdiug. Missin the times fastflags werent that popular.
Video creator here,
These have existed for a while now and I’m glad that it is finally getting patched, it was gatekept but inevitably bad actors got hold of it which was unfortunate.
Please make sure that whatever replaces the current fastflag system allows us to enable developer-oriented things such as betas in our client. My use-case for changing client flags is to test betas like EditableImages and aerodynamics outside of Studio before they officially launch.
What is your use case for this? This is currently not in our plans and it smells like Studio could be improved here.
I have quite a niche use case outside of what @Mauio64 described - I sometimes toggle on flags to help engineers determine whether a flag they’re wanting to enable will cause issues with certain aspects of my game. For example, a few weeks ago a flag was pushed regarding UI that caused a property used in my game to completely break and I was able to work with an engineer who was responsible for it to help test and identify the flag involved and see if the issues were corrected after they pushed a fix.
Yes, repro files can be used as an alternative but not for device-specific issues… going to miss helping out engineers with flags 
No please don’t it will disable the ability for me to revert to old CoreGui version and many many other things such as FPS unlocking with bloxstrap
Maybe solve this issue by making some abusive game breaking FFlags read-only? (aka you can’t edit them and they have only one value)
This behavior will not be preserved in the client, though you will still be able to change flags in Studio using whatever method you would be using today.
This simply isn’t sustainable and requires that we play cat and mouse and constantly make sure that specific FFlags can’t be abused. Also, even if this was added, it certainly wouldn’t include reverting to old CoreGui, as the end state of most flags is for the code it’s replacing to be completely removed for maintainability reasons–we would just be encouraging delaying the inevitable.
Well, I literally just stated my use-case. I use them to test features that make use of betas ingame before they launch, most often with several of our playtesters whom I can’t afford to give Studio access. I have these features built and tested before the betas go public so that when they do go public I can be relatively sure we’re good to go, and can just enable it.
I don’t know how Studio could be improved here, short of letting us enable fflags for our entire game inside of it, or some system that lets us host game servers from our PC and lets people join, respecting whatever fflags we set.
I see. This use case will definitely break, and were it to come back it would not be in this form (I expect us to never allow local flag editing on client after this). But it sounds a bit like better Studio permissions, like being able to Team Test with someone without giving them access, could help alleviate this somewhat…that or beta features being able to be tested in game which is a problem we face a lot regardless. No promises, just musing about what could potentially help.