I just have one smallish question. Is the need to bench then add an actor the only way you "allow" transfer of children between parent actors?
In similar systems that I have constructed in the past, I have used a number of methods for passing actors in different states.
Pass a fully instantiated actor via a transfer process. Nothing changes for the actor, beyond reassigning parentage.
Pass a cleaned actor via a similar process to the bench and add process. This was used to allow an actor to be reduced to a resting state as it were. In most cases you could think of it as a resurrection method that allowed discarded actors to be reinstated with only specified base properties in place.
Anyway, I don't use Lua at all, but I like these type of actor messaging models. I look forward to reading through the rest of your documentation once it's done.
>Is the need to bench then add an actor the only way you "allow" transfer of children between parent actors?
Currently, yes. Since this is sort of an entity component system and that actors can always create more children anytime they want, I suppose I just always assumed that actors could be "spun-up" with any sort of functionality and then deleted when not used.
Benching/Joining an actor is more for handling errors at runtime or for debugging ("If I temporarily remove this actor will it solve my issue?").
In similar systems that I have constructed in the past, I have used a number of methods for passing actors in different states.
Pass a fully instantiated actor via a transfer process. Nothing changes for the actor, beyond reassigning parentage.
Pass a cleaned actor via a similar process to the bench and add process. This was used to allow an actor to be reduced to a resting state as it were. In most cases you could think of it as a resurrection method that allowed discarded actors to be reinstated with only specified base properties in place.
Anyway, I don't use Lua at all, but I like these type of actor messaging models. I look forward to reading through the rest of your documentation once it's done.
O.