Right now I am creating a datatable of assets (for example) with fields like a static mesh, material options, orientation, etc… but then to be able to offer that as a drop down option in my Blueprint at designtime I have to also make an ENUM of basically all of the data table row names - so that I can later plug them into “GetDataTableRow” and get my asset settings…
What I’d like is just those data table row names exposed so I can have them in a dropdown without creating the ENUM?
Kind of like the variable type “Data Table Row” but what I need is “DataTableColumn”
Does that make any sense and is it possible with something that I have missed?
Sorry to push such a old post, but it makes totally sense I guess.And I do not find good answers for that case.
I would say, it’s not only about making the Enum with all row names… the bad thing abou that is, the need of having the enum and row names in sync all the time.
I think it’s very common to store things like EnemyTypes, ItemTypes in Datatable to have them easily reconfigured in that table. But I do not know to solve the problem, that “row name” of the datatable, can not be an enaum, but only be simple text.
How you UE4 experts handle this? Of course you can put you enum in column 2 of the datatable, and then work with “find” and search the datatable every time. But is that really the best solution? Would be very cool to be able to select a row from a data table simply with an enum in a choicebox. Same as with a Map with Enum as left side for the “key”.
Also this workaround with putting your enum on a normal column, loose the advantages of “row name” in a datatable that every “row name” must be unique name (key). Same as in a map. And that’s the same thing you want when putting your (as example) ItemTypes in da Datatable, you want that the rowname is a unique ItemType name.
Would be nice to hear your best practices for this.
Sorry to push that, but would be really great to hear something from an UE4 expert how you are working with datatable and handle “row names as enums” or why this is not important and how to design it else.
How are you imagining working with an enum with 100 elements? How about 5000?
I cannot, not without smashing my face against the keyboard that is. If you must use an enumerator for this, nothing stops you from making one, and converting enum->string->name, and fetching a matching row from the DT.
What I’ve had to do is use an Editor Utility Widget and build my drop downs in that and then I can assign my materials using functions - it’s not exactly what I was looking for but ended up being pretty good in the end and I didn’t have to create an enum with 800+ material names - but if you check out Editor Utility Widgets you might find they are pretty powerful!
Thank you, @Everynone: That is a solution of course, but it is the same (or similar) I described by myself, but also with all disadvantages:
You have to make sure manually that “row names” are a value from an enum. Check for Spelling, etc.
When you change values of the enum, you have to (and not forget) to go into you data table and change “row name” of the row which is representing the changed enum value
Perhaps I miss another design.
You said you think about 5000 values and that’s is making an headache working with enums for you. For me… more values, more sense to use an enum. What do you do, when you have a big bunch of items, character-skills, levelnames … or something else you want to store in global accessible datatable without enums? Without enums, on every access of the data in the datatable you have a simple string (name) you enter in ue4 and have to make sure everything is spelled correctly. Also you have no choicebox without using enum, you have to search for the item name manually (on paper? in a excel file? search the data table everytime self manually?) to search the string (item name, or else) you want to read out of your data table?
Also, without using enums, but use simple strings (names) by changing item-names (or character-skills, levelnames, or else read from datatable), you have to change all positions in your BPs where you access datatable by simply string of rowname. There is no reference then.
As I said… perhaps I miss the point in general and I should not use datatable. But then I would like to know, what is you best practice to achieves the same (or similar) result.
**Goal **is → Save items (character-skills, Weapon-types/attributes, levelnames, or anything else) in **datatables **(or in something else?) which are based on a struct.
And after store them in datatable (or in something else?), to have “something” which is not a simple string (or name) to have a easy to use reference from Itemname (character-skills, Weaponname, levelnames, or anything else) to make it easy to search in the data for the object you need.
Option like with enums to expose a Enum like “Items with a Itemname” to a BPs, so you can place a Item-BP in the world and select per Enum-Choice-Box which item this is (when Choicebox is used, setting are loaded from data table in construction script to make Item-BP the selected item from enum list)
How this is done without Datatable-row-name->Enum?
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.
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.
Thank you a lot! @Everynone
This explanation also show me that I have a complete other use case in my head.
And yes, I was wrong! Writing that … “more objects, make more sense of enums”… was incorrect. You got me, I was on a wrong track.
Of course, if it is too much, you will find nothing in “select boxes” with 5.000 entries, I agree now.
But, perhaps I can give a much better example which use case I have in my head, and why I (would) use Enums as row name for this (if I could).
You have 12 weapons. And 15 pickups.
The weapon in **one **Blueprint (WeaponBP). The Pickups are another **one **blueprint (PickupBP).
Each Weapon/Pickup details (reference to mesh, attributes,. etc.) are stored in datatables consistent of struct (e.g. weapons-datatable consist of weapon-config-struct).
All settings of each weapon/pickup in the world is set, by dropping the WeaponBP or the PickupBP from content browser to the world, and then under “details” of the BP a choice box is available. The choicebox has for WeaponBP all “WeaponID” (IDs which have readable names, which tells you the weapon) in it. The choicebox has for PickupBP all “PickupID” in it (also with understandable/readable names as IDs).
If a Level-designer change or use the checkbox of one of the BP, the construction script is running an load all data of related Datatable (one for weapons, one for pickps) and load all data to the object of the chooses ID in the choicebox.
The advantage is, you have one BP (or better saying one for weapons and one for pickup) and in the world/viewport you can simple change Weapons and pickups by simply change the Itemname/Weaponname in the Details of the object in the world. -> If somebody want to change the weapon in the level, just change the choicebox to another (readable) WeaponID/PickupID.
Now… all WeaponIDs and PickupIDs are Enums, to expose this variable as choicebox to the BP so in Viewport Details to make the WeaponID/PickupID selectable. Now of course, all of this Enums have for WeaponIDs/PickupIDs have to represent one (and only one) row in the related datatable. And now it would be very handy, to have the row name the same entries as the enums, so you can easily select the row without need of searching columns.
You have also advantages that row name must be unique. By putting the Enum of WeaponID/PickupID in a normal column, the enum could be doubled in the column without error/warning. Also a advantage, when the datatable row would be a enums.
Sorry, I hope this explanation is a bit better. For me, this was the main use case at the moment for using data tables.