Dealing with structs and maps in blueprints can be unwieldy and error prone. I’ve found that many times, a string can be used instead.
A string is an array of characters. You can easily make an array of strings which means you can easily get an array of arrays. To deal with an array of arrays via a blueprint struct can make for messy, confusing work very quickly.
Typically to store relational data (e.g. a Name like “Bob” maps with an int like “29”) you use a map. Maps are a bit unwieldy to use in blueprints which also introduces errors and extra mental fatigue.
A string can store relational data pretty easily because we can use the parse string node. I’ll show you how:
Here I have made a complex example string:
I am separating elements with a dash (-). Using the parse string node the dash as the delimiter, then I get this result:
So now I can store pretty much whatever I want within a single string. The only thing I need to make a note of is the order of the elements in the string. Something like this:
You can make a tooltip on the string variable, that way anywhere it is used you can easily see the reminder of what the order is:
Then later if I want to find just one specific piece of data, I can just parse the string and then from the resulting array I can find the element at that index. This is much easier and less error prone than searching maps or nested structs.
And of course you can have an array of strings like this, so holding a big database full of all kinds of relational data is pretty easy to filter through, and also lighter to save compared to holding onto more complex data types.
Example of retrieving relational info from a string:
You may not be able to convert everything into a string but I am finding that in most cases, it is possible for me. This has helped increase productivity. It seems no matter how much I worked with maps and structs, it is always a slow and error prone process. Making better use of strings is streamlining the process considerably.