Play animated spirtes before object is destroyed?

Godot Version

4.3

Question

Hi all,

I am having a problem with the playing of an animated sprite(s) on an object that is being destroyed and don’t know what to do about it. I set a singleton type environment to play a sound while the destruction is happening, but, I cannot get the animated sprite explosion playing while the queue_free() is occurring and can’t think of anything to try. Like I can play it during the ready() phase or anywhere else just not at destruction. I created a singleton type thingy to play a sound during destruction but I can’t see what to do here for the animated sprite(s).

Any help on this matter is greatly appreciated.

Regards.

Without seeing code, so I am making some assumptions here.

You should play the animation (and do whatever else you need to do), and then queue_free() it. Calling queue_free() marks the object for deletion.

Wait for the animation to complete, then free the object.

Yes, that makes sense but I need the code to a wait about 1 second before the queue_free deletes the object. So, what would the best way to do that? Would using a timer/timeout signal be the best way?

I did try using an await signal on the sound and the player object didn’t appear on restart, this:

	tank_explode.play();
	await tank_explode.finished;

and then tried it on the animated sprite as well, this

	fx.play("explosion");
	await fx.animation_finished;

and the player object didn’t work on restart either. So, I am running out of options!?!

Regards.

Your initial post doesn’t mention anything about the player or its re-appearance, just that you cannot play animation/sound when freeing. So try to describe the actual problem more precisely and include the code that shows the context.

If you queue_free() a node, you’ll need to explicitly re-create it if you want it to reappear, or you’ll need to reload the whole scene.

Restart of what? When you queue_free() a player, there’s no such thing as restart. You need to create a new player.

Perhaps the issue is related to the fact you shouldn’t be using queue_free at all. Instead try this:

hide()
set_physics_process(false)

Then when you want to “restart” the player:

show()
set_physics_process(true)

Yes, what is occurring is that the player is cleared out of memory and then a new one is instantiated into the scene at the spot I have specified.

Unfortunately, I didn’t have any luck with your suggestion probably because a new instance of the player is sup[posed to occur after the game_over function is called.

There’s no much sense in discussing this without you posting your scene structure and all of the relevant code.

1 Like

The player character is destroyed when hit by a bullet of the enemy and vice versa and after that the game_over() function is run giving you the choice to play again, if play is selected re-instancing occurs of the game objects. Except that the player character does not re-appear if using await signals, and also timeout functions.

I can’t reload the whole scene I am trying to modify a bare-bones game to do some extra things it needs, and I am finding that incredibly hard not to mention the heat on top of that it’s 4 o’clock in the morning and this room of over 25C. I might have to drop it a make the crappy game in the course :sob:.

Ok, I’ll do it tomorrow, when it’s much hotter, I need sleep.

There is a lot of code to send: the player, the enemy, my attempt at an overarching game manager. Do you also want of the code that make up the menu at the start of the menu to access the games?

Oh there’s lots of code. What about the bullets do you need that as well?

1 Like

Send it all.

Found what the problem was, it was when the game_over function was being called. It needed to be just before, like immediately, immediately before the queue_free destroying the object, otherwise it wouldn’t work. The awaits for the animation to finish, threw this out out of whack. That is why sending the sound through the singleton worked - it didn’t interfere with the processing - it was on the same frame. I just didn’t think that one through.

Once it was on the same frame plain sailing - well as plain as anything I code is. But less said about that the better. Also good is the temperature is right down only 28 C in the computer room today.

Thankyou for the replies it kept me on my toes and trying to find the error and rubber-ducking the problem by explaining what was happening to you really helped.

Regards.

1 Like

Good you solved it, but that actually shouldn’t matter. queue_free() literally puts the request to free the object into the physics frame processing at the end of the queue and it gets deleted once the frame is over. Just keep that in mind in case it pops up again.