Setting Preset Variable Values for Blueprints Data Mgmt Best Practice Enums, Structs, Tables

Without going into all the different ways I have seen and used myself, I am looking to see how everyone is doing PRESETS for their blueprint characters. Nice and simple for users to deploy setup and use.

The variables do not matter as much as how you handling the many variations and combinations of settings and variables a designer could use.

Say, you had 14-15 variables that essentially trigger subsets and variables, difference physics, whatever to construct and assemble that Preset type.

Right meow, Im working on something I am not sure if enums is what I should be using. That being said, looking at doing hundreds of variations using tables and structs seems like double the work. I am wondering if (without using C#) could a person generate a list of presets using strings only? I do not think you can generate enums dynamically so I would be assuming the structure would look something like
Parent Type Enum > Bools via struct > to a switch on string?

The function essentially updates all matching blueprints which have a tons of variations condensed in what is 3-4 enums and 10 bools that control the overall usage type for the blueprint.

That being said, each of those values calls functions that are in no way similar to each other but as a whole give a complete item. Such as a Door, a Door with light, a Door with Light and Sound, a Door with Lights, Sound, and UI event.

But also has a second or third “layer” of presets which are the same but allow for level streaming or other advanced functions. IE Streamed Level - Door, Stream Level - Door with Sound, etc.

I am hoping for a workaround for this as is essentially making a supa huge , the hugest of enums, so beautiful, so huge. But if there is a better way, I wouldn’t mind knowing a little of your magic.

Be well and tyia!

I don’t get exactly what you’re trying to do, so I’m just gonna address the preset part.

If you mean presets for in-editor use, you can use either data-only blueprints or data assets (more straightforward), and include them as a variable in the blueprint that will use the presets. If you mean presets for in-game use, you can use a struct and save it to an array of structs (i.e. presets) in a savegame.

What I am trying to make is a enum drop down that then will set a bunch of bool preset values.

I am able to pass data between everything and save it. But lets say, I have types A B and C all with seperate options and features. When I select type A, it would then select a bunch or variables. but those may or may not be exclusive to that type and may be used by type B or C.

With every option being a bool or another enum.


Type A - Trigger
Type A - Trigger with Light
Type A - Trigger with Light and Function 1
Type A - Trigger with Light Text and Function 1 and 4

Type B - Trigger
Type B - Trigger with Light
Type B - Trigger with Light and Function 1 and 2
Type B - Trigger with Light Text and Function 1, 2, and 6

Type C - Trigger
Type C - Trigger with Light
Type C - Trigger with Light and Function 8
Type C - Trigger with Light Text and Function 8 and 1

You didn’t mention if this is for the editor or the game, so I’m assuming it’s for the editor.

The problem with an enum is that for every new entry, you have to (1) add that entry to the enum manually, and (2) add it to the code manually. Instead of doing this, you would use either a data asset or a blueprint class and select them from a drop down in a variable. Then, instead of having to set variables manually, you just access them directly from the preset; this treats it as if it were part of the blueprint itself.

Using a data asset
  1. Create a new class of type “PrimaryDataAsset”.
  2. Add variables.
  3. Create a data asset from the miscellaneous category.
  4. Select your data asset class.
  5. Open it up and set the values. This is what will be used as a preset. You can duplicate this and create more.
  6. In your actor, create a variable of your data asset and compile. You can now select presets from this variable.
  7. To access the values from this preset, get them like any other variable.
Using a blueprint class
  1. Create a new class of type “object”.
  2. Add variables.
  3. In the class settings, set “generate abstract class” to true. This will keep the base class from being a preset.
  4. Create a child blueprint from this.
  5. Open it up and set the values (note: the first time will open up the full blueprint editor, but the second time will open up only the defaults). This is what will be used as a preset. You can duplicate this and create more.
  6. In your actor, create a class reference variable of your base preset class and compile. You can now select presets from this variable.
  7. To access the values from this preset, get them from the class defaults (note: you can hide pins).
    Alternatively, you can construct an object from the class to access the values like normal variables.

If you want this for a game, you would use an array of structs in a savegame that contain all the data you need, populate a combo box with the entries from an array of the preset names, and load the entry that the player selects.

Yes is for the editor prior to game packaging.

I have the primary (first named/spawned) and then its settings are passed into the construction scripts for all the other matched triggers.

I am running this in a loop which then either runs only once for the parent or then for all matching

Which then sets the data sync options and then sets the primary usage types for the trigger using an enum. Which the reason for this is the construction scripts for the child triggers runs on its own and then sets up the builds in the construct script.

BUT under the basic usage types, there those common presets or variants which may or may not be common to the usage types themselves.


So you could have a video wall trigger that also uses a minimap widget when active as well as an SFX trigger which will also generate a minimap (or whatever)

So I’m quite literally trying to toggle all these books. My first attempt was a spaghetti mess and a super long enum with all the different variations (was over 300 line items) Which is what lead me to the hybrid I am currently using and the purpose is to simplify the initial setup for the users as they build their levels.

Might just end up staying like it is, bc I am worried that if I did all data like you shown or go just make a var group with setup vars, its gonna get to be to much work setting one of the triggers up (my goal was about 2-4 minutes total setup for a new trigger)

So it seems like no matter what, its either going to be a lot of data assets, structs or workflow replicating each individual preset?

Lots to think about. Thank a lot for the incite sir!

1 Like

Your setup still looks unnecessarily convoluted. For instance, this picture can be simplified using blueprint classes or data assets. Notice how each macro has the same variables, the only difference being that the values change. This is what data-only blueprint classes & data assets are for; when you use them, they are treated as though they are part of the blueprint itself (because they essentially are). Think about it like the “Set Static Mesh” or “Set Material” nodes: instead of creating an enum for each new mesh or material, it is automatically added to the list, and all you have to do is select it; those assets have their own settings, which also come with other settings, and so on. None of them, however, need to be manually coded in; it’s all automatic. The way you have it now, you will have to manage all this yourself; what if you wanted to add new types, new variables, or bulk change multiple values for multiple types? Using a class or data asset will simplify this tremendously (and is actually how things like this are supposed to be done). Unless I’m missing something, I think you should use blueprint classes or data blueprints instead.

When it comes to syncing with the first placed trigger, you could just grab the variables directly from the first trigger (i.e. “pull” the settings) instead of having the first trigger set all other triggers (i.e. “push” the settings). You could also just make a child blueprint of the trigger. That way, you don’t have to do anything in the construction script because the settings will sync from inheritance.

Well adding functions is fair staright forward. I add it too the enum and then create a base usage type node like in my last image. Then its pretty much ready.

I agree with you saying is sorta convoluted. it was way worse at one point. I am going start looking into the data only and see if I can make that work for me how I want. Sorta want to address this before the next release and make it easier to setup then it already is. As long as I can thread it through with out having to include a save or game instance, might just be the right ticket!

1 Like