Lesson Q&A

Use this space for questions related to what you're learning. For any other type of support (website, learning platform, payments, etc...) please get in touch using the contact form.

• Alternate ways to leave sound after queue_free()?DMKI don't really like that you have to wait until the sounds are finished before you actually queue_free() the node. For example if that node is in a group, when you do get_nodes_in_group('group_name'), that node will get picked up, even though the node isn't supposed to exist. Do you have any other ways to keep the sound running after you queue_free() the node? You could probably put the audioplayer node in other places, but I think that would clutter the project too much. One solution I came up with is just before you queue_free() the node, you remove the audioplayer child node and put it where the parent node was. This way you can still put the audioplayer nodes as a child. (Although, I'm not sure if the sound persists while moving the audioplayer node) What do you think about this approach? 1 0 Mar. 08, 2025
• order of functionsSootyHello, this was my code for the player in this lesson. I was having some problems and weird behavior , if i set collision shape 2d first in the die function, then the other things like sound and reloading the current scene do not work correctly, why is this? is it something with the collision shape being required for the physics process? func set_health (new_health : int) -> void: var previous_health = current_health current_health = clampi(new_health, 0, max_health) health_bar.value = current_health if current_health <= 0: _die() elif previous_health > current_health: hit_audiostream.play() func _die ()-> void: toggle_player_controls(false) collision_shape_2d.set_deferred("disabled", true) death_audiostream.play() death_audiostream.finished.connect(get_tree().reload_current_scene) func toggle_player_controls (is_active : bool) -> void: set_physics_process(is_active) weapon_pivot.set_process(is_active) weapon_01.set_process(is_active) 2 0 Feb. 23, 2025
• Any other options besides just adding AudioStreamPlayer nodes all throughout the project?SingleMom420To me this seems like a somewhat haphazard approach, but personally, due to simplicity and the small scale I've been working at for now, it's the one I've used on all my own games. But is there a better, more elegant way? For example, in another tutorial I saw they used a global scene that had 5 or 6 AudioStreamPlayers, which when needed would loop through to find a free player and then play the required sound on it. This had the advantage of allowing multiple sounds to be playing at once, and also avoided having AudioStreamPlayers cluttering all the other scenes. What do you think of this approach? Or could you briefly share any other approaches you think are effective for small- to mid-sized games? I saw you wrote in the other comment that large projects would use a "ticketing system" -- that sounds too advanced/complex for me, so I'm more so curious about feasible systems for relatively smaller projects (but still larger in scope than this course's demo game, for example). 1 0 Feb. 05, 2025
• Having multiple audio stream player for 1 scenePurpleSunriseHello, Just a quick question. Is it ok to have multiple AudioStreamPlayer for one scene (like we did for damage and die sounds). Is it going to affect performance in any way if I have a lot for example? I notice while making other games that when too many sounds overlap (non necessarily coming from the same source) some sounds play quiter than others or there could be some glitches in the sounds. What is the best practice to manage sounds on godot? Should I have them in separate busses or should I create a disposable audio player at need and then free that? Thank you! I feel I learnt so much!!! I can't believe I started this course roughly 3 months ago and already released some little games without ever watching tutorials! You guys are great! 4 0 Jan. 31, 2025