Allow scripts to access GetFastFlag

Feature Requests Engine Features
#1

this probably isn’t phrased that well pls dont hurt me thanks

As a Roblox developer, it is impossible to for scripts to access FFlags.
This is a problem since I have the ability to change FFlags on the fly to develop this stuff in Studio (yes I know im basically playing with fire here).

The current workaround to this with many features is to prod what the flag should do and see if it returns an error which is a bit of a yucky implementation

local s, e = pcall(function()
  return game:GetService("AvatarEditorService").GetInventory --this will error
end)

If this issue is addressed, it would improve my development experience because then I would be able to write code for features that are yet to be released, but can be accessed through an FFlag.

The main drive behind this is stuff like attributes, one of my entire projects was built ontop of an attribute-based object system, however I had no way to see if Roblox had actually enabled Attributes in live games, allowing me to fallback to a custom implementation.

Currently, I have to rely off this:

local AreAttributeEnabled = pcall(function()
  script:SetAttribute("AttributesEnabled", true)
end)

if not AttributesEnabled then
  --fallback to a custom implementation
end

There’s a few issues here, the main one being that we basically have to force an error to see if the feature is enabled which probably isn’t the best way of getting around this.

Now lets see what happens if we throw game:GetFastFlag into the equation:

local AreAttributesEnabled = game:GetFastFlag("AttributesEnabled") --i cant remember it;s actual name

if not AreAttributesEnabled then

end

First of all, it’s less lines, and secondly, we’re not prodding for an error inside a pcall.

In summary, I want to write code for future features that aren’t out yet but I can activate within Studio.

ps: scripts can already access fast flags preceeded by User, I wonder why it was filtered to this behaviour.

14 Likes
#2

I think the fundamental misunderstanding here is that features behind fast flags are not meant for actual/production work until they are announced as generally available by Roblox (through e.g. forum announcement or API documentation descriptors). With this understanding, this feature request makes little sense. Just try out the features for experimental work in separate place files until they are ready for use in production code, or wait for Roblox to properly turn on the fast flags themselves (we’re not meant to toggle them ourselves).

2 Likes
#3

I don’t think it’s unreasonable to want to get a head-start on features releasing soon.

However I’m against this for a different reason and it’s that FFlags are removed all the time (the hypothetical GetFastFlag function would return nil in this case, and not true) and if you don’t update your code accordingly, your system that relies on the FFlag being enabled will no longer work. Typically, Roblox does not like this scenario.

Sure, Roblox could introduce a function that does this with the implicit understanding of “if we remove a flag that you rely on, it’s your fault, not ours” but they prefer to avoid situations like this entirely.

3 Likes
#4

My request focuses on beta features that are available in Studio, which are controlled by FFlags, but not live games. The developer may accidently implement features that aren’t actually released in the RCC client. (this did happen, see the attribute situation). Technically speaking, this could be safeguarded with IsStudio, but in my opinion that doesn’t feel granular enough (and also Team Test misreports it).

This could be blamed on developer error, but this is going to happen to everyone eventually.

But the whole Roblox not wanting code to break suddenly makes complete sense, dont think they want a massive JSON file with FFlags that haven’t been changed for three years because one developer relies on it lol.

1 Like
#5

Based on the rest of your post I think we’re on the same wavelength, just phrasing it differently: nothing wrong with trying out features early, but fflags are not proper API and are prone to change that we cannot anticipate well from developer side. Roblox usually does try-outs of features with proper boolean/enum toggles that have better defined behavior and change modes.

5 Likes
#6

This would improve my developing experience because I could block users using FPS caps above 60 from joining my game by checking if the Fast Flag “DFIntTaskSchedulerTargetFps” is over >60. This can help mobile players because they will not have a disadvantage over PC players with the FFlag set.

#7

Why are you treating fps cap users as exploiters? Are they exploiting the client? (Ok, bad example since maybe they are exploiting technically speaking)

But still, it’s like calling all mods = cheats scenario, plus FFlags are built-in feature editable by ClientSettings.json instead of DLL injecting

#8

It gives them a unfair advantage over mobile users.

#9

The thread already more-or-less concluded above your post, e.g. this is not appropriate for Roblox to expose.

This solution would be an XY solve for the problem you are having. I recommend filing a feature request about your problem (not trying to find a solution for a problem, just post about the problem itself) so Roblox can take a look at that.

#10

It’s possible with some plugin tricks. (only in studio)

Plugins can read FFlags and can communicate with normal scripts in various ways (such as BindableFunctions).

#11

Here is a very simple local plugin.
(make sure to add some extra checks)

function getFastFlag(flag: string): boolean
	return settings():GetFFlag(flag)
end

function enable()
	local bindableFunction = workspace:FindFirstChild("_GETFASTFLAG") or Instance.new("BindableFunction")
	bindableFunction.Name = "_GETFASTFLAG"
	bindableFunction.Parent = workspace
	bindableFunction.OnInvoke = getFastFlag
end

function disable()
	local bindableFunction = workspace:FindFirstChild("_GETFASTFLAG")
	if bindableFunction then
		bindableFunction:Destroy()
	end
end

plugin.Unloading:Connect(disable)

enable()
#12

This only works for plugins, I already knew about this thing. The feature request asks to make it more general to game scripts (which cant access the settings() object [dont even think the client has one?])

#13

It would be amazing to be able to use new features if they are enabled on client

2 Likes