How to spawn actors without creating references?

[BIGTIMEMASTER (Aljav)]

Is there a way that I can spawn actors from the game mode without creating a hard reference?

I watched the livestream about soft references and read the documentation, but I’ve found an issue here:

Loading a soft class creates object class which cannot be used to spawn an actor. In order to make it compatible, I have to cast to actor, which creates a hard reference.

Is it possible to use interfaces somehow to abstract the spawning? I’ve tried that but how do I get around the fact that the game mode has to reference the spawner, which then further references any actors it might spawn?

[Rumzie]

I’m not sure what the intent here is, as there may be a better way to approach the actual issue you have.

A soft reference is a just a string (path) to an object. IE the object must first be a hard reference to create a soft reference of it. When you get a hard reference from a soft reference you are just finding a pointer (hard ref) to the object by path.

Async load class asset is just loading a class definition, which is just being used to describe the type of object, it isn’t the object itself. Spawn actor is expecting you to provide a type of class so it can make an object from it.

Class is a definition
Spawning creates an object from the definition (class)

[Rumzie]

If it’s always going to be a subclass of an actor, why not just cast to actor class for your situation? Only actors can be “spawned” into the world.

If it’s just a UObject you are trying to create you can always run ConstructObject

[eblade]

? just spawn the thing

[BIGTIMEMASTER (Aljav)]

My intent is to avoid loading a bunch of actors which wont be needed for awhile, seen here:

What I can’t figure out is, I am using a soft object reference in the game mode, but it still creates a hard reference.

This seems to be the opposite of expected behavior?

Problem is explained in more detail here:
Object references in Blueprints. Object references are one of the… | by Morva Kristóf | Advanced Blueprint scripting in Unreal Engine | Medium

If I use a soft reference instead, then I should be able to only load the actors into memory once I actually need them.

[BIGTIMEMASTER (Aljav)]

Here is one detail I overlooked (from above article):
“Beware though, the type is still loaded when using soft references, so if the type is BP_Weapon , it’s still going to be loaded with all its dependencies; therefore, it’s best if you use a C++ base class for variable types (you can still have a BP base class inherited from the C++ one), or a minimalist BP parent class.”

I think that might be the cause of my confusion.
It is still going to load the actor into memory, so if i wanted to reduce memory, I’d make an empty parent class, that way only a child instances extra baggage is loaded when I dictate?

[Rumzie]

Here’s what I suggest. Yes use the soft object references.

No, do not async load them on begin play. Just make a custom function and only async load them when you need them. Or before you need them, or whenever you decide?

[BIGTIMEMASTER (Aljav)]

Begin play is just for testing purposes.

The problem is that the reference viewer still indicates a hard reference, despite using a soft reference only in the game mode.

So despite using a soft reference, even if I never load it, it looks like the problem remains that the the entire reference chain of the soft referenced object is loaded into memory - it appears both in the reference viewer and size map.

I must be doing something wrong, except I’ve reviewed the video and documentation and I can’t see how I am doing anything different.

[eblade]

… if you’re attempting to load them at begin play on game startup, what’s the point of delaying them from just being loaded to begin with?

to not have them auto loaded to begin with, you need to have zero hard references to them in anything that is loaded.

[BIGTIMEMASTER (Aljav)]

begin play was just for testing… I didn’t think that makes a difference here?

Without entering play mode, the reference viewer/size map should not show reference dependencies on the soft object, I thought.

[BIGTIMEMASTER (Aljav)]

Here is totally empty game mode. It has a variable, soft object reference to some actor.

Then the size map of the game mode:

(purple is the soft object referenced actor)

Am I misunderstanding, but isnt the point of using soft reference to avoid this?

[Rumzie]

I think it’s just because you’re using the gamemode and not another empty class. Gamemodes come with expected object references to be filled by default. Here is a generally blank class inheriting directly from a c++ base class.

Also when you pull off the class reference type reference to immediately get the class if you are going the class reference route (which aligns with better with what you wanted to do originally)

[BIGTIMEMASTER (Aljav)]

thanks, that’s interesting. I’ll take a look further into this.

I was thinking that I may be able to use Event Dispatchers as well which may help. Actors in the level could just bind to dispatches from the game mode, which means game mode doesn’t have to reference them.

But still at the beginning of the game, level actors would have to be loaded. Perhaps the usage of soft references isn’t so much for the purpose of actors - more for content. In all the examples I saw, it looked like he was using soft references to reference to things like skeletal/static mesh components, materials and stuff like that.

I don’t know how the lower-level stuff works and it’s probably deeper than I have need to consider, but it’s a curiosity and might help me improve memory usage as well - when game is first started, obviously everything in the game has to be made available somehow. When we are talking about references, it is probably just about to what degree are they made available, right?

So a hard reference has the asset and all of it’s dependencies immediately available. That is like, loaded in RAM I guess?

And a soft reference might be somewhere a little “further away”, and for it to accessed we first have to load it into more immediately available place.

Is it just not a possibility to load actors into a level at runtime without them being “staged” in RAM, assuming I am understanding this correctly?

[BIGTIMEMASTER (Aljav)]

actually, i think you answered this question already.

So if this generic actor was referenced and spawned by the game mode, that is okay because it will not add further dependencies to the reference chain.

You’ve demonstrated that it is not creating new references because of the soft reference, so I think that should solve the problem. I’ll test this out tomorrow and mark as the solution if it works out okay.

[Rumzie]

Soft reference is really just a file path as a string. So it only exists on the disk somewhere. In my example it exists on the disk and then when that actor is spawn obviously the whole actor is deserialized from the disk into memory.

Using dispatcher in the way you have described could work. You would simply pass your path string(soft reference) and do what you wish with it on the receiving end, but you might also want to do things conditionally, in which case maybe you pass more information. Do be aware that the actors have to already exist in the level to receive such events. Personally I would like to manage a system like this centrally.

What I would really want is potentially some type of manager to control spawning and loading based of a collection of soft references. I would suggest creating a subsystem to manage this for you because it would remain level agnostic but I don’t think you can create subsystems from blueprints yet. However, you could get really far using the gamemode as it is fairly singleton like in nature.

[BIGTIMEMASTER (Aljav)]

Thanks, this is becoming clearer.

It looks like at this point it would probably be best to dig into c++ a bit to solve problems at this level.

I think for my current project it isn’t necessary because even my original beginner code is still within tolerable levels for target platform (pc).

However, I think for the next project I ought to see if I can learn enough to setup some subsystems - seems like something that could come in handy especially for a game where I am trying to be a lot more careful about memory usage.

[BIGTIMEMASTER (Aljav)]

Here is a little experiment that seems to solve the problem using only blueprints.

I think it is similar to the abstract factory pattern? I have only read about that but never found a blueprint example so it is theory to me, but I think I’ve got the principle at play here:

First, here is the result:

In order to spawner any amount of actors, the game mode is only referencing this object class that I have called “AbstractSpawner”

In the Game Mode, I create the AbstractSpawner and initialize it.

(I needed to put out a dispatch to announce the creation so that any listeners to the AbstractSpawner can bind to it’s Dispatches at the appropriate time)

In the Abstract Spawner is just a single event which takes a name (or could be enum, or string, or some sort of ID).
It passes that along to a dispatch. In the level there will be a Concrete Spawner that will be listening for this.

The Concrete Spawner has the data base full of soft-references. I’ve used a DummyActor class to test.
First thing in the Concrete Spawner I’ve bound to the GameModes dispatch so that once that AbstractSpawner is constructed, then we can bind to its events.

And finally, here is an example of how spawning and actor from soft reference could be handled:

So, I think this accomplishes the goal of reducing memory usage and tight coupling.

Alternatively, perhaps you might have an AbstractSpawner that is an actor in the level and is mostly empty, same as the object class above, and it uses an interface to pass data onto the ConcreteSpawner, which is just another actor in the level, but it has the data base full of soft references.
This would work the same but probably be fewer nodes overall (for some reason I find event dispatches and binding to be messy and harder to understand)

[BIGTIMEMASTER (Aljav)]

Here’s better solution:

On game mode, just get actor with tag and communicate through interface.

This way the game mode only references the interface.

To keep the Spawner actor clean, abstract a database of soft-referenced actors to an uobject:

The Spawner Actor can create the uobject only when needed for spawning, seen here:

Reference view of the SpawnDataBase object:

It is holding an array of soft-referenced actors and successfully not generating any hard-references.

It looks like this is a cleaner solution than what I wrote above that accomplishes the goal. The game mode does not force anything to load, it uses a single interface call to communicate that some actors should be spawned, and the spawner actor also does not force anything to load until I explicitly tell it to.

Why use the Uobject though? Why not just put the soft-references into the spawner actor?
The reason is because if I do that, the spawner actor is then creating hard references. I am not sure why, but if I use soft references in a uobject, it works like I’d expect. If I put them in an actor, it still creates hard references.

This must indicate something about actors - something over my head. But at least this solution works and it is not too abstract or complicated to manage.