Is it possible to spawn an actor into the world at runtime and have it properly stream with world partition? Testing this it seems to only work on actors placed via editor world. Is this a bug or is it not a dynamic system?
3 Likes
I believe if the actor itself has world partition settings set to location based it should keep that into account no?
Well these are the options I added to a test actor. I drop a few in the world (change none of the instance settings) and then hit play. Then ones dropped in work correctly, so I spawn another one into the world using SpawnActorFromClass. All of the same settings as the placed in world ones. I move far away from the spawned test actor and it never unloads.
So either this is a bug (right?) or World Partition simply does not work with dynamic worlds which super sucks if true.
2 Likes
I haven’t looked at UE5, but the way it worked in UE4, each sub-level was it’s own sub-World/Map/Level. Actors belong to a particular level. and when that level is unloaded, the actor unloads.
The problem with spawned objects is that they generally spawn in the “main” top-level “persistent” level. If you unload the world underneath their feet, they will fall to their deaths! Unfortunately, “Move Actors to Level” is an editor function, because the actors get baked into the compiled level files.
You can specify a level for an actor to live in, and thus to be unloaded when that level is unloaded. You do this with the Owner property. However, if the actor moves around and goes to another slice/tile/level, you have to move them to that level for them to follow its fate. It may be easiest to keep spawned actors in the persistent level, and instead do a pass through all actors of the class in question when unloading a streaming level, and explicitly destroy actors that happen to be located in the area of that level.
I’m posting this under the assumption that each tile in UE5 world partition is still essentially a streaming level. If it’s something else, then “do a pass across interesting actors and explicitly remove the ones you don’t want” is probably still a reasonble way to go …
To my knowledge World Partition doesn’t work the same as World Composition with the sublevels etc. Instead it uses an array of grids (they can be different cell sizes and streaming distances) that you assign actors to. That’s why you assign a grid to the actor.
However, it seems like World Partition doesn’t notice what grid the spawned actor is on despite the settings given to it. I don’t know if there is some sort of “hey register this new actor to your grid” or something system… but yeah doesn’t work.
Exciting! If there’s a new owner kind in addition to level, that’s pretty bold. I would have assumed they made each grid cell a level, and just managed them for you like that. Gotta take a look at the code and see what’s up!
Yeah might be a bug, but since there is a lack of documentation until release we dont really know the intended use of things like this. I know in ea we had some wp settings per asset. But in preview there are already some visible changes to the system compared to ea. I will take a look tomorrow and do some testing. 
//
Played around with it today, changed stream distance settings, changed default hlod layer.
Added custom hlod to spawned object. And it does say you can let the system decide. But indeed it didnt do much for me. Tried adjusting it so small gridsize + low streaming distance should have just unloaded the spawned object after walking like 10 meters away from it, but it didnt. So my guess is its a wip until release. We are going to have to be patient 
1 Like
I’m fine with being patient, I just wish they would address this question… it seems like the obvious first question when learning about World Partition, is it dynamic / can I add AActors to the grid at runtime. Without this, it’s still powerful but extremely less useful because a lot of open world games aren’t static.
From the original documentation:
It does say “when editing the world” but that is not what we are looking for.
We will have to wait and see
The World Partition system works by storing your world in a single persistent level file and subdividing the space into streamable grid cells using a configurable runtime grid . These cells are loaded and unloaded at runtime by the presence of streaming sources, such as the player.
When editing the world, Actors can be added anywhere and are automatically assigned to a grid cell based on their Grid Placement setting, found in their Details panels’ World Partition section.
That sounds a lot like actors would have to know what cell they are “in” and unload themselves appropriately. Of course, this then has the problem of “what do I do when the cell re-loads again? Can I bring the actor back somehow?”
I wonder if there are any bindable events for cells coming or going?
This is something my team is going to need to figure out. Large world with spawned pick up items, vehicle possession etc.
Hi everyone, sorry to jump on this thread, but I’ve hit an issue with World Partition and struggling to find any help.
Have any of you encountered an error message “World Partition is does not support static lighting” when trying to build your lighting? I have tried everything ,including striping all my assets off the map (including all light sources), only leaving the bare landscape and still get the same message when trying to build. Can’t seem to find anything about it online. I am pretty new to UE and i could be something obvious but so far it has eluded me
Thanks for any help you can provide!
So there is release about few month. Trying to find any info about cells and stuff and still no success. Did anyone figured out how to check cell bounds, add Actor to cell or something?
P.S. In my case even touched dynamic objects (like physics) didn’t get unloaded and fall to the abyss after level geometry get unloaded.
P.P.S. Not touched, but intersecting grid edge, which is interesting. And moving does not move it to another cell. Sigh.
I have a weird problem too about this topic. When I go and posses a vehicle which is added level in the editor, if I drive to a distance that will unload the cell which is vehicle spawn on, the vehicle destroy suddenly. But this was not a problem in matrix demo and city sample. I think the city sample might be the answer for our problem. Do you have any idea for my weird problem or the dynamic spawned actors witj world partition?
Any update on this topic?
1 Like
Is there any update on this? From my understanding at this point in time, unlike Actors placed before runtime, any Actors spawned in during runtime are placed in the persistent level and cannot be unloaded?
Yea, that’s still the case.
If you’re using an actor which was placed in the editor to spawn vehicles/pawns in game, you can work around this by having it destroy whatever it spawned on End Play. That’s also called when the world tile it’s on streams out.
To keep a vehicle or whatever from going poof when you move away, set a bool on the spawner if the player uses it, and check that before deleting.
For actors not spawned by something placed in editor, or that had the spawner stream out? Could do it the old fashioned way and have check distance to player in tick or a looping timer event to decide if they should self destruct.
Obviously this gets more complicated if multiplayer is involved or you need persistent respawn timers, but, yea.
4 Likes
Updates? Would really like to runtime spawn WP actors.
So right now you cannot use WP if you want any kind of player or environment spawned objects? Surely this is such a common feature it must be possible…!?
Sure you can, you just have to manage them separately.
Separately, the spawn-actor call does allow you to specify a specific Level to spawn in. Presumably you can, like, ray-trace to the closest support for the object you spawn, and spawn the object in the same world.
That being said, you won’t be editing that world on disk, so I’d expect that when it unloads, it’s gone.
Hence, why you should listen for world load/unload events, and have your own grid of “user spawned actors” that you can manage. Perhaps the simplest would be a savegame instance per world partition grid cell or something like that.