When you add a new TMap entry that uses an enum as a key, it should attempt to simply add a new entry using the lowest enum value that is currently not in the map. Otherwise, this makes editing such TMaps infuriating, especially with TMaps that are already populated with a large number of values.
TMaps with Enums as Keys should allow new entries by incrementing key instead of checking for defaul
This x 1 billion. It makes them pretty frustrating to use, I actually use them for a similar thing (collision FX)
I go off-topic here, but why exactly do you store Something that is accessed with an Enum in a Map?
Wouldn’t it be better to use a Switch on Enum?
Switch (sometimes) just translates into an if-else statement, which introduces branching. Sometimes it’s faster to just lookup directly (and more convenient, cleaner code etc.)
You could use a TArray and access the elements by casting the enum to an integer, by the problem with that is you might want to skip some entries for enums - so it’s not always viable.
^Are you sure about the Switch is a disguised if-else? in most languages it’s a direct lookup(because they are constants and not dynamic)
but you are right, with BP, a Switch is pretty ugly
I think it depends, as with all things in programming - but yeah I prefer the TMap approach, then if you add items you don’t have to dart around code to find all the places you used it and modify them etc…
If I was in C++, you’re right, I would use a switch for all the reasons you’d expect. In BP, its not really the same.
If you are using enum, to index TMap, then why not use TArray ? Access time will be much faster, as you will be accessing data directly by it’s adress (in Hash maps, there are several steps of indirection).
I would rather request better support for using enums as indexes in Arrays in blueprints.
Because you might not want an entry for all the Enums, and the end-user may need to know what enum each index corresponds too.
The issue is pretty much known… and pretty much backlogged.
Thanks! I failed to find this on my initial search.
That’s why better interface for blueprint would be better, than TMaps with enums. Using enums kind of defeats purpose of Hash map.
From performance perspective it’s better to have array initialized with all enum values, rather than TMap with only some enums.
With so few elements performance difference is negligible, probably not even measurable. ints/enums hash very quickly. Since you’re not adding or removing elements to the Map at runtime, your not making any allocations either. Array is probably faster for lookups since the memory is most likely contiguous, but not so much so that it’s worth wasting memory for and sacrificing use-ability.
This is mostly a design question IMO rather than a performance concern, but from a Use-ability standpoint using an array would be poor. Imagine as a C++ programmer you have (like OP) a bunch of physical surfaces. You want an actor to specify a bunch of impact effects for each surface type. You probably want to fall back to the default if an artist or designer doesn’t specify an effect for something. They edit these in the Blueprint defaults panel.
With an array, the artist/designer needs to know what element # corresponds to what enum. (Could be solved with details panel customization, but that’s a lot of effort for very little gain). They would have to duplicate items if they don’t have a certain impact effect for a given surface, and it opens up a lot of room for user error. You also need to consider what happens if later in the project, someone decides to add another enum / physical surface, even worse if they add it in the middle.
Anyway… just this dudes opinion…
EDIT: Better support for enums as Array indices in BP would still be useful.
I’ve come across this myself, quite annoying. Yes arrays make more sense to a programmer but if you want to present a nicer interface to the designers in BP and a few indirections aren’t a big deal then it would be nice to have sane handling of enums as keys.
And better handling of enums as array indices in BP, everybody wins!
Oh heck yeah. +1
From usability perspective I would not use enums in first place but GameplayTags, which are perfectly suited for this kind of situation (:.