Slow movement of token

[LordEntrails]

I meant "server version" (aka folder on server PC) of the campaign folder, not program version. Do players have a campaign folder and do you need that one, too?

Players have a cache folder for each campaign. No support does not need this as it is re-created when a client logs in.

[Moon Wizard]

@Amerisun,

cpinder looked at the video. He thinks it is related to the changing selection on the tokens forcing a full visibility check between all tokens to all other tokens. This is specifically improved in the vision/lighting work we are doing.

Regards,
JPG

[Xorn]

Here's another example of slow moving tokens:

https://www.twitch.tv/videos/925390976?t=02h37m07s

I linked the whole session but the link starts at a great example of it. I thought it was because I have the share party view set on all 5 PCs for the stream. (I stream a player client with no PC chosen, so the only way the LOS works is if I have shared party view set on at least one PC.) The map is 1.31 MB

[Moon Wizard]

I'm going to go ahead and guess what @cpinder will say, that this is again related to the number of tokens. I see at least 25 on the map here, which I'm sure is impacting. I'll forward it on, so he has another example.

Regards,
JPG

[Xorn]

yeah it was admittedly a very large encounter. :P

[Weissrolf]

And here is the reason why locked token movement approval makes client tokens crawl and the respective FGU client overload the CPU. I am flabbergasted that this has not been noticed by SW earlier. Or maybe it just wasn't communicated in the light of LoS overhaul just shortly after the official "FGU is ready" release.

LoS for every single pixel of token movement is calculated on the client PC (but not on the GM PC).

This is an animated GIF:



If you watch long enough you will also see that token movement by the GM is completely ignored by the client for as long as the formerly approved movement is still underway. As a result tokens can end up in different grid fields on GM and player side.

Please properly analyze these kind of bug reports instead of "guessing" what might or might not be the problem. This could have been caught within minutes with a simple local server vs. client token movement test. This also explains why some of my players' PCs were struggling so hard with CPU overload during game-play and why our last session went so much smoother when I manually moved tokens.

[kevininrussia]

And here is the reason why locked token movement approval makes client tokens crawl and the respective FGU client overload the CPU. I am flabbergasted that this has not been noticed by SW earlier. Or maybe it just wasn't communicated in the light of LoS overhaul just shortly after the official "FGU is ready" release.

LoS for every single pixel of token movement is calculated on the client PC (but not on the GM PC).

If you watch long enough you will also see that token movement by the GM is completely ignored by the client for as long as the formerly approved movement is still underway. As a result tokens can end up in different grid fields on GM and player side.

Please properly analyze these kind of bug reports instead of "guessing" what might or might not be the problem. This could have been caught within minutes with a simple local server vs. client token movement test. This also explains why some of my players' PCs were struggling so hard with CPU overload during game-play and why our last session went so much smoother when I manually moved tokens.

I'm seeing same issue. 4E Ruleset

[Cozy]

Weissrolf:
What program did you use to record the video clips?

I made an attempt with about 50 NPC and a fairly large map. That made one of my players computer go to the blues screen of death.
Did the same with a very simple map of the same dungeon and that was also verry slow.
Made a final attempt without the LOS and unlocked movement of the player tokens. I manually unblocked what the player tokens should see. That had no slowness at all.

[Weissrolf]

I used: https://www.screentogif.com/

[Weissrolf]

And to mention it: This is a CPU load problem, not a GPU load problem. On the contrary, GPU load and fps decrease while FGU is busy calculating LoS via CPU.

I do wonder, though, if GPU accelerated calculations wouldn't be a much better to begin with. Isn't dynamic occlusion and light something that GPUs excel at, even when calculating much more complex sceneries than what we have in FGU? Shouldn't that be what the whole 3D engine part was about?

https://developer.nvidia.com/gpugems...-occlusion-and