Dynamic Enumeration?

So I really enjoy using enumerations to help keep things organized between classification and being able to use “Enum Switch”. One thing I would like to see, however, would be a way to dynamically group various groups of enums as a method for sorting more complicated algorithms in BP.

Basic structure:

A) User defined Array of enum classes
B) Class selection (from user defined array (A), shown by simple class name) that can be selected via dropdown much how an enumeration can be chosen.
C) Enumeration choice of selected class (B)

How should it work? Well, the drop-down bit would be more for us devs for the sake of simplicity. It wouldn’t show the class when it’s made public/editable, and would only display B and C as drop-down menus. The best example I can see for the use of such a variable class would be:

Dynamic system where variables swap out but undergo similar processes to be run by them. The inspiration for this was a modular weapon system. You could either have similar processes run for the different weapon types but limit each type to its own blueprint, or just have it all there dynamically made by each blueprint. FOR THE “PARTS”, imagine they exist in enums numbered 1-8. Example: For SwordParts there is an enum for SwordParts01_Blades with the following data: SwordBlade01, SwordBlade02, etc, to SwordBlade08. Imagine the same for all of the other parts for each weapon.

Enum Class: WeaponTypes
Enum WeaponTypes: Sword, Bow, Battle Ax

Enum Class: SwordParts
Enum SwordParts: Blade, Guard, Grip, Pummel

Enum Class: BowParts
Enum BowParts: Limbs, Riser, Bowstring

Enum Class: BattleAxParts
Enum BattleAxParts: Handle, Blades

Enum Class: InvalidType
Enum InvalidType: NA


Enum ChosenWeapon (Public, editable): WeaponTypes

Dynamic Enum WeaponParts01 (Public, editable):
A) {SwordParts02_Blade, BowParts01_Limbs, BattleAxParts01_Handle}
B) Dropdown between any class from A
C) DropDown displaying an enum from class defined by B

Dynamic Enum WeaponParts02 (Public, editable):
A) {SwordParts02_Guard, BowParts02_Riser, BattleAxParts02_Blades}
B) Dropdown between any class from A
C) DropDown displaying an enum from class defined by B

Dynamic Enum WeaponParts03 (Public, editable):
A) {SwordParts03_Grip, BowParts03_BowString, InvalidType}
B) Dropdown between any class from A
C) DropDown displaying an enum from class defined by B

Dynamic Enum WeaponParts04 (Public, editable):
A) {SwordParts03_Pummel, InvalidType, InvalidType}
B) Dropdown between any class from A
C) DropDown displaying an enum from class defined by B


Bringing it together: It's quite simple. Any time the value for variable ChosenWeapon of enum class WeaponTypes changes, I would go and manually (though in a macro) change the classes of the Dynamic Enumerations (Section B) for the 4 WeaponParts variables to equate to the index number of the Byte value return for ChosenWeapon. Value C for each individual one can be carried over as the ByteValue of the different classes, clamping between a value of 0 and the LastIndex number for that enumeration class type (B).


Now among the blueprints' exposed values when you drag this out in world, you can simply click and choose between a few dropdown boxes to customize your weapon without having to resort to typing in strings, or doing this with just byte values and hoping everything is what you think it is. This is currently doable with just ByteValues, but to know and select between Enum values you've defined yourself would be great for being able to choose based on the targeted (or potentially chosen) Enumeration value.

If you want, you could even make your own DynamicEnum_Invalid enumeration as a fail-safe return value for having an enumeration's Byte value out of range compared to other ones.

**This would, technically, all still static in the same manner an enumeration is, but it has the potential to be capable of organizing Enumerations so they all become interchangeable via their Byte value, while still being invaluably dynamic within a range specified in its static definition.**

Does any of this make sense?

The input would essentially be just an array of the numerations made in a similar fashion that enumerations are made. Except it's an array of Enumeration Classes. The outputs that can/should be gained (from one or various functions) would be: selected EnumClass (Value B), selected Enum (Value C), selected EnumByte (Value C in Byte Form).

This feels incredibly niche and not at all feature worthy. What’s wrong:

switch (A)
{
    case X: return corresponding B;
}

And then have the client figure out C, or have C be dependency injected into B, and have a FactoryMethod:

CreateSword(A a, C c)
{
    switch (a)
    {
        case a::X: return B(c);
    }
}

And then repeat for other values of A? You can only reuse code so much, and creating a factory method means you only need to do this like 4 times.

Or, if you really want you can make it a generic factory method.

CreateItem<TA, TB, TC>(TA a, TC c)
{
    switch (static_cast<int>(a))
    {
        case 0: return TB(c);
    }
}

Now its one switch statement, you’d just have to ensure type safety.
But this is super over engineered if you ask me, but way better than a clunky feature.