Skip to content

fix: animation queue bug#1093

Open
DesecratedTree wants to merge 1 commit into
GregHib:mainfrom
DesecratedTree:animations
Open

fix: animation queue bug#1093
DesecratedTree wants to merge 1 commit into
GregHib:mainfrom
DesecratedTree:animations

Conversation

@DesecratedTree

Copy link
Copy Markdown

Root cause: When a gathering action (mining, woodcutting, fishing) ends either by the player walking away or the resource depleting the animation was never properly cleared on the client. The server's visuals.reset() clears the animation flag but not the animation data when the animation is infinite, and even for non-infinite animations, the client was never sent a "stop animation" packet because no one flagged the cleared animation.

Changes made (4 files):

Movement.kt:56: Widened the Walk handler's clearAnim() check from player.mode is PlayerOnObjectInteract to player.mode is Interact. This ensures animation is cleared when walking away from any interaction type (NPC interactions like fishing spots were previously missed).
Woodcutting.kt:101: Added player.clearAnim() after the chop loop exits. Previously the animation persisted after the tree was depleted, inventory was full, or the player lacked the level/hatchet.
Mining.kt:132: Added clearAnim() after the mine loop exits. (Mining already called it specifically on ore depletion at line 124, but not for other exit conditions like inventory full or missing level.)
Fishing.kt:141: Added player.clearAnim() after the fish loop exits.

Firemaking already had this pattern correctly at Firemaking.kt:95. No changes were made to this skill.

@skalfate

skalfate commented Jul 17, 2026

Copy link
Copy Markdown
Contributor

Interesting, I think it may also affect Shooting Stars where when I clicked off by clicking another ore it would be mining all the way there lol.

@GregHib

GregHib commented Jul 17, 2026

Copy link
Copy Markdown
Owner

I think it's more the animation should be cleared on walk rather than finish, iirc if a woodcutting tree depletes on osrs the animation doesn't get cleared and player will continue to cut until the animation has finished

@skalfate

skalfate commented Jul 18, 2026

Copy link
Copy Markdown
Contributor

ACKtually... lol glasses emote. Anyways Greg, Hawthorns fix are valid and I have sources. 15 year old sourcces. actionShowSources(lol):

https://www.youtube.com/watch?v=PWEMQrkkrkw

https://www.youtube.com/watch?v=oNLXem9vzoE

Mining https://www.youtube.com/watch?v=WGFDBX3O1yo

I'd say modern day OSRS is last resort.

Osrs past 2015 gets unreliable by the year.

@DesecratedTree

Copy link
Copy Markdown
Author

I think it's more the animation should be cleared on walk rather than finish, iirc if a woodcutting tree depletes on osrs the animation doesn't get cleared and player will continue to cut until the animation has finished

What the original RS2 did: When a tree depletes, the cutting animation continues briefly before stopping naturally. This is confirmed by the official wiki.

The animation must be explicitly cleared via clearAnim(), because it uses infinite = true animations that loop forever without server intervention.

Sources
RuneScape Wiki runescape.wiki/w/Trees:
"If two or more woodcutters are cutting wood and one of them completely cuts the tree, the rest of the woodcutters will still continue with the cutting animation in the air, stopping it after a few seconds."

RuneScape Fandom Wiki runescape.fandom.com/wiki/Trees: Same quote. The original game's finite animations played out their cycle then stopped.
Rune-Server RSPS source patterns (rune-server.org, 2009-2013): Multiple threads show woodcutting implementations where the cycle event/task stops when the resource depletes, implicitly ending the animation loop.

Greg is correct about the original game's behavior (finite animations end naturally). But this codebase uses infinite-loop animations and without clearAnim(), they never stop. My changes align with how legacy RSPS sources handled it: clear the animation when the action ends, matching the "stopping it after a few seconds" behavior from the wiki.

The 4 changes are valid and consistent with how Firemaking already handles it at Firemaking.kt:95.

If there are any other issues, we can discuss further :P

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants