Announcement

Collapse
No announcement yet.

Spawn Actor from Construction Script (loophole)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Spawn Actor from Construction Script (loophole)

    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.
    Last edited by namrog84; 02-05-2015, 05:11 AM.

    #2
    Does your bypass work? Generally you can spawn on construct as World instance don't exist at that point.

    Also you should post this in blueprint section, not feedback ;]
    =========
    My Tutorials:
    Basic knowledge about Classes and UObject environment and stuff like that

    Comment


      #3
      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.

      Hope that helps to clarify!

      Comment


        #4
        Thanks Nick for explanations.

        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.


        Thanks again and keep up the good work

        Comment

        Working...
        X