Access to Datatable Row Name as a Blueprint option?

I completely disagree. That’s not the purpose of enumerators. They mesh well with switches, select nodes, can be used for short dropdowns menus, lists. If I need to choose out of more than 20 of something, I’m definitely not using an enumeration for that…

Datatables. And fetch stuff by name.

I slay a monster and it drops a weapon: I grab a weapon struct by name (or randomly) from Weapons table (of 5000) - the struct has all the data the weapon needs, and one struct from the Enchantments table, also by name - another struct. My character will assemble these 2 into an actor and spawn it.

When I want to save my data. I need to save 2 Names. If my game allows for gear modification, I’ll save 2 structs instead, each full of modified values - the very same structs the datatable is using. When I load the data, I’ll use the exact same functionality when the sword was assembled. I’d use an enumerator to check whether the enchantment deals Fire, Ice or Poison damage. Or whether it can be used with a Helmet / Armor / Weapon.

If you wonder how the monster knows the name of the sword - they also got it from a data table - most likely some kind of randomised loot table.

Also, mapsare useful for handling uniquely named elements.

Yeah, no, that’s *precisely *the reason why I do not want an enum with 20+ names. I have a procedurally generated world that uses about 30+ enumerators, only 1 or 2 have more than 20 elements and working with them is already annoying. The save game stores over half a million variables in nested structs (just for the world, ofc).

How do you even choose something from a list of 100 without tearing up? **@GeeksGoneBad **surely knows the pain. 800+ !

I don’t get this one. Why would I *ever *need to search for something manually. The name of the sword is in the datatable, my character stores it in a variable / struct… The only time when I’m going to type a name is when I create the actual spreadsheet. Everything else will be based on that. If I misspell in my own cvs, then I’ll have it mispelled in the game, sure. It will still work, just look stupid. Which I’m quite OK with, since I can open the cvs, find the offending entry, fix the typo. Save. Reload the DT. Done.

If I store a class reference or asset path:

Texture2D’/Game/Assets/Modules/Iso_Burner_IB66.Iso_Burner_IB66’

I’d rather not misspell that, for sure.

I don’t get this one either. Your DT identifier should be static and different from the item / skill name, players can rename whatever they want but they will not touch my IDs! What I know as swordsID_twohanded_totalOP_epic_666 should never be exposed to the player and will never change. The player can keep the custom name in whatever other dedicated variable, but it will never be used to fetch anything - it’s just a display name.

You can’t save in DTs in vanilla blueprints - there are plugins for that (and even proper data base), though. When working with Save Game objects, you will be, primarily, saving arrays of structs, often nested. These will be often the very same structs the DTs are using.

So in the end you loop through the player’s inventory / skill tree - query them for actors, assemble it into arrays of structs and save. It’s restored on Load.

2 Likes