Soft Reference in a Break Struct counts as Hard Reference?

I’m trying to add a class check to find a matching entry in a DataTable by looking for either an Enum match or Class match. I tried to switch from a Hard Reference on the class to a Soft Reference on the class in the struct itself.

In my local project, I created a brand new BP Function Library and have just one function to verify references. Here is where I’m having issue, when I expose the pin to a soft reference the size map and reference viewer count that as a hard reference?


When the Soft Reference for ‘Class’ in struct is hidden, Reference Viewer shows no reference


When the Soft Reference for ‘Class’ in struct is shows, Reference Viewer shows white line hard reference

Shouldn’t the Reference Viewer show a red line soft reference to my BP_Character?

However, when using the Reference Viewer & Size Map tools it still shows that simply displaying the pin for the Soft Class Reference will be stored as a hard reference? In the Reference Viewer the line should be red if it’s a soft reference right? The size map also shows that it is having to load the full class.

If this is not possible, is there a better way I can check an entry in a data table without loading the full asset it references?

As far as I know the hard reference should be there simply by having a variable of type BP_Character Soft Class Reference in your ST_Character struct, regardless of what the value of the Class member is set to. If you look at the reference viewer for ST_Character it should already show a reference to BP_Character there.

If you want to get rid of that reference you can change the type to Character Soft Class Reference instead.
On a side note the BP_Character Soft Class Reference isn’t completely useless. While it pulls the reference to BP_Character into the struct it will still prevent the additional references to subclasses of BP_Character that you may set on the Class member of the struct.

Not sure what’s happening with the reference viewer though. It could be simply from the fact that the reference is necessary as soon as a pin of that type exists in the blueprint regardless of whether it’s actually connected to anything. Or it could just be a bug.
When checking the references I’d recommend to not rely on the default settings alone. From my experience you should also check different depth/breadth limits (or disable the limit entirely if the project size allows that).

Thank you for the explanation. So I guess even if you use a soft reference in a structure, it creates a hard reference? Unless that is the bug you’re referring to in the Reference Viewer. It does seem to be the case here:


Soft Class Reference in Struct has white line hard reference to the BP_Character

I suppose I could change to plain Character as you suggested, I’d loose the ability to easily find the class when setting up my data table but it might be worth the savings in memory for the reference.

Is there somewhere I can read more about that limited portion you mention here?

While it pulls the reference to BP_Character into the struct it will still prevent the additional references to sub-classes of BP_Character that you may set on the Class member of the struct.

I’d like to know more about the specifics, and maybe this reference to BP_Character’s soft class isn’t as costly as I’m lead to believe…

I cannot say for sure since I have limited knowledge on the internals of the engine so take everything with a grain of salt.

I believe that creating a soft class reference to Character as I suggested previously also creates a hard reference. So In a way you can say that. But the hard reference in that case goes to the Package that contains the native Character class instead. And since it is a package the reference chain likely stops there and won’t pull in as many additional dependencies.

However in the case of a class implemented in Blueprint the reference goes to the asset/package containing the Blueprint which in turn pulls in all the things the Blueprint depends on. That’s the case with your BP_Character class.

I suspect the reason for this hard reference from the struct is that the struct still needs to know the class that was selected when creating the soft class reference variable. After all it needs it to determine the available subclasses when you assign a (default) value to this member.

There’s been a similar discussion somewhat recently that contains a great link to an article that explains “Object references in Blueprints”. You can find the link in this post: Does 'Resolving' a Soft Class Reference to 'Get Class Defaults' Create a Hard Reference? - #10 by M0rph3u5_UK

Just found this topic and I think it’s almost the same question I asked here: Why is using a Soft Reference from an actor in Blueprints still loading everything in memory in the Editor (according to the Size Map). Am I missing something?

Even just referencing an actor as a soft ref in BP seems to always hard referencing assets (according to the Size Map). I don’t know if the Size Map thing is reliable or not in the Editor. I thought it would indicate something light if you don’t do anything with the soft ref (not Loading Asset or Casting).

It would be interesting if someone could shed some light!

1 Like

Yeah casting will also create a hard reference. That’s the point where interfaces come in handy as they break the chain of dependencies as well. Except for the dependencies used by the functions “declared” in the interface.
Components can work as well if you have access to an actor or know that you can cast to Actor and then retrieve a specific Component from it. Casting to Actor would only add the dependency to the native Package however the Component may have dependencies that you could avoid with an interface.

Thank you for the tips! Indeed, interfaces will come in handy for sure in that case. I also didn’t think about using components but that’s a really clever way as well!