So it appears that I can’t “Spawn Actor from Class” inside “Construction script”
However, if I make a function, with a “Spawn Actor from Class” and then I call that function in the construction script, I can bypass that first restriction.
Either
I shouldn’t be able to bypass it(Am I causing a leak or anything?)
or
You should be able to call it from construction script directly
I feel like one of the 2 should be fixed, unless this was intended loophole?
I know the proper way would be to addchildactor component from the construction script directly. However, I was still curious.
We don’t let you use spawn actor in construction scripts because they’re run all the time. Whenever you change a property, move something, etc. So, unless you’re managing the lifetime explicitly of the actors you spawn, it’s very dangerous! As an example, if you spawn a new mesh in your construction script, and move it around, you’ll have one new mesh in your level for every tick that you moved your actor!
ChildActorComponent helps with this, because it manages the lifetime of the actor it creates. Every time the construction script is rerun, it cleans up the old version, and creates a new version.
The fact you can get around it is a technical limitation. Because we let you have shared state in the event graph, we can’t really prevent you from doing something like spawning actor in there. We could restrict it, but we felt that was far too restrictive in terms of general functionality! We figured that if people got to the point that they realized they could do something like that, they’d be advanced enough to know that it is potentially dangerous. At some point in the future, we may be able to be a bit smarter about that, but currently, we left the loophole in to not prevent you from doing all sorts of other function calls in the construction script.
In our project we use an persistent TArray<AActor*> ManagedActors; in the C++ base for our Blueprint.
When the CS reruns, we determine how many more actors we need and only create them if the amount of valid AActor* in the array is less than that.
Since the array is defined in c++ it is not reset to its default (empty) state upon every rerun of the CS. (hint for feature request Wanna be able to mark BP defined variables to “survive” rerunning the CS - i.e keep their value untouched. Probably via adding them to the ComponentInstanceData for that Actor/BP under the hood).
If we reduce the amount of Actors we need, we shrink the array by properly de-allocating the content (detach from any parent it may have, remove reference from array and tell the world to destroy that actor) - in that order.
The reason we spawn actors in the CS is that we want to be able to interact with them in the editor viewports during design/edit time in order to set properties of a certain selection set at once etc.
Sadly the ActorComponent so far did not give us selection specific details panel to work with… - will see what the new BP’able Components will bring in that regard.
Obviously this thread is almost a decade old, but an update for those who get here from Google:
Depending on your needs, instead of directly spawning actors, you may be able to add child actor components in your construction script.
In my experience, this is a MUCH better approach than spawning actors. The component automatically manages the lifecycle of the spawned actors, which means you completely avoid the common side-effect of accidentally spawning hundreds of unmanaged actors into your scene.
Wanna be able to mark BP defined variables to “survive” rerunning the CS - i.e keep their value untouched. Probably via adding them to the ComponentInstanceData for that Actor/BP under the hood).