Super! Thank you. Going to get Auto-Save now.
I have some ideas for alternative usage of this system. What would be the best way, for you, to discuss it? I don’t want to post it in public, but neither DM you directly without your consent
Super! Thank you. Going to get Auto-Save now.
I have some ideas for alternative usage of this system. What would be the best way, for you, to discuss it? I don’t want to post it in public, but neither DM you directly without your consent
You can DM me no problem, I get PM all the time.
Haven’t tried it, but sounds like a great idea. Simple / generic concept applied where needed, well done mate!
PS -
can you please ADD : LIFE SPAN ? so when it ends it will auto POOL IT BACK?
thnx
This already exists on latest plugin versions. On details panel of your APooledActor you will find a pool lifespan property.
Update 1.3.5 with compatibility to Particle Components attached to Pooled Actors have been published to Marketplace.
Is there any way to wrap any actor to pooled actor on the fly, without making separate class/blueprint for that? I have spawner, where I can select any actor class to spawn. Now I want to add object pool support for it and found that I need a proxy class (pooled actor) for each object to spawn, which is not perfect in terms of flexibility. I guess you need to make another one Spawn Actor from Pool node, which could take any actor as input parameter, then in C++ dynamically make pre-defined Pool Actor, which has ChildActorComponent variable and populate it with defined actor (it’s just rough assumption, because I didn’t dig into your code yet, so maybe there are some caveats).
I have remade this plugin for around 10x; the reason I endup with this architecture is because the way Unreal works. Pooling ordinary AActors wasn’t giving any noticeable performance boosts, I had to introduce intermediate C++ Classes to make performance work the way I was expecting it to be…
By the way, you lose absolutely zero workflow when re-parenting your base class to APooledActor instead of AActor, there’s no drawbacks in doing so; the plugin provides a custom Spawner node and C++ functions exactly to cover such a case, you can spawn any actor that is a child of APooledActor there.
There are some reasons against re-parenting. What if in future I’ll decide to not use this plugin for some reasons? What if I have hundreds of actors, which I need to re-parent? What if I decide to re-use these actors in another project, where I can’t use your plugin? etc… Of course, all of these issues can be solved, but it will require additional time and efforts. Your PooledActor derived from AActor anyway, so I wonder did you tried to add ChildActorComponent to it and test performance? I assume it shouldn’t affect performance, because otherwise even if you reparent existing actor to pooled actor if it has heavy components (like ChildActorComponent, because it’s also possible) in it, these components will remove all benefits of pool in case if they won’t stored within an actor in the pool.
As far as my personal experience goes… Every single project I worked on everybody had a base Actor class derived from AActor for the game in question; nobody went creating multiple different instances of AActor creating multiple different base game classes.
This is why I see no issue with this. All they had to do was reparent from AActor to APooledActor and the game development is flowing smoothly.
Reparenting is an issue when the base class is a Blueprint, which is not the case here.
If you decide to not use the plugin after building on top of it… a quick reparent back from APooledActor to AActor is enough as long you have a base class for your game which is a child of AActor instead of using AActor as the base class itself.
Why you need the same base class for trap and for the main character, for example? They even have different parents (that’s why, I guess, you have a separate pools for characters, pawns, etc). It’s better to have classes with loose coupling, otherwise, later it might be hard to separate trap from main character by removing base class, in case if you want to re-use trap in a product, which you can only sell without your plugin(and probably you will need refactoring, because there can be a properties in base class, which some of the derived actors, like trap, are not using). Moreover, if you’re using content from third-party sources, like UE Marketplace or Gumroad (here you can find those hundreds of actors, which you need to reparent), then in your case, you need also to re-parent everything to the base actor class, which is equivalent to reparenting to pooled actor class and is not needed in most times, especially if third-party content is regularly updated (so you need to do this action multiple times).
But I see now that there are no chances for such change, so will try to do this by myself.
Yes; I am not willing to support third-party Marketplace products with this plugin; that is a decision the project developers might do and make the changes they need themselves.
Am I told about supporting third-party Marketplace products? I even can’t imagine how you can do this, even if you wanted. I told that many of your users(including me), which you should support, use third-party marketplace products or community projects or already have a lot of actors in their projects and games and it might be a trouble to re-parent all content from them, especially each new update. I told that current architecture is not flexible enough (even if you re-made it 10 times) and it would be great to fix that in future updates. But if it’s not possible, then ok. Don’t be angry because of that.
I’m not “angry”; I’m just saying that the focus for this tool is performance, not flexibility.
sent you a pm, but decided to send it here in case anyone else had same problem…
Hello ,
I would greatly appreciate some help implementing your object pool.
I read through your instructions but I am not sure I am using it correctly.
Create an object pool by clicking in asset browser, selecting synaptech and then object pool and named it BP_Projectile_Pool. OK
Go into (in my case) redtrooperbullet.blueprint and reparent it to (S)Pool Actor. OK
This is where I got lost:
3. Create a new blank actor? and insert the BP_Projectile_Pool component into it? Do I have to place this actor into the level? In this new blank actor, I should select my redtrooperbullet.blueprint and select “200” as the pool size… Am I doing this correctly?
Are there any other steps I missed?
Thank you!
Reinaldo
An Actor somewhere in the Level must have a pool component attached; I usually add the component to the gun.
Then that Component manages the class of the pooled projectile you’ve created on Asset Browser, spawn/return, etc. there are some nodes you have to use instead of the regular Spawn Actor or “Destroy” node to make use of the pool component correctly.
There is a demo project with a pool component and a pooled Actor here: Dropbox - File Deleted - Simplify your life
You don’t have to reference anything; the Pooled Actor always knows which Pool Component is its owner. they communicate automatically in C++ without requiring you to setup this stuff.
On the Gun you’ll want to get drag a ref of the Pool Component to call “Spawn from Pool” node, but that’s pretty much all for it.
On the Pooled Bullet you’ll want to use the “Return to Pool” node when you want to destroy it.
Hi!
I saw you use separate begin/end-play events. I was wondering if you had looked into resetting the actor and reusing the standard events. If so, did you get very far?
I would assume the goal of pooling is to get around all the stuff that happens before BeginPlay is called, so I know a full reset of the actor would be bad. I was just wondering if there was some way to just let a pool use BeginPlay and EndPlay normally. Or if you had gotten anywhere at all trying to find a way.
UPDATE: I think I figured out a way to do it. At least, it looks like its working. If you would like to reuse the Begin/End Play events instead of relying on your own events, I’d be happy to share. It’s a bit hacky – in the sense that if the engine changes it will break this solution. But it doesn’t look like that part of the engine is changing any time soon. We should be trying to get an otherwise innocuous change into the engine source but for now I think you’ll like what I came up with.
, I successfully implemented the pool component into my hero character (all of my firing is done from inside my character)…
1 Issue I have is that your Pooled Projectile (that replaces Projectile Movement) does not allow a “Set Homing Target Component”… why is that? That is something that Projectile Movement allows…
Also, how can I expose the parameters I need from the construction script (before I would allow properties such as speed, damage, controller id, to be exposed on spawn )
Spawning bullets with physics enabled also seems to cause a problem where the bullets dont render - but they definetly get spawned and hit things (I have audio, phsyical and damage cues to show that).
Taking off the physics renders the bullets properly… but I want bullets with physics enabled so that is not a solution for me… do you have any of this on your end or is this just me?
I am still a bit confused by the following: I named my pool blueprint the same as yours it is called Bp_Projectile-Pool and I use it as a component inside my hero character, who then calls it whenever he wants to spawn the bullets - but I am not sure if once I make that component blueprint (bp_projectile-pool) Do I ever need to change anything in that specific blueprint, or do all the changes need to be done inside the actor that is the current owner of that component(in my case my hero character has the object pool component, so all the changes like template class, pool size, thats all done inside his blueprint and never in the actual bp_projectile-pool blueprint?)… I have been making the changes in my hero character and that has worked, but just wondering if this is the workflow you intended?
This is dangerous, so I don’t do it.
This have never been requested, so it’s probably not exposed, I will have to check why is this way in the plugin.
Check on properties “expose on spawn” checkbox, on your blueprint. They show up in the spawn node after that.
There’s something wrong with your SpawnOptions struct if this happens; check the options you use, Unreal is a little annoying with these settings and they cause this kind of problem when misused.
It’s your choice, I also prefer to control things in the character blueprint too; works fine this way.