Walk code fails when at the walk to position

[balloonpopper]

Bug description

I have a prop that has a walk_to x coordinate of 1044 pixels. When I walk to it my character ends up at X coordinate 1052 (it's a 1920 pixel wide game so the 8 pixels difference is acceptable). The look_at position is to the right, so when the prop is clicked, the character walks to x coordinate 1052 and looks to the right as expected.

If I click the prop again however, this code fires

func walk(target_pos: Vector2) -> void:
    is_moving = true
    _looking_dir = Looking.LEFT if target_pos.x < position.x else Looking.RIGHT
       <...>

As 1044 is less than 1052, my character (incorrectly) changes to a left facing animation for 1 frame, then as it's reached the walk_to location, turns back to the right to face the look_at position again.

It appears that the game might need to remember the fact that it's already at the walk to position when a prop is cleared and skip the walk phase, or have some sort of tolerance built in (e.g. don't walk unless you need to walk at least 5% of the screen width)

I've put in pictures of the prop, and the walkable area

Moving the walk_to location to ensure it's within the walkable area didn't help.

Steps to reproduce

This will happen with clicking any prop that you walk to - as long as the walk_to location doesn't end up being the exact coordinates the character ends up, clicking a prop will cause a walk animation to start.

Expected vs observed behavior

If the character is already at the walk_to location of a prop (or close enough to it) then they shouldn't "walk" if you click the prop again.

Environment information (please complete):

• Windows 10
• 4.4.dev3
• Copied the dev branch of the Popochui code today

Additional context

Add any other context about the problem here.

[balloonpopper]

I tried moving the walk_to location to ensure it's in the walkable area. The problem still happens (though now the player temporarily points downwards as the walk_to location is a few pixels below where they end up)

[stickgrinder]

Thanks @balloonpopper for the extensive analysis of the problem. I'll talk to @mapedorr to understand what's the best way to address this.

[stickgrinder]

@balloonpopper this should be fixed now. Are you confident enough to test in from develop branch?