Need an alternative to recursive structs

[Chumble]

I am currently in need of a recursive structure (or rather, an alternative to a recursive structure since UE doesn't let you create one). I am trying to create a setup that can be used for dynamic menus. Essentially, this structure will drive the appearance and behavior of a button. My problem is, the button needs to be able to contain data for additional buttons. And those additional buttons need to be able to contain data for additional buttons, etc.

One option is to simply create all the buttons at the beginning and pass in the child buttons by reference to the parent button. But this seems very messy. It also doesn’t work too well when the child buttons need to be dynamically generated (for example, if a button needs to be created for each player in the game).

Structs are out because a struct can’t contain a data type equal to itself. This makes sense if it’s not an array because compiling this struct would cause infinite recursion. However, if you have an array of that struct with 0 elements, it should work since there’s no recursion there. But it doesn’t let you.

So is there a workaround for this?

[Joviex]

Old way is to just flatten the data, like any of the fancier K-V database do these days.

Store everything in an array.
Add a field called Index to your entries.
Add an array field to your entries called Submenus

As you build, statically, or dynamically, you will just push and pop the Index value to the Submenus list for said entry.
You build the menu and submenus from the data you can "recursively" trace.

What you will want to do is make it so you don't do some stupid thing and allow people to build 18 submenus.

Pick a descent cutoff, which you can even parameterize (how many level so submenu allowed?)

This is basically an old school "linked list".

Take note, this allows people to build multiple types of submenus from the same menu entries i.e. they would add a submenu called pickles, and then in another place, if they wanted to use pickles again, but with new submenu entries, you just make said new entry in your array that has all entries, give it a new index (unique) and off ya go...

Cheers

[Chumble]

I .. don't quite follow you. In attempting to follow your description, I have a struct "menuStruct" with an integer "index" and an integer array "submenus". In my game hud, I have a variable "menus" containing an array of menuStructs.

I honestly have no idea what to do with this, feeling a bit like an idiot.

[Chumble]

I should mention that the goal of this was to pre-create the menus in the event graph manually. The menus will not be edited and customized in-game and the only menus that would change are ones where it displays a button for each player (or each other actor I specify). The system I am looking to create is to assist me, the designer of the menus so that I can make changes quickly without having to remake a bunch of widgets each time I want to change something.

[Everynone]

While you cannot nest structs, you can always nest objects. Perhaps you could take advantage of the DataOnly blueprints.

Create an actor with the variables/functions/events. If you remove the default Events from the instantiated object's (child's) graph, you end up with a data-only blueprint:



I'm not entirely sure if there are any performance benefits over regular actors.

[Chumble]

Well I guess if I was going to go that route, I may as well just create all the buttons beforehand and only add them to the interface when needed.

I would need to have exceptions for times when the buttons need to be generated on the fly (again, using the example of having a button for each player) which is a bit messy but .. I don't see any way around it.