Particle Emitters should have a "PlayOnRemove" property

Feature Requests Engine Features
#1

Currently, all currently emitted particles disappear the moment you call Destroy() on the ParticleEmitter. But, this isn’t optimal for animations where the particle emitter is only used for a short duration of time (for example, only calling Emit() on the ParticleEmitter once and then destroying it). This is problematic as it makes code longer and dirtier.

Currently, this is what developers have to do to ensure the particles all play in a scripted animation:

local ParticleEmitter = --> particle emitter without "PlayOnRemove"
ParticleEmitter:Emit(100)
task.delay( --> waiting until all the particles complete their animation
    ParticleEmitter.Lifetime.Max,
    function()
       ParticleEmitter:Destroy()
    end
)

-->> rest of animation

If PlayOnRemove is implemented, this would be the resulting code with the exact same behavior as the code above:

local ParticleEmitter = --> the particle emitter with "PlayOnRemove" enabled
ParticleEmitter:Emit(100)
ParticleEmitter:Destroy()

-->> rest of animation

This type of logic is used quite frequently and thus should be implemented.

23 Likes
#2

Support.

However, I usually don’t call Destroy directly on the ParticleEmitter, but rather one of its ancestors. I would instead want something that allows the ParticleEmitter to complete its Emit.

4 Likes
#3

Honestly, I think that something like workspace:EmitParticleAt(particle: ParticleEmitter, cF: CFrame, spaceSize: Vector3, emitAmount: number) would be better. We would be able to emit particles more easily and, since we wouldn’t need them parented to a specific part when they’re just, for example, explosion effects, there shouldn’t be the issue of them disappearing all instantly after the part they’re parented to is deleted.

But yeah, a PlayOnRemove property would be good for particles that are for a specific BasePart or use .Rate too.

1 Like
#4

It probably wouldn’t be a CFrame, but rather a BasePart or Attachment, as the ParticleEmitter object cannot emit from just a CFrame.

But yeah, something like that would be much better, not only for convenience, but also performance.

1 Like
#5

Why can they not? They’d act as if they were parented to an Attachment if the spaceSize argument was nil or Vector3.new(0, 0, 0), but if the spaceSize was like Vector3.new(3, 3, 3), it’d act as if it was parented to a Part with that size. For the part’s shape, there is already a property of ParticleEmitters for that, which, by the way, make the ParticleEmitter not emit if the part’s shape doesn’t match the property.

#6

Sorry, I didn’t see that parameter when I viewed your message. It is definitely an option, but if MeshParts are planned to be supported in the future, then it may not be.

1 Like
#7

Absolutely.

I actually try not to constantly create/destroy stuff to put less stress on the memory management but if I recall correctly, parenting particles to nil, ReplicatedStorage or Lighting also causes them to abruptly disappear.

Even if not destroyed, I would like for particles to finish their life cycle even if I parent it somewhere outside of workspace. :frowning:

Currently I literally have to pull a task.spawn() or a task.delay() before removing/reparenting the particle emitter and it’s honestly a bit tedious.

2 Likes