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.
This is the best case scenario in my opinion. Letting developers just use beta features in-game more often (even if they’re not necessarily stable yet) would go a long way, both for Roblox and developers.
I’ll gladly take Team Test being open for non-devs being supported though, and it’d be really useful outside of the context of testing Roblox betas… thinking it could generate a join-link much like how private servers work. That way, all we’d have to do is send one link to get people ingame and going, no need to configure permissions or anything.
If there was one FFlag that liked to use, it was the one that let’s the player hide all GUI, including BillboardGui and chat bubbles. It was arbitrary locked to being in a specific group (which was changeable using Bloxstrap, but I think this needs to be a feature anyone can use, mainly for screenshots and videos.
Some games use BillboardGui instances to guide the player towards quests and important locations, but these break immersion, especially if they’re drawn on top of everything like the Sonic Prime logo and characters’ head renders are in Sonic Speed Simulator:
This flag was also useful for getting completely clean screenshots, as it can hide all game and core GUI elements with other keyboard shortcuts.
People are emphasizing how important frame rates over 60 are, but this is so useful that I think it should become a proper feature before locking down FFlag modifications.
EDIT: Also, without this flag, the only people that can hide all GUI are exploiters, since they have control over CoreGui. It would be awesome if every player could hide any GUI when they wanted to take pictures. I know CaptureService exists and it can hide CoreGui for screenshots, but that will only work if a developer uses its functions in their game, and I doubt most of them will… Roblox can look beautiful at times (just look at Royale High’s Castle’s Heart realm), and it would be nice to capture that without any obstructions…
Currently this functionality is restricted to devs-only unless you turn on the flag. Maybe they could open it up to everyone(?) but this would probably be a separate feature request.
Just as an FYI, this workflow will definitely be broken in the recent changes. I’m unsure if this is something we will want to bring back as a general thing, it is actually quite surprising to me that GUIs I can make would sometimes be able to be hidden (obvious cases being things like intentional blind UIs, aesthetic blurring/vignette UIs, etc). I think the better solution here is making it easier for developers to allow their games to have these kinds of viewer modes, probably through something like a dev module.
I’m glad I found this topic, was about to ask the same thing as I’ve seen a Exponential increase in cheaters being caught by my anti-cheat service. It’s usually a few per week or even the entire month, but lately it’s increased to thousands a week. At first I thought maybe there was something wrong in the anti-cheat service, but it’s doing its job properly. It seems that more kids are finding info about this, even though it is quite old I suppose. It is becoming more popular now.
I can’t stand the new “Chrome” topbar, so I used FFlags to revert it to the actually decent topbar. Now FFlags are about to be disabled because some random dudes are ruining it for everyone by cheating with them.
A fix would be to make all flags read only, then release an official way to edit certain flags, such as ones that remove the new topbar that makes me want to throw up
I mentioned this above earlier, there’s no world where we maintain both Chrome and pre-Chrome so this isn’t a use case we would support even with some alternative solution.
Good call on FFlagHandleAltEnterFullscreenManually! I remember it being removed but I didn’t realize until your post that it was eventually brought back. This workflow will be broken when the local flags removal happens, but I let the people who made the decision to bring it back know that we’ll need to take this into consideration in the future.
