FGU locks up when DM moves player around with LOS on in 5e

[deadbug]

Summary: FGU locks up when DM moves player around with LOS on in 5e

Ruleset(s): 5e

New Campaign / FGC Migrated Campaign: Probably FGC migrated? "The Haunt" from DMs Guild.

Extensions/Themes: 5e language fonts, wizards theme

Modules Loaded: The Haunt, SRD beastiary/data/magic items, basic rules DM/player, PHB, FG battle maps, unearthed arcana DM/player, xanthar's DM/player

Operating System / Language Setting: Windows 10 / en-US

Steps to Reproduce:
I just updated FGU about an hour ago; console.log says I'm on FGU v4.0.0 ULTIMATE (2020-04-28)

I'm trying out LOS for the first time, and just drew a bunch of walls/doors over a map from The Haunt.

- Open the map
- Click the padlock icon
- Click the eyeball to turn on LOS
- Drag a character token from the combat tracker onto the map
- Select the token so you can see its LOS POV
- Drag it around the map, into different rooms
- After a minute or two, FGU eventually freezes and never recovers

I can reproduce this consistently.

There's nothing interesting in console.log; just typical startup messages and a couple warnings:

[5/5/2020 11:01:32 PM] [WARNING] Frame hotkeytitlebox contains out-of-range values in Middle.
[5/5/2020 11:01:32 PM] [WARNING] Frame hotkeytitlebox contains out-of-range values in Right.

[pollux]

I haven't experienced this myself, but I've heard reports that using the arrow keys can help with LoS lockups. When moving with the mouse, a ton of realtime LoS computation needs to happen to keep up with semi-random micro-movements in the mouse. When you use the arrow keys, the token jumps in a single discrete hop to the next square and LoS only updates once. I'm told this can reduce overload and increase stability. Might be worth a try as a workaround until performance and stability improve.

[deadbug]

Thanks for the tip, pollux! I'll give it a shot.

[bmos]

I haven't experienced this myself, but I've heard reports that using the arrow keys can help with LoS lockups. When moving with the mouse, a ton of realtime LoS computation needs to happen to keep up with semi-random micro-movements in the mouse. When you use the arrow keys, the token jumps in a single discrete hop to the next square and LoS only updates once. I'm told this can reduce overload and increase stability. Might be worth a try as a workaround until performance and stability improve.

Can confirm, this helps greatly.
It's also great at keeping the players in their squares since it seems to be really tempting to people to position their characters halfway between squares ��

[Moon Wizard]

Can you provide a copy of your campaign folder zipped up for our developer to review as a test case? We have some LoS updates in the pipeline to hopefully speed up LoS performance; but more examples are always good.

Thanks,
JPG

[deadbug]

Can you provide a copy of your campaign folder zipped up for our developer to review as a test case? We have some LoS updates in the pipeline to hopefully speed up LoS performance; but more examples are always good.

Sure! I sent you a link via private message. Let me know if there's anything else I can do, like grabbing some kind of process dump when things freeze.

We lost a good 40 minutes to this issue tonight. I just finished a few hours with seven players, and everyone had to be extremely careful not to move their tokens too quickly or risk freezing their clients. I froze my server at one point when I tried to drag a token from the first floor of the map to the second floor (on the same image); the only safe way to move tokens across the full map was to delete them then re-add from the combat tracker.

A lot of my players, especially on macbooks, complained that their clients were maxing out their machines and heating them up, and making the UI stop-and-start enough that they couldn't reliably drop attack dice onto targets.

But, once we learned how to tiptoe around things, the game went great

[Moon Wizard]

Thanks, I've added to our dev tracker for the LoS freeze. The Mac running at high speed issue we're looking at separately.

Regards,
JPG

[pindercarl]

Sure! I sent you a link via private message. Let me know if there's anything else I can do, like grabbing some kind of process dump when things freeze.

We lost a good 40 minutes to this issue tonight. I just finished a few hours with seven players, and everyone had to be extremely careful not to move their tokens too quickly or risk freezing their clients. I froze my server at one point when I tried to drag a token from the first floor of the map to the second floor (on the same image); the only safe way to move tokens across the full map was to delete them then re-add from the combat tracker.

A lot of my players, especially on macbooks, complained that their clients were maxing out their machines and heating them up, and making the UI stop-and-start enough that they couldn't reliably drop attack dice onto targets.

But, once we learned how to tiptoe around things, the game went great

As the GM, you can SHIFT-Drag to move a token without updating LOS.

[deadbug]

As the GM, you can SHIFT-Drag to move a token without updating LOS.

Oh that is a great tip; thanks pindercarl!

[webdove]

I repeated deadbug's description at the top and my client hung in update without ever touching a key or clicking. The host froze as well.
(5E dragonheist/tower-first map, win10 latest, FGU latest).

It is interesting, we played a week ago and never saw a freeze, last night in 5 hours several clients froze and had to restart I had to restart also.
At that point I disabled LOS to use mask mode instead and found that is a LOT more awkward in unity than classic due to the lack of mask controls on the secondary image banner.

I wonder if some move queue buffer is overflowing when the individual graphic updates are queuing to quickly for some slow client to handle. I presume the game tries to keep all the views in sync.