I recently noticed that when I create an array of several soft references of a specific parent class, the parent class itself gets a hard reference. I was able to avoid this by swapping class stored in the array to be the actor class instead and this did not no effect on how the code works. My question is, why would I ever use anything other than default classes (like actor or scene) for a soft reference class? Regardless of what class I put for the array, asynchronously loading the reference still require me to cast to some class (like actor) anyway right? So what benefit would I get from defining a specific class for the array if the asynchronously loaded asset still cant reference any of that classes properties while still creating an additional hard reference?
The reason is that it allows you to control more precisely the classes that are allowed to be assigned.
If you have a property that is just ‘Soft Class - UObject’, you can assign any blueprint to that property. But if you have a property that is ‘Soft Class - MyClass’, you can only assign blueprints that are children of MyClass.
This does result in a hard reference to the type you’re using for the Soft Class property. But you can mitigate that quite a bit by making sure that class is very small (mostly no other content references or properties/casts to “expensive” types.
This is easier when using C++ in your project because using a C++ class for the soft class doesn’t cause the same types of size problems as references to other blueprints.
Loading the class shouldn’t require any casting. You should be able to pass it directly along to object or actor creation.