Hello and thanks for the help
I’m creating a map of data objects that function similar to a DataTable but they require state / virtual methods. I’m considering using a TSoftClassPtr as a TMap key, ie:
TMap<TSubclassOf<UDataObject>,UDataObject> HeroMap
or
TMap<TSoftClassPtr<UDataObject>,UDataObject> HeroMap
I’m interested if anyone has feedback on this as it seems unorthodox are there unforseen problems this might hit?
While FName does ok for a key I’ve been finding it hard to proof for typos or make sweeping changes across many blueprints / levels / graphs accessing data by manually typed FName. ENUM is not an option because some of the lists exceed 255. While UE has some Asset management systems in place I find them too proprietary and I’d rather just use Maps/Array of data.
I’ve noticed that using either TSubclassOf or TSoftClassPTR, provide someusefull ‘features’ which I prefer:
- Can’t be typoed and easy to update/change name.
- Clean Searchable Context Menu that I can also drop into from the content browser.
- Can exceed 255 entires.
- Can search and replace all usages.
In this case there would only be one of each class in the data, instantiated at launch on the game instance, functioning as DataTables with state. These benefits of using TSoftClassPTR or TSubclassOf as a key seem huge but I’m concerned if there are unforeseen risks of using this as it seems like an unconventional approach.
At a glance the issues I can see are:
- TSubclassOf would force the class to stay loaded, but since these are always instantiated it will not matter and TSoftClassPtr could potentially be used instead.
- TSoftClassPtr seems to use much more memory compared to FName (At the least it’s a long FString and maybe more), but most likely this would be trivial?
To further clarify what I’m trying to do. A simple example of getting hero hero data and setting a flag on it. FName vs TSoftClassPtr
The context menu that both TSoftClassPtr and TSubclassOf use which I like very much:
