#
Entity Key Value Pairs
#
What Are Key Value Pairs?
Key Value Pairs are the most powerful aspect of FuncGodot. All of the Class Properties set in a FuncGodotFGDEntity definition get added to the corresponding entity placed in the map editor.
Key Value Pairs are defined in a FuncGodotFGDEntityClass resource's Class Properties dictionary. A Class Property is defined with a key String and a value of many of the Godot Variant Types (see
Additionally, you can define a property description. With the exception of
The result as it appears in TrenchBroom:
If you plan on using J.A.C.K. you may want to use the descriptions as proper names for the keys rather than actual descriptions. The same entity's properties as they appear in J.A.C.K.:

Once the corresponding node is generated by a FuncGodotMap, these key value pairs are then applied to the generated node's funcgodotproperties dictionary. Additionally, if you add undefined key value pairs in your map editor, these too will be added to your node's funcgodotproperties dictionary.
NOTE: Entity keys that are not given values will have their default values applied to the generated node's funcgodotproperties dictionary.
#
Applying Key Values
It's pretty easy to apply entity key value pairs to nodes generated by FuncGodot. You have one property and two methods that you can use: the Dictionary func_godot_properties, the method _func_godot_apply_properties(entity_properties: Dictionary), and the deferred method _func_godot_build_complete().
After the entity is built, FuncGodot will check if the entity contains a func_godot_properties Dictionary, and if it exists it will apply the translated key value pairs as a Dictionary to this variable. In order for the application to persist at Runtime or after closing your scene, you'll need to make sure the variable is an @export variable.
Use _func_godot_apply_properties to apply your key value pairs to your node, as they are passed through the _func_godot_properties argument in the function.
_func_godot_build_complete is a deferred call that happens after every entity has called _func_godot_apply_properties, making it safe to reference any nodes generated during _func_godot_apply_properties.
You are allowed to limit yourself to only the application methods you're interested in. Mix and match these options as you see fit for your entities.
#
Property Types
FuncGodot supports many of the Godot Variant types. Consult the [key values section of the FGD page on the Valve Developer Wiki](https://developer.valvesoftware.com/wiki/FGD#key values) for more information on FGD value types.
#
Choices
The choices key value type allows you to open a dropdown menu of predefined options in your map editor. They are defined in Godot by choosing a value type of dictionary, with each key being the option text and each value being the property value. Keys are always Strings, but values can be either Int or String.
Normally the default value is set in Class Properties, but for Choices we can't do this (not without a fair amount of trouble). Instead we use Class Property Descriptions to set a default value. We do this by creating an Array with 2 elements: the first element is a String serving as the description; the second element is the default choice and should be either an Int or String matching one of the option values defined in Class Properties.
Once written to the FGD you should get a something like this in your map editor:
NOTE: While Bool types always generate a choices key value type, you don't need to set them up any differently than any other property. FuncGodot will automatically format Bool types for you on FGD export.
#
Bit Flags
Bit flags are the most complex key value type to set up, but offer a lot in simplifying complex comparisons and systems in your game scripts.
To set up a bit flags property, choose Array as the value's Variant type. Each element of the Array will be an Array as well, representing a single Flag. Each Flag Array is composed of 3 elements: a String serving as the Flag Description, an Int declaring the Flag's Bit Value, and an Int representing the Flag's default state.
Bit Flag properties do not utilize descriptions so there is no need to add one to the entity's Class Property Descriptions dictionary.
Once exported, you should get something like this:

Left, Trenchbroom; Right, J.A.C.K.; Not shown: NetRadiant Custom because I'm lazy, but it's pretty similar to J.A.C.K. in this regard.
Even though Godot uses 64 bit signed integers, map editors only seem to offer support for up to 24 bit flags. This is largely an artifact of the Quake engine, specifically its Quake C programming language. QuakeC doesn't have an integer type and instead used a 32 bit floating point number. The result was that only 24 bits remained to be used in bitwise operations. The Half-Life engine inherited this limitation, and subsequent Quake and Valve map editors designed their bit flag menus with this limitation in mind.
In TrenchBroom this isn't too much of a problem as you can have multiple bit flag key value pairs. Unfortunately other map editors are designed to only support one group of flags that they assume to be spawnflags, no matter what they're called in the FGD. J.A.C.K. will just overwrite spawnflags. NetRadiant Custom will throw errors if it detects flag values with matching bits and be unable to open. All key value types of flags will be compiled into the entity's Flags property and saved in the map file with the key "spawnflags".
If you're using another map editor other than TrenchBroom, you can still use multiple flags key value pairs or inherit them across multiple Base Classes. Just make sure each flags property applied to an entity has a unique bit value and expect FuncGodot to build it as a compiled spawnflags bitmask.
#
Build Stage Properties
In Quake mapping there are a number of compiler only key value pairs that can alter the way the map is built, typically preceded by an underscore. These include properties like phong, minlight, and shadow.
FuncGodot also has a few properties that can be used as part of the build process, all of which are customizable in the Map Settings resource. These properties are exposed by the FGD to be set in the map file and read by FuncGodot's core classes throughout the build stages. These build stage properties are:
Some of these properties have built-in support through the use of the default FuncGodotFGDBaseClass resources Phong and VertexMergeDistance.
See also
FGD stands for "Forge Game Data", leftover from when the Half-Life 2 level editor Hammer used to be the Half-Life 1 editor Worldcraft, and before...
Resource file used to express a set of FuncGodotFGDEntity definitions. Can be exported as an FGD file for use with a Quake map editor.