Plugin Object Pool Component

[BrUnO XaVIeR]

Thanks. So just to be clear, if I had 500 different projectile types, each player would have 500 pools? Is that possibly an issue?

Yes that would scale badly.
I would develop projectile sub-classes in case like that, i.e:

APooledActor -> AProjectile...

Then code the AProjectile Blueprint to "change behavior" depending on weapon equipped, to avoid doing that.

Making that many pools would be horrible.
I would just go without pooling then, too many allocations.

[Vaei]

Hmm there's still one issue with that. If the projectile is an actor with components for collisions, but those components have various components for visuals and audio fx that are specific to each projectile I'd still end up having to spawn those, right?

I guess I could add some components in advance and simply not use them for some? Will there be overhead with changing the particles on each spawn?

[BrUnO XaVIeR]

Hmm there's still one issue with that. If the projectile is an actor with components for collisions, but those components have various components for visuals and audio fx that are specific to each projectile I'd still end up having to spawn those, right?

I guess I could add some components in advance and simply not use them for some? Will there be overhead with changing the particles on each spawn?

I will investigate if it's possible to "multicast" a Pool Component; that would be ideal...
I have NO idea if that would be possible, but if there's a way to do that you could then have all projectiles pooled from the same memory pool component.

[Vaei]

I'll work on a solution that works with the current system, meanwhile I'll cross my fingers but not hold my breath for your solution

[Vaei]

ExposeOnSpawn + SpawnActorFromPool node still reads default value in C++

[BrUnO XaVIeR]

Expose on Spawn only work based on the custom Spawn from Pool nodes.

It's the Node whose does all the expose setting, if you call Component functions in C++ all that process is skipped (no Kismet Compiler involved).

[Vaei]

Makes sense, thanks for clarifying

Edit: Actually makes a lot of sense, it's the same for the default UE4 spawn actor nodes too, which is why you use deferred (and you have deferred from pool nodes, so that works fine)

Edit again: Nope doesn't work, OnPoolBeginPlay is being called after BeginDeferredSpawnFromPool and not after FinishDeferredSpawnFromPool - I believe this is an actual bug?

[Vaei]

Let me provide an example. This code is responsible for firing the projectile. It spawns the projectile deferred (BeginDeferredSpawnFromPool), then it sets the settings for that specific projectile (OffsetTemp for this example), then it completes the spawn (FinishDeferredSpawnFromPool). The issue is that OnPoolBeginPlay is called before FinishDeferredSpawnFromPool is called which defeats the purpose of deferring the spawn.

AVWPProjectile* UVWProjectileComponent::FirePooledProjectile(const FVector& OffsetTemp)
{
    if (!InstigatorActor || !Handler)
    {
        // Died during firing sequence?
        return nullptr;
    }

    const FVector SpawnLocation = GetFireLocation();
    const FRotator SpawnRotation = GetFireRotation();

    AVWPProjectile* NewProjectile = nullptr;

    bool bSucceeded = false;
    APooledActor* PooledProjectile = UObjectPool::BeginDeferredSpawnFromPool(this, Pool, FPoolSpawnOptions(), FTransform(SpawnRotation, SpawnLocation), ESpawnActorCollisionHandlingMethod::AlwaysSpawn, InstigatorActor, false, bSucceeded);

    if (bSucceeded && PooledProjectile)
    {
        NewProjectile = Cast<AVWPProjectile>(PooledProjectile);

        NewProjectile->PooledProjectile->OffsetTemp = OffsetTemp;  // Already OnPoolBeginPlay has been called, it's too late to set defaults

        UObjectPool::FinishDeferredSpawnFromPool(PooledProjectile, FTransform(SpawnRotation, SpawnLocation));
    }

    return NewProjectile;
}

[BrUnO XaVIeR]

I will note this and step through code tomorrow morning.

[Vaei]

I did a temporary fix in the meantime. I moved SpawnFromPool out of BeginDeferredSpawnFromPool into FinishDeferredSpawnFromPool. I also had to expand FinishDeferredSpawnFromPool with the options required for SpawnFromPool.

[BrUnO XaVIeR]

I remember there was a reason why I moved it into BeginDeferred...
I just don't remember anymore what it was

But engine have changed so much, need to revision that code again.

[Vaei]

Think you could also provide SetLifespan / GetLifespan methods (for the pool) similar to AActor? I added them on my end for now. It's just that I use them for cleaning up projectiles

Edit: Just to clarify, I can't simply add them in the derived class as the handle is private

[BrUnO XaVIeR]

Sure, will make that change as well!

[BrUnO XaVIeR]

I did a temporary fix in the meantime. I moved SpawnFromPool out of BeginDeferredSpawnFromPool into FinishDeferredSpawnFromPool. I also had to expand FinishDeferredSpawnFromPool with the options required for SpawnFromPool.

Instead of changing all that, I believe you can take these calls out of APooledActor::SpawnFromPool() and just move them into APooledActor::FinishSpawnFromPool():

EVENT_OnPoolBeginPlay();
OnPoolBeginPlay.Broadcast();

The actual bug is that APooledActor::FinishSpawnFromPool() is called too early.
I'm fixing that now.

[Vaei]

Thanks a lot for that.

Do you know what's stopping them being showing up on clients? I was going to add network support but this is not a very apparent issue. I log their spawning, I also log their destroyed function, they all spawn properly and none of them are prematurely destroyed.

But after they spawn, they don't exist on the client. Only the server. How do I get them to stay after spawn on the client, or show up? I can't tell what's going on.