Looking at snagging this plugin, I have a couple of questions beforehand regarding how much effort it will take to overhaul my existing system to utilize it.
First, how well does it play with Child Actors of a given class?
My use case: I have a parent class PlayerProjectile, which contains a lot of core game logic but isn’t actually utilized at runtime, and a whole lot of child classes of PlayerProjectile which are implemented in game. The way that I spawn projectiles is with a class-agnostic function call; it takes as input arguments a PlayerProjectile class variable and a couple of other inputs (a charge float, an array of target actors, and a transform). The way UE works, the pins in the parent PlayerProjectile class set to “Expose on Spawn” will remain there and work correctly as long as the class fed via the function input is a child of this class. So I feed it a PlayerProjectile child class, a Charge float, and a Target array, and it all just works, regardless of which class I choose when calling that function.
Obviously, when pooling, each child class of PlayerProjectile will require its own pool on the back end. You can’t recycle RifleRound into RifleRound_Explosive since they have different logic. But I’m wondering how much effort it will take to spawn each actor from its own specific pool on the character, when there are many, many kinds of projectile and those kinds are expanding during development.
-If I use a Pool Component set to the PlayerProjectile class, will I be able to use the Spawn From Pool node to call any child of that class from its own pool? Or can I only call the SPECIFIC class configured in the Pool Component (i.e. I could only spawn the naked parent PlayerProjectile actor)?
-If I use a Shared Pool Component instead, will the fact that any arbitrary class of APooledActor can be used mess up the Expose On Spawn pins in Spawn From Pool? Or will I be able to feed in my generic Charge and Target variables as long as whatever subclass of APooledActor I use (in this case, all children of the reparented PlayerProjectile) implements those vars?
-Is there a way to automate the process of generating a pool for a potential class of actor, preferably at runtime? My concern is that any time I design a new child class of PlayerProjectile, I’ll have to go into every actor which can spawn them and add that child class to the gigantic array of classes in each one’s SharedPoolComponent. And this is a system that may not be readily extensible down the line (e.g. for UGC support or other expansions) since it requires hard-coding every class that can ever be allowed to generate.
I understand that any solution to this would necessarily limit my ability to set specific pool parameters for each child class; I believe I can live with that. What matters most to me is that I can offer up a child class of PlayerProjectile, ANY child class, and it will pool without me doing pre-work on the actor that calls it. Even if that means the pool has to be expanded at runtime, which was my original intent anyway (spawn new actors into a pool of size zero, and only pull from the pool when there happen to be actors that have been returned to it)
My other question is less significant but I’m curious:
The Pooled Projectile Movement Component already does the work of restarting the Projectile Movement Component after it has been deactivated, to enable projectiles to restart themselves when redrawn from the pool. Is this “reactivation” function call accessible outside of the Spawn From Pool logic? There are a couple of cases in my game where I handle punch-through type effects by destroying and recreating the PMC on the projectile (or by configuring it to Bounce, and then using the OnBounce Event to reset all of its data and cancel the Bounce) and it would be handy if I could instead sidestep these hacks and just say “re-activate PMC” using the Pooled Projectile logic which already does this.