Player: Don't emit dust particles initially

[wjt]

Since commit 63fdec1 ("Player: Use
InputWalkBehavior"), PlayerDustParticles.emitting is not updated every
frame; it is only updated when the InputWalkBehavior emits
running_changed. It is not explicitly initialised when the scene is
loaded. In player.tcsn, PlayerDustParticles.emitting was set to its
default value, true. As a result, particles are emitted until the
player first starts then stops running.

Set PlayerDustParticles.emitting to false by default.

The InputWalkBehavior change also meant that the particles' direction is
no longer updated as the player changes direction while running. Rather
than reimplementing this: change the initial particle velocity to 0, and
remove the code to update the direction. Having done that, we can
actually remove the entire player_dust_particles script, and connect
InputWalkBehavior.running_changed to GPUParticles2D.set_emitting
directly.

[github-actions]

Play this branch at https://play.threadbare.game/branches/endlessm/wjt/player-don-t-emit-dust-particles-initially/.

(This launches the game from the start, not directly at the change(s) in this pull request.)

[wjt]

I'm not sure about this solution. Another option would be:

diff --git a/scenes/game_elements/characters/player/components/player_dust_particles.gd b/scenes/game_elements/characters/player/components/pldiff --git a/scenes/game_elements/characters/player/components/player_dust_particles.gd b/scenes/game_elements/characters/player/components/pl
ayer_dust_particles.gd
index 71e8e5b6..1b3afda2 100644
--- a/scenes/game_elements/characters/player/components/player_dust_particles.gd
+++ b/scenes/game_elements/characters/player/components/player_dust_particles.gd
@@ -5,6 +5,10 @@ extends GPUParticles2D
 @onready var player: Player = owner


+func _ready() -> void:
+       _on_input_walk_behavior_running_changed(player.input_walk_behavior.is_running)
+
+
 func _on_input_walk_behavior_running_changed(is_running: bool) -> void:
        emitting = is_running
        if emitting:

But reading this made me notice:

threadbare/scenes/game_elements/characters/player/components/player_dust_particles.gd

Lines 8 to 11 in 36082b4

	func _on_input_walk_behavior_running_changed(is_running: bool) -> void:
	emitting = is_running
	if emitting:
	process_material.direction = Vector3(player.velocity.x, player.velocity.y, 0.0)

process_material.direction is only updated when the running state changes. So if you continue running but change direction, this is not updated.

I have to say that I don't see any visual issue with the direction being wrong, but you could imagine doing something like:

diff --git a/scenes/game_elements/characters/player/components/player_dust_particles.gd b/scenes/game_elements/characters/player/components/player_dust_particles.gd
index 71e8e5b6..68c0b992 100644
--- a/scenes/game_elements/characters/player/components/player_dust_particles.gd
+++ b/scenes/game_elements/characters/player/components/player_dust_particles.gd
@@ -5,7 +5,14 @@ extends GPUParticles2D
 @onready var player: Player = owner
 
 
+func _ready() -> void:
+       _on_input_walk_behavior_running_changed(player.input_walk_behavior.is_running)
+
+
 func _on_input_walk_behavior_running_changed(is_running: bool) -> void:
        emitting = is_running
-       if emitting:
-               process_material.direction = Vector3(player.velocity.x, player.velocity.y, 0.0)
+       set_process(emitting)
+
+
+func _process(_delta: float) -> void:
+       process_material.direction = Vector3(player.velocity.x, player.velocity.y, 0.0)

[wjt]

@manuq WDYT?

[manuq]

@manuq WDYT?

You beat me with this one, I saw the issue yesterday!

I'm not sure about this solution. Another option would be: (...)

Yes in some cases we ensure the initial state when running in game (not in editor) at the _ready function.

So if you continue running but change direction, this is not updated.

Oh good catch! I think we can just remove the horizontal velocity of these particles:

It's a subtle touch but it makes things more complex than needed. I just appended a fixup for this. If you agree, please adjust the PR description and squash&merge.

[wjt]

If we remove that, should we also remove the code to change the direction?

[manuq]

If we remove that, should we also remove the code to change the direction?

Yes absolutely!

[wjt]

I realised that if we remove that velocity-update logic, we can actually remove the whole script!