I was trying to create a persistent list of bp actors, to use later without having them all in the scene. To automate a process of spawning interior meshes in the rooms in game. I had built a system that collected in a dictionary all the rooms actually spawned and validated, then another that took all the ismc contained in the bp interior, and for each spawned room, compared the tags of the ismc with the socket name of the room to check that the chosen ism was compatible, then I went to create another dictionary, which for each room, had a random ismc, to vary the map, but still compatible with the socket of the room (they are not all the same), with other coordinates that I used to upgrade the transforms in case the ism did not snap well to the target socket. But the system I had before (all the isms in a single bp), gave problems with the current ism variable at the time of spawning in the rooms, each ism was no longer treated independently but all in unison were altered at a new loop. So now I’m trying to randomly but compatiblely associate one of these bp actors, from which then at the time of spawn/add instance, I will do a get component, taking the right ism. @ClockworkOcean
@ClockworkOcean Sorry I tried to be as brief as possible, but the reason behind this choice was complex. I hope it is understandable.
Ok, no, you don’t need to refer to the asset registry to do this sort of thing. But gimme a little while to re-read your text…
So you just want to spawn random rooms with random items in them, and the rooms can connect in different ways?
Each room can be a blueprint. You know from the type of blueprint, what other rooms can be connected to it. You also know, from the room type, what meshes can be spawned in the room.
Each room can just have a list of classes that can be spawned as meshes in the room.
Shall I do a small example?
@ClockworkOcean I currently have the bp of the rooms, I should just convert them because at the moment each room is managed as if it were unique, but in any case the rooms can repeat themselves and with nodes in the materials take on different aspects. So later I think I will also convert the rooms to ism to reduce calls. At the moment the spawn of the rooms works. But yes, that is, if you have any suggestions instead on their interiors, I’m listening!
So this is very basic. I made a room parent BP,
It has
. 4 spawn points
. An unset mesh
. A list of possible things to spawn
To save time, I set the spawn list in the parent, it just chooses one mesh randomly and puts it in the center of the room
This means all child BPs will also have this.
Then I made a ‘square room’ BP, with this mesh
See the only thing I did here, was set the mesh.
And a round room BP
No corridors etc. These could be part of the mesh or separate. We also need a way of knowing if we already have a room at a spawn point. The easiest way to do this is overlap, so I included collision boxes in the parent
Then, because they are in the parent, the appear in all the child BPs
Now I can tell if we already have a room. I have set the events so I can call them in editor, and check it out
This script is just
These are just ideas. You can see I’m not using the asset registry.
It’s very interesting and cool the approach you used! Except that I already have a system that spawns on random points of the room and checks if there are one or more overlapping rooms, and if so removes them. I mostly wanted to make sure that the bp list for the meshes that must populate the room, “populates” and “updates” itself, in reference to what is available inside the folder where I’m creating all the bp related to the ism interior. That is, without the asset registry I would have to drag all the bp into the scene, before being able to get references to automatically add to the bp list.
Also because, if I inserted an instanced static mesh inside the bp of the same room in which it can spawn, as in this example, however then for each room, each ism would be an additional draw call. Instead I am trying to instantiate the same one x times as necessary, to have as many isms as possible in a call.
@ClockworkOcean
I must say, no point in using ISMs, unless you’re going to have 1000’s of copies of each mesh.
The problem is that I have a procedural map that can tend to infinity based on the current record of the players @ClockworkOcean
Is it multiplayer? If not, then I’d take a look at streaming or world partition.
Yes I’m trying to make a 5 player coop
Even if you’re instancing, that will only be happening for each player for the meshes they can see, not all meshes in the game. It’s a GPU based thing.
In fact, I was then thinking of integrating a pool system, based on distance, where unnecessary assets are temporarily deactivated and not rendered. @ClockworkOcean