How GD and Geode enums appear in scripts, stubs, and bindings.
GD enums live on geode.gd. Geode enums live on geode.
Each enum is a table of integer members.
local gd = geode.gd
if levelType ~= gd.GJLevelType.SearchResult
and levelType ~= gd.GJLevelType.Saved then
return
endCocos enumKeyCodes is similar but lives on geode.cocos. See cocos.
local keys = geode.cocos.enumKeyCodes
if keyCode == keys.KEY_A then
print("A pressed")
endBindings pass enum arguments and returns as plain numbers.
Members like gd.GJLevelType.Saved are the same integers.
Use == and ~= like any other number compare.
There is no separate enum type at runtime.
Each bound enum has two shapes in types/geode.d.luau:
export type GJLevelType = numberfor method args and returnsexport type GJLevelTypeNamespace = { Saved: number, SearchResult: number, ... }for the constant table
The type checker types every enum as number, so it does not block compares across different enum names.
Only the integer value matters. The special-cased stub type for enumKeyCodes is EnumKeyCodesNamespace.
Prefer named constants over magic numbers.
Some GD_ENUM_TYPES names have no scanned geode.gd table.
Stubs still use number and runtime values are plain integers, so named constants may be missing.
They are listed as unscannedGdEnums in schema.json and the codegen report.
tools/luau_codegen/emit/bindings/geode_enums.pytools/luau_codegen/emit/luau_types/enums.pytools/luau_codegen/convert/marshalling.py