That’s what 2.0.1 does.
It removes the warnings, stop using IsPendingKill().
2 Likes
When I click “Install to Engine” and select “5.0” and “Install”, nothing happened, it won’t start downloading. For 4.27 its OK.
Can you verify that, or it’s my local problem.
That’s Epic Games cloud servers problem.
They might take some time to sync around the world.
Best way to verify this is contacting Marketplace staff.
Hi @BrUnO_XaVIeR,
I’m trying to use pools to managed block actors created and destroyed by the player. I’ve had this functionality in my game without pooling from the beginning and have always spawned with the “Always spawn, ignore collisions” handler option. Unfortunately, this doesn’t seem to be working correctly with pooling. I think this is the correct implementation:
The problem is that if the player rapidly creates and destroys blocks while moving forward, the block seems to be using the ‘Try to adjust but always spawn’ option, and is offsetting by 10 or 20 units as seen here:
Blocks MUST always align on the 200 unit boundary, so I calculate that position exactly. This has to be coming from the pool manager’s collision handler check. Is there another setting or option I’m missing?
Thanks,
-Rob
I replied to your message there.
Please check PM.
@BrUnO_XaVIeR Hi! I recently purchased your plugin and it’s just great! However, I have a question - When I enable option “Never Fail Deffered Spawn” is it possible that not the last, but the first spawned actor returns to the pool?
For example, a player shoots a pistol and after each shot a cartridge case flies out. I would like there to always be 25 shells on scene. and when the player shoots 26 times the first and oldest cartridge case was returned to the pool.
I will investigate this soon, but I can’t this week.
1 Like
I’m still drowning in work, but I want to investigate this soon.
Maybe next weekend.
2 Likes
Okay I started looking into it this week.
When I find solution I let you know.
Any chance to get the full options of Projectile Movement into the Pooled version? Specifically, is there a reason Planar Constraints was left out? But all the other options are nice to have as well. Thanks.
I’ve submitted v.2.0.2 for review that should address this.
There’s no issues to my end like described previously, if you still experience weird behaviour, please share with a small project where I can run with Visual Studio debugger attached.
(2.0.2 is still under review)
I don’t suppose that includes expanding the Pool Projectile Component settings as well?
Sorry, I have now rushed to work on other things under close deadline.
I will take note and try it once I have the time 
1 Like
No problem! In any case, thanks for the consideration. I’m sure if it all works out, it’ll save a lot of time for others as well and bring even more value to your plugin.
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.
Hey there,
Just checkin in to see if there’s an ETA for this plugin to be updated to 5.1? It seems to still work but getting a warning when I open my project in 5.1 with the 5.0 version of the pugin.
Thanks for your work!
Garth
The update is waiting for review.
Epic Games is too slow to process these engine upgrades, they usually take several days to update marketplace plugins to new major engine releases. I’m waiting.
1 Like
You’re awesome dude, no stress. Thanks for pumping out the update so quick
Hey there, I just got the plugin and have been replacing my projectiles with pooled versions.
However, I have found that the PooledProjectile component’s collision detection isn’t as solid as the standard ProjectileMovementComponent.
My sniper projectiles are going through their targets without registering hits now. They have a move speed of 100000 and were working just fine with ProjectileMovementComponent.
Shortening the Max sim time step, turning on CCD, or increasing the Max sim iterations did not help, and they were also previously unnecessary.
For ProjectileMovementComponent, there is the option to “Sweep Collision”.
I am fairly certain that it is this collision sweeping that ensures that the projectiles are colliding properly. Is there any chance that this could be added to the plugin?
I will investigate that when I get home today.