Movement path line does not dissappear on other clients

[Battenhatch]

I'm seeing this behaviour both on the PC client on local network, and on Forge, with and without other modules loaded, with or without a dedicated movement provider module also loaded. It exsisted for me before todays update.

When more than one client is connected, the movent path traced by Drag Ruler dissappears for the client initiating the move when the token is released after the move - but on connected clients, the path stays visible. It can be made to go away by lifting the token again, dragging it outside it's new square/hex, then back to it and releasing it again.

The behaviour can be seen here (audio in danish so visuals only): https://youtu.be/OE40CkxMGXs

[manuelVo]

I'm having difficulties reproducing this in my local install. What game system are you using? Please also check the console (opens with F12) for any error messages or warnings.

[Battenhatch]

The only warning I see is this, but it pops the first time I move a token. It pops on the client doing the movement.

index.mjs:1 PixiJS Deprecation Warning: renderer.plugins.interaction has been deprecated, use renderer.eventsDeprecated since v7.0.0

This warning appears on both Forge and PC client

It occurs with Simple Worldbuilding 0.8.1, which is the latest on Forge, and D&D 5e 2.2.1 on the PC client.

[manuelVo]

I managed to reproduce this. This bug apparently only happens on hex grids.

[manuelVo]

Actually, this happens on square grids as well, but not while a combat is running.

[Battenhatch]

Comfirmed, not on squares while combat is active.

[manuelVo]

I've managed to track this down to what I consider to be a bug in core. The transmission of player rulers has been modified in a way that no longer guarantees that updates to the ruler will be received at the other players clients. The way Drag Ruler is built just happens to trigger this bug every time after a token has stopped moving (unless the movement history is enabled and a combat is active).

I've reported this bug in the Foundryvtt bug tracker: https://github.com/foundryvtt/foundryvtt/issues/9617

For the time being, you can fix this bug by reverting Foundry back to it's old behavior by modifying foundry.js and replacing the line

game.socket.volatile.emit("userActivity", this.id, activityData);

with

game.socket.emit("userActivity", this.id, activityData);

[Avitale34]

Cool I was coming here to report this lol

[manuelVo]

This bug has been fixed upstream and should no longer occur when using Foundry v11.304