Slow movement of token

[Cozy]

It sometimes happens that the movement of tokens is awfully slow. It might take seconds before the token moves for the DM or any of the players. The problem is the same even if the DM mover the token.
I have tried to unshare and reshare the map, restart FG unity and some other things that I do not recall now, none of those things work. I also have restarted my computer and still the same slow response of the tokens.

But if I remove all tokens from the map and then put them back, then everything works great again. But everyone loses their already discovered areas. That is a quick fix that I we can live with.
But is there any way to not lose the discovered areas? It is a big pain on a big map to select all the tokens and drag them to all visited places.

[Jiminimonka]

It sometimes happens that the movement of tokens is awfully slow. It might take seconds before the token moves for the DM or any of the players. The problem is the same even if the DM mover the token.
I have tried to unshare and reshare the map, restart FG unity and some other things that I do not recall now, none of those things work. I also have restarted my computer and still the same slow response of the tokens.

But if I remove all tokens from the map and then put them back, then everything works great again. But everyone loses their already discovered areas. That is a quick fix that I we can live with.
But is there any way to not lose the discovered areas? It is a big pain on a big map to select all the tokens and drag them to all visited places.

When a token is removed from the map all its visibility is removed.

If you enable Party vision then just drag the one token around that might help, but it's not ideal.

I get slow tokens sometimes, so probably still needs optimising.

[Moon Wizard]

The token accepted movement animation should be moving at approximately 3 grid squares per second right now. If you are seeing something differently, please let us know.

Regards,
JPG

[anubisascends]

I can say that I have had times where the token accepted move is far slower than expected. I have had it where I have accepted the token movement and then it takes several seconds to register the accept. Once that happens, movement is exceptionally slow. Now, there was a movement that was over many squares (once that was 20+ squares) so that may have made it just seem slow. If it happens again, I will document it down more.

Is there a way to change the amount of movement on our end?

[Moon Wizard]

No, there is not. I'm thinking we might need to adjust the speed based on the distance of the overall movement eventually, but that's something longer term.

If you are seeing something other than about 3 squares per second; then please provide a link to a zipped up version of campaign, as well as details of which map/token we should look at.

Thanks,
JPG

[Cozy]

No, there is not. I'm thinking we might need to adjust the speed based on the distance of the overall movement eventually, but that's something longer term.

If you are seeing something other than about 3 squares per second; then please provide a link to a zipped up version of campaign, as well as details of which map/token we should look at.

Thanks,
JPG

Next time it happens, I will try to make a link to a zipped up version of the campaign. But I have no clue how to make a zipped version of the campaign.

[Moon Wizard]

It's just a folder in the GM's FG data directory under the campaigns subfolder. It has the same folder name as the campaign name.

Regards,
JPG

[Cozy]

Ok, thanks

[Cozy]

No, there is not. I'm thinking we might need to adjust the speed based on the distance of the overall movement eventually, but that's something longer term.

If you are seeing something other than about 3 squares per second; then please provide a link to a zipped up version of campaign, as well as details of which map/token we should look at.

Thanks,
JPG

Ok, it happened again. I as a DM tried both with and without the map maximized (the arrow in upper corner). It seems to be even slower when I maximize the map.
If the tokens are not locked, then the movements are fast. With the tokens locked and the DM skip to accept and instead move the tokens, then it also moves them fast for everyone. But if locked and then the movements are accepted by the DM (clicking green tick) it is terribly slow.
The map is named: “JFG – Level 1 DotMM”
The path is to the zipped file:
https://jfg.se/FG/Lost%20Mine%20of%20Phandelver%20-%201.rar

I do not know if the map will be accessible with the above campaign data.
I have the map in the FantasyGrounds/images. This map probably needs to be copied there.

https://jfg.se/FG/JFG.rar

[Zacchaeus]

Even zipped that map you linked is 595Mb. That's colossal; it's going to take me a while to download it and see what resolution it is but I'd say the issue is that the map is just too big.

[Cozy]

Even zipped that map you linked is 595Mb. That's colossal; it's going to take me a while to download it and see what resolution it is but I'd say the issue is that the map is just too big.

Well it might be. But it is not just one map. I zipped all maps in the catalog, maybe not the best idea.
I have not really got the hang of where all maps and other things should be stored.

If I go by the button "images" to the right. The map is called: "JFG - Level 1 DotMM"
If I search for a map with that name in the harddrive it can not be found. (is it compiled into som other file?)
In the big zipped file, that I linked to, is a map named: "level1-72dpi-fullquality.jpg". That is the one that I used to create the "JFG - Level 1 DotMM". I had to add my own line of sight.

Nice maps anyway :)

[Zacchaeus]

Probably not the best idea no. Wherever you obtained the maps from presumably you put them somewhere on your hard drive and if you added them to FGU then they'll be in your campaignname/images folder. If you click on the folder icon at the top left of the FGU start screen this will take you to the FGU Data folder and your campaign will be inside the campaign folder in a folder with your campaign name on it.

[Jiminimonka]

Even zipped that map you linked is 595Mb. That's colossal; it's going to take me a while to download it and see what resolution it is but I'd say the issue is that the map is just too big.

That second zip is more than one map.

[Cozy]

I made a folder in the “Fantasy Grounds/images” and put the map files there. I created these folders in the images: JFG/DotMM/L1 where L1 has the map for level 1 of DotMM.
Then I opened the map image by the following these steps: Assets->Images where I then opened “Data->JFG->DotMM->L1” and dbl-clicked the mapfile.
After that I added the LOS.

As I understand now, I should have copied the map image into the “campaign/my campaign name/images”.
As it is now, the map for level 1 is not in the “campaign/my campaign name/images” but just in the “Fantasy Grounds/images”.

Did you download all the maps? Or should I zip just the particular map?

[Cozy]

That second zip is more than one map.

Yes, it is. Sorry for that. Did not know if a map without the correct path would work.

[Jiminimonka]

I made a folder in the “Fantasy Grounds/images” and put the map files there. I created these folders in the images: JFG/DotMM/L1 where L1 has the map for level 1 of DotMM.
Then I opened the map image by the following these steps: Assets->Images where I then opened “Data->JFG->DotMM->L1” and dbl-clicked the mapfile.
After that I added the LOS.

As I understand now, I should have copied the map image into the “campaign/my campaign name/images”.
As it is now, the map for level 1 is not in the “campaign/my campaign name/images” but just in the “Fantasy Grounds/images”.

Did you download all the maps? Or should I zip just the particular map?

Is it the standard Mad Mage map or a custom one? Because if its the Mad Mage map that is included in the DotMM module for FantasyGrounds.

[Cozy]

Is it the standard Mad Mage map or a custom one? Because if its the Mad Mage map that is included in the DotMM module for FantasyGrounds.

It is a custom made map. It show a lot more as funiture and such in the rooms.

[Zacchaeus]

Indeed. The image isn't in the campaign images folder - so it's never been imported into the campaign. I managed to d/l the campaign but there's no image there just the pins and the LoS. I can't d/l the map file that you zipped - it keeps failing. I think though the problem (or at least one of the problems) is that the image isn't in the campaign/images folder. But yes, if you could upload just that one image it might tell me someth8ing more.

[Cozy]

I suppose you need to place the map at the same path that I have used.
"Fantasy Grounds/images/JFG/DotMM/L1"

This link will take you to a rar with 2 maps. I am not sure which map I used.
https://www.jfg.se/FG/L1.rar

Can I erase the old big map file now?

[Zacchaeus]

Yes you can remove the big file.

I'm only able to test in a limited fashion since the file you provided is not the same name as the file you have used. Renaming it to the same name as you have just gives me a blank map with pins and occluders. Testing on the map you did provide I can't see that the token movement speed is anything other than correct. The map is very big both in terms off size and resolution and with occluders and effects that could give you a bit of lag. Since I'm not seeing your definition of slow it's hard to say whether what I'm seeing is also what you are seeing and you consider that slow. But I can say that the image you have added LoS to isn't in the campaign/images folder so I'm not even sure why it would work at all. I've never tried using a map directly from anywhere other than inside the campaign.

[Cozy]

I suppose that it is not easy to move into the correct folder without loosing the LoS?
I will place them in the correct place in the future.
Thanks for your time.

[Cozy]

I could add that slow for me is when it takes more then 1s per square on the map. Sometimes 3s. But it also works with no problem sometimes.

[Moon Wizard]

It might be related to the number of tokens on the map; and the number of occluders defined. Every piece of information increases the burden on the product. I'm guessing with such a high-resolution map, you are using very detailed LoS with lots of points. We are working on some optimizations as part of our next big pass for vision/lighting; but that also adds more overhead to support the vision/lighting.

You could try turning off the occluders, and see what the performance is like.
Or try resampling to a smaller size image, and testing whether that helps.

A 595MB image will most likely create some challenges with in-memory size, as well as swapping between memory and your graphics card.

Regards,
JPG

[Cozy]

The 595MB Zip file included more then 40 maps. So the actual map is around 12MB.
But I will try to turn off the occluders next time. And the next map will be placed in correct folder.

[Weissrolf]

Age of Ashes 2, Cinderclaw mine map. Lots of tokens visible at once, token movement (of locked tokens) for one of my players became slower and slower (same player that suffers from "black map" issue every week). For him locked tokens arrived 14 seconds after they arrived at my GM session. When I move a token directly it jumps to the destination immediately for the player, so no problem then.

My guess is that LOS calculations during token movement are the the culprit. It seems as if adding more tokens (+CT entries?) makes it worse, but then removing them does not improve it again (or maybe makes it even worse again).

Log files can be provided.

[Moon Wizard]

We're deep into a complete rewrite of those systems; and logs are only useful for outright errors and crashes (not slowdowns). My guess is that it might be either complexity of the map occluders and/or the size of the map displayed.

Just out of curiousity, can you try having that person run without sending the image to the background, if they do that? I'm wondering if that might help as well.

Regards,
JPG

[Weissrolf]

Problem is that he has to keep shoveling windows around inside FGU because he lacks the desktop resolution to display it all. So the map window keeps being covered by other windows and he keeps resizing it to accommodate for the CT and charsheet.

That being said, I find lock/approved token movement too slow on my rather high powered GM PC as well. FPS drop considerably along the way (with some dips below 20 fps). It's just that it is even slower on his machine.

I will stop using approved movement for NPCs, it serves no specific purpose anyway other than me using ALT-movement to measure distance. Until FGU improves on performance I will rather drag the token to its destination once I know the distance. It's more clicks, but also less trouble.

[Moon Wizard]

What is the size of the map you are using in pixel dimensions?

JPG

[Weissrolf]

You give me the password, I give you the resolution. It's a module bought from the SW store. ;)

https://i.imgur.com/diO7Vk1.png

https://www.fantasygrounds.com/store/product.php?id=PZOSMWPZO90146FG

[Amerisun]

Moonwizard / Everyone else, I had the same problem on the Ice Caves Player map for The Rise of Tiamat at Oyaviggaton just this past three weekends. That map made the game horribly slow for everyone to use, they had to click on their character and wait a slow count of 3-5 seconds (one one thousand, two one thousand.. etc.) and then their character would be able to be picked up. I had to do the same, so DM was not immune to the slow down.. I have 6 players and myself in that campaign. Arauthators lair was not as bad.

Sometimes if they didn't count long enough, they would somehow duplicate their character and the duplicate would not be bound to anyone and it would be an orphan token just kind of hanging out that I had to delete. Figured I would add to the information since that's an "out of the box" campaign map that I got by buying / downloading the adventure from FG.

It would lead credence to the number of lines / items that made up that map because of the broken size of the caves had to have a lot of points / lines to make it work.

[Ludd_G]

Hi.

I realise that all the relevant coding around this is probably being overhauled as part of the dynamic lighting upgrade, so please see this more as an extra data point rather than something I would expect to be able to be addressed before the dynamic lighting launch.

This last weekend I found a similar issue when running Sunless Citadel from Tales of the Yawning Portal. There are a couple of rooms with a lot of NPC tokens (Kobold Colony and Goblinville) and I discovered that if the tokens were set to either Always Invisible or Always Visible then DM approved token movement was normal, but if the tokens were set to Mask Sensitive the approved token movement really slowed down dramatically, in proportion to the number of tokens set to Mask Sensitive. I tested with the NPCs both in the Combat Tracker and not and this didn't seem to make a difference. The Goblinville room is 10 squares by 12 square, there are around 28 NPC tokens loaded from the encounter, the LoS is a simple wall around the room, there are no terrain or object occluders within the room, all the tokens are in full view. When I approved a player token to move through the room, then through a door and into a smaller room, as soon as the token entered into the smaller room and was no longer in line of sight of the NPC tokens it's speed returned to normal.

I had to set the NPC tokens to Always Visible (one at a time... I'd love to be able to change the NPCs token visibility state as a function of group select, if that could be made possible?) once the room had been encountered, which, whilst not ideal, was better than the grindingly slow token movement for my players.

I hope this helps in some way.

Cheers,

Simon

[Moon Wizard]

Thanks for all the information.

I have a theory that this is partially related to another issue reported (background panel missing scrolling control). In this case, I believe the background panel is not confining the image control for some reason; which causes the window within the panel to be the full size of the map. Larger map windows cause more lag as more pixels need to be rendered. There's also probably some other performance considerations in general for images; but as I mentioned those are being refactored by Carl already.

If my theory is correct, the workaround is to NOT use the send to background option for images until this is fixed. (which given that the code base is currently gated behind vision/lighting, any fix would be part of the first vision/lighting release.)

Regards,
JPG

[Ludd_G]

Hi Moon,

just in case it helps diagnosing the issue: in my situation the map was always in Windowed mode, and occured whether there was a player connected to the session or not. Previously at least one of my players had been having the missing control issue, but I did my testing later on that day in a re-launched version of the campaign.

Cheers and thanks for all your help, you and the whole team!

Simon

[Weissrolf]

Windowed mode here, too. In fact I just considered asking the player to maximize the window (what is "background mode"? what is "desktop mode"?), because his repeatedly resizing the window causes memory errors as per another thread.

[Moon Wizard]

The floating window that comes up when you open an image (or an image gets shared with you) is the default mode. If you use the "Send to Background" option, this will is "desktop mode", "panel mode", "background mode" or whatever we all want to call it. Apologies for the shifting terminology as some of it is related to under-the-covers implementation logic.

Thank you for the confirmation that this is happening in Windows mode. Is it possible to get the campaign folders zipped up, and the specific images that are being affected? I can then pass on to @cpinder to check against his new code to see if it is improved.

Regards,
JPG

[Weissrolf]

I am still confused about the terminology, there are three modes, which of these is desktop/background mode?

Windows = Default
Maximized between chat and side-panel = ?
Maximized over chat and side-panel = ?

The image/map in question is the same one I posted about in the window stays black thread. It is the "Cinderclaw Mine" from Age of Ashed #2 as bought from the SW store. I cannot send you the map, because the AP zip file is password protected by your shop.

I can send you the campaign folder, of course. Would you need my server version or the affected players' version (do players have a campaign folder to begin with?)?

[Moon Wizard]

In ruleset developer terminology, there are floating windows and panel windows. The panel windows are the ones always stuck to the desktop and always displayed below floating windows (i.e. chat, character list, sidebar, modifier box, dice tower, etc.). The floating windows are every other window that floats over the rest of the desktop, and can be moved at will. The two image background modes are both panel windows; but at different levels in the panel window hierarchy.

Yes, the campaign folder would be useful. I'm not clear on the server version. Are you not running v4.0.10?

Regards,
JPG

[Moon Wizard]

@cpinder took a quick scan of the thread. He believes this is probably related to the number of tokens on the map; and that in particular should be better in next build (faster LoS performance).

For now, you should reduce the number of tokens on the map if possible. I would recommend against using extensions that load multiple encounters onto the map at once.

Regards,
JPG

[Weissrolf]

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?

[Amerisun]

I made a video of what's happening here: https://youtu.be/gEnzvHxLYc8 for me which sounds similar.

You can see when I drag an token sometimes up to 3 seconds and in one case almost a full 4 seconds on the last try. It seemed much worse when players were connected, and at that point they would sometimes create ghosts of themselves.

You can also see at the end of the video, it's barely putting a strain on my system. My GPU is only at it's level when I started recording because the Video Recording Software uses the GPU to process video (which I never run during a normal game).

[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:

https://i.imgur.com/ieCC76w.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/gpugems2/part-ii-shading-lighting-and-shadows/chapter-14-dynamic-ambient-occlusion-and

[Weissrolf]

On a side-note: Noticed how I had to click twice at the beginning? That is because FGU does not seem to register token operations when its window is not in focus before. So you need one click to get in focus and another one to do any token operations. This does not happen when you just try to move the map (or try to move the token and then wonder why you move the map instead).

[kevininrussia]

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.

I think this has to do with FGU not being able to deal with large data chunks. They did a hack to limit how much data is accessed with the "pages" where you have to step through groups of 10 so not to try and load all the data at once and bog the system down. It was really horrible 6 months ago and they did an update that made FGU usable. Still has issues as you describe.