Hello,
I literally gutted my Blueprint and then compiled and compiled and I’m still getting hard references even though it’s empty. Known bug?
As a control I added a reference to the Game State. Then I deleted that reference. Resaved and recompiled. Still holds on to a hard reference of the Game State.
Is the Reference Viewer gospel? Will it load assets that are not referenced?
(post deleted by author)
That’s actually not a bug. It’s the same way in C++. Still a hard reference to your bp class in the Reference Viewer because the variable’s type itself names that specific class. That word “soft ref” is actually for the object reference that won’t load into memory until you want it to; that’s it, but it’s still referencing the class. It is how it works; otherwise, it can’t generate the class’s property.
Imagine you have an eraser in your pencil case (soft reference), while you’re writing your assignment with your pen (hard reference). The eraser is in the box because you don’t need it right now, but when you do, you take it out. The eraser is still inside your pencil case (loaded as a hard reference, just not until you want it). The pencil case is your game.
The only right way to use a soft reference is to use the base class and then call the interface function.
You are 100% correct. (Not even GPT and GEMINI could figure this out. They kept giving me wrong info all-day. The AI apocalypse is officially on hold… for now.)
I actually decided to create a Data Table that allows me to utilize the stored soft reference base classes from the associated Struct. Storing soft references in Structs creates a hard reference as well, but assigning a bass class and then defining that base class in the Data Table is A-OK. (I think Data Tables are read-only… unsure.)
Next I call the Data Table and its Rows and then I async load the base class variable of the Struct that is defined by the Table.
Glad I could help. I would avoid using a data table for that purpose. It will be quite messy as the development advances. The best I can recommend you do is to utilise interfaces. Interfaces came long before casting was ever introduced in Unreal. You can also call the “Does implement interface” node to know which class it executes on.
Some simple generic functions will do for multiple classes, like “On interact”, “On fire” or anything similar, which can support multiple types of classes using the same interface BP.
I disagree.
Interfaces are NOT good for spawning, which is why I need a reference to the spawned class. I use Interfaces for Blueprints to communicate, not to get actors that don’t yet exist in memory.
Data Tables are EXTREMELY organized.
That’s just my recommendation. After all, even if you use hard references for all classes, it rarely causes any issues. It’s just a small part of the game on modern hardware, nothing much, unless you are running the game on Windows 7 or XP, or you have 4 GB of RAM, which rarely be the case nowadays.
So, yeah. It’s a small matter.
Actually no.
Circular Dependencies can arise if you’re hard-referencing. It’s not just about what’s loaded in memory; it’s the ORDER assets are loaded in memory. A game can crash if A needs B and B needs A.
Small games may need not have this issue… but larger games ABSOLUTELY will.
A needs B, B needs C, C needs A, but A doesn’t need C is STILL a Circular Dependence.
You may want to look up REINST errors. I’m pretty advanced, and I’m working on a large project, so I’m very sensitive to memory management, and I want others who see this to know not to hard ref without reason.
hard references for all classes
True, and I think you misunderstood me. What I meant by that is that I’m talking about the spawning classes, like what you have there. Not every single class in the game. I also know that you already know this, as you have been in the industry for a while.
