Custom Enum Management Window

As a Roblox developer, it is currently too hard to …

Ensure a number is a valid ‘type’ or ‘index’.
You can only union string representations, and the Enum table, while amazing, is an example of functionality that remains inaccessible to developers.

If Roblox is able to address this issue, it would improve my development experience because…

Nearly every experience has needed, or will need, a custom Enum representation, but currently there’s no type-safe LUAU solution, which is FRUSTRATING from a stability standpoint.


Currently, we have a Collision Groups Editor:

While I’m aware that this is simply ‘filling’ values into predeclared arrays for the physics engine, we really need a similar menu for custom enums.

A Custom Enum Menu should:

  1. Allow developers to declare a new Enum.
  2. Adjust the numerical values of each entry for a custom Enum.
  3. Automatically update the internal type-checker and auto-complete
  4. Support negative values ( -2, -1, 0, 1, 2 )
  5. Support sparse values ( 0, 1, 3, 7 )
  6. Support bit-flag values ( 0, 1, 2, 4, 8, 16 )
  7. Implement a matching Type for each custom Enum
  8. Mime all existing functionality of Enum tables: .Name, .Value and .EnumType
  9. Shared across all places in an experience, without an additional require()

For posterity, there’s been a few attempts to offer suggestions or fixes to this problem, but none have approached it as something to be solved with Studio itself, and the solutions that do exist honestly feel like bloat in comparison to Enum. for such a basic LUAU functionality, and most solve it with a lot ‘clunk’, making them un-ideal.


Heck, I’m to the point where I’m considering ‘repurposing’ certain Enums for my own game logic, that way I know what values I’m getting- But that relies on the fact that said Enum won’t change in the future, which is also horrible for long-term project stability.

5 Likes

Custom Enums should not be a thing implemented right now, as it will be a runtime tax slop
Roblox should do this first:

Enums should be fully ahead of time.

That’s why I dislike custom “implementations” of enums because they are all bloatslop
Enums in the current state are used as a proxy by the engine to identify data you should never try to mimic the engine API in non-engine work; this is not C++. This is a dynamic scripting language; patterns should optimize for runtime here, so using Luau primitive numbers for it internally is a much better idea, hence why implementing header files and preprocessors should be better than bloating the engine with “custom” slop.

Internally you can define headers with enums like

--#Header<Enums.H>
local Enum_DoorBroken = 0
local Enum_DoorOpen = 1
local Enum_DoorMoving = 2
local Enum_DoorClosing = 3
local Enum_DoorIdle = 4
--\Header

then require it using --#include<Enums.h>
And keep using code as is without bloat for runtime.
This is something I currently try to archive in Roblox Studio via plugin and in the future for VS Code implementation.

1 Like

I guess this should come with custom instance stuff, then while they are at it