Particles2D one shot, pauses too long before being able to emit again - (solved - kind of!)

BingBong

Ok, a strange one...

I have a particles2D scene, instances of are in another scene trigered by animation player setting emitting to on (on frame 5 of the animation in this case). The particles is set to a one-shot.

Now, In the scene with the particles node, when the emitting box is checked in the inspector, the particles are emitted, live their lifetime (of 2 seconds) and expire, and the emitting checkbox goes off again.

Clicking the emitting button again does nothing, and will continue to do nothing until you wait 3 seconds after its turned itself off, THEN it will fire the particles again.

I wondered what I did in the scene with the animation player, was it waiting for the (0.6 second) animation to finish? but this problem seems to be coming from the Particles2D node... It should immediately reset to be able to emit particles again shouldnt it?

How can I fix this? :)

TwistedTwigleg

You might be able to work around the issue by calling the restart function, which may work. You can add a call method track if you want to call restart from the AnimationPlayer.

It is strange that there is an additional second delay added to the lifetime of the particles.

BingBong

I did fiddle with that, and it does kind of work, kind of, however restart wipes the currently emitted particles whether or not the lifetime is up and starts again. I might (will) want the first lot of particles to stick around.

Its not that theres a delay added to the lifetime of the particles, theys gone in the specified 2 seconds, but a delay (of another 3 seconds) until they can fire again, however the animation can play again, just no particles... The actual animation itself is less than a second!

theres precious little code in this one too!

func _unhandled_input(event):
	if Input.is_mouse_button_pressed(1):
		triggered = true

func _process(delta) -> void:
	if triggered == true:
		$AnimationPlayer.play("sponge_puff")
		yield(get_node("AnimationPlayer"), "animation_finished")
		triggered = false

xyz

Yielding the _process() callback is a very very bad idea :) and that's probably the root of the problem. How about this for start:

func _unhandled_input(event):
	if event is InputEventMouse:
		if event.pressed and not $AnimationPlayer.is_playing():
			$AnimationPlayer.play("sponge_puff")

func _process(delta):
	pass

cybereality

I've never found a need to use yield. While it appears to make things easier, it usually just causes problems.

BingBong

Ok, that makes sense, I made the change and it works, but still have the same identical problem as shown in the gif above...

@xyz said: Yielding the _process() callback is a very very bad idea :) and that's probably the root of the problem.
		if event.pressed and not $AnimationPlayer.is_playing():
			$AnimationPlayer.play("sponge_puff")

@cybereality said: I've never found a need to use yield. While it appears to make things easier, it usually just causes problems.

Yes, I have needed it to stop things happening for various reasons in other snippits of code, though theres better ways, I havnt figured those out yet!

xyz

@cybereality said: I've never found a need to use yield. While it appears to make things easier, it usually just causes problems.

It can be useful in all cases that typically benefit from using coroutines, for example in generators that stream continuous data, you just yield in and out of endless loops as needed.

But I often see it misused and misunderstood in GDScript code. People who just started to learn coding should stay away from it as it can cause some serious confusion... and launch the code execution into oblivion like in this case :)

xyz

@BingBong Could you post new code and also animation tracks?

cybereality

Yes, it is a legitimate function. But most times people use it, they just want to wait, so using a timer (or even just setting a boolean) would work better and be less error-prone.

BingBong

This is pretty much it, its a fairly simple project!

xyz

It's explosiveness that's causing this apparent behavior. I just don't know if it should be considered bug or a feature :)

When one shot is enabled, the cycle lasts for two lifetimes; one lifetime to emit it all and one lifetime for all particles to die. This is all fine when explosiveness is 0.

However when you set explosiveness to 1, all particles are emitted at once and then they die at once when one lifetime expires. Now there's still one lifetime to pass until cycle is considered finished. If you trigger emission during that time, the cycle will be restarted but without emitting fresh particles (bug/feature?)

There's probably a workaround possible here but it really depends on exact behavior you want to get out of this setup.

BingBong

:( Your right... it even gets worse on the scale from 0.1 to 1 as you go up.

Not really a bug, not quite a feature, definately something that needs tidying! Oh well, lets see what 3.4 and 4.0 bring.

Would be nice to keep this behaviour, might try with instances of the flies instead of particles. Not sure if they will actually 'do' anything or are just background furniture yet!

xyz

You could create new particle node (or make a new duplicate) for each puff, let it live for one cycle and then delete it. It doesn't even need to be included in the animation track. Just trigger it with a tween.

TwistedTwigleg

@xyz said: You could create new particle node (or make a new duplicate) for each puff, let it live for one cycle and then delete it. It doesn't even need to be included in the animation track. Just trigger it with a tween.

Yeah, using multiple Particle nodes is what I would suggest as well as a workaround. Then the issue of having the particles stay for their entire lifetime shouldn't be an issue. Unfortunately there isn't a signal for detecting when particles are finished, but you could add a condition to check if emitting is false and call queue_free when it is for each of the spawned/duplicated particles nodes.

What I would recommend is making the 4 particles nodes children of another node, save that to a scene instance, and then dynamically instance it through code at the correct time. For the timing, I would suggest using a call method track to call a function to spawn the particles, so it still plays at the exact right time relative to the animation player.

xyz

Should this be reported as a bug or improvement proposal though? For things to be intuitive, one shot cycle should end as soon as all particles are dead.

cybereality

I'm still not sure I understand what's happening here, but the fact that it's so confusing sounds like a bug.

xyz

I'm not understanding it fully either :)

From the strict standpoint it's not a bug. Emission cycle duration is always kept constant. But this is not what one would ideally want when explosiveness parameter is larger than zero. However there seems to be actual buggy part of it - enabling emission during the cycle seemingly resets the "cycle timer" but doesn't reset the "particle status". So once you enter this state you need to wait out full cycle before trying to trigger emission again. Otherwise you can trigger it over and over without seeing any particles at all.

It's a bit hard to explain. Try to play with emit checkbox on one shot particle system whose explosiveness is set to 1.

I'm guessing peeking into Particle node source may help in figuring out what exactly is happening.

BingBong

Well theres lots of suggestions for workarounds, thanks, I'll work through those and see which is best. but it might be an idea for an improvement tho, this is the first time the problem WASNT my crappy code, a typo, or my lack of understanding!

But theres a major update to particles in Godot 4 tho isnt there? Havnt played with the current builds so not sure of the changes...

xyz

@BingBong said: ... this is the first time the problem WASNT my crappy code, a typo, or my lack of understanding!

Congratulations, you've leveled up! :)

Remember to stay away from yields inside _process(). Although it turned out not to be the cause of the problem as I initially suspected, it still made a clump on the stack and tangled the code flow without you even realizing it. This type of thing can cause serious crash-inducing bugs as the code grows more complex.