Log in

View Full Version : Freezing issues



Cozy
July 6th, 2021, 10:11
In June we had freezing issues while playing. The game froze frequently for about 5 sec every few minutes.
Now we have taken a break in playing over the summer.

The freezing also occurs when I am preparing the game for future play. That is with no one else connected.
For example I write text in a story window and the game freezes in the exact same way for about every 20 words I write down.

I did unload all extensions and the problem is the same. So I updated them all and reenabled them.

I always run Unity and the latest version.
Windows 10.
No other program is locked up when this happens.

Anyone have a clue what it could be?

Zarestia
July 6th, 2021, 13:03
Can you show us a screenshot of the /campaign/<campaignname> folder content or tell us the size of the db.xml of your campaign? Fanatsy Grounds autosaves every 5 minutes and there has been a handful of reports that the saving process freezes the program when working with a very large db.xml.

Otherwise there was one report some months ago that had only freezes while writing large (> 5k words) story entries.

Cozy
July 6th, 2021, 13:08
Here is the campaign folder and the db.xml looks to be 6MB
48077

Zarestia
July 6th, 2021, 13:27
Here is the campaign folder and the db.xml looks to be 6MB
48077

Thanks. If memory serves right, one or two people already had problems with a size of 6 MB. As that looks like LMoP I don't know why that database would be so big. You can zip and upload your campaign here if you want so others can take a look.

See here for how to: https://www.fantasygrounds.com/forums/showthread.php?68475-How-to-zip-up-your-campaign-if-the-Developers-ask-for-it

Cozy
July 6th, 2021, 13:30
LMoP where the first campaing we played with FG, så I named the Campaign after LMoP. Maybe I should have named it "Campaign 1-20 Cozy" or something.
Then we continued with Dungeon of the Mad Mage, and that one is big.

But I have unloaded the LMoP.

Zarestia
July 6th, 2021, 13:37
The actual module (adventure) you load doesn't affect the db.xml at all. Only the data which is explicitly in your campaign is also in the database. My 2-year old Curse of Strahd campaign for example is 2,2 MB in size. My new campaign's db.xml which is now 15 sessions long and got 6 players is 1,09 MB in size. For some reason you got a rather big file.

Cozy
July 6th, 2021, 13:42
I have used other maps with more details for the first 5 levels.
Maybe I should not do the same for the rest of the levels (15 more or so)

Edit: We are 4 players and have played about 30 session (4 hours each).

Trenloe
July 6th, 2021, 14:19
As Zarestia suggests - please ZIP up your campaign and post here so we can see what's causing the large amount of data.

Cozy
July 6th, 2021, 14:39
The actual campaign is 1GB and the rar-file 700MB.
So I should probably not just place it here in the forum.
You can download it from my FTP-server:
https://jfg.se/FG/LMoP.rar

As I now understand, the problem is because I have:
- added large and detailed maps with ocluders
- kept the old maps
- added translated text to some parts (to Swedish)
- added some of my own changes

I guess the best I could do now when we are not playing until December:
- Start a new campaign with the DoTMM
- Just use the included maps
- Transfer over only some important stuff
Instead of starting a new campaign. Is it possible to reset a campaign to the original status?

Is there anything more that I should think about not to do, so the size of the DB does not grow to big?

Trenloe
July 6th, 2021, 15:06
Thanks for attaching the files. A quick look at this, but just opening the db.xml file in Notepad++ and collapsing the XML levels:

Just a quick look at the number of lines within this file that has 117,495 lines of XML:

50,000 for the characters
29,000 for the images
17,000 for MKshops
15,000 for the party sheet.


The above four items account for approximately 111,000 lines - 94% of the total number of lines in the file. Now, this isn't an accurate measure - as some lines may contain much more data than others, but it's a good place to start.

Expanding the above 4 mentions XML levels reveals:

There are 20 PCs in this campaign.
There are 80 images.
There are 18 records in MKshops. I assume this is data stored as a result of entering data through an extension.
Nearly 9,000 of the 15,000 lines in the party sheet are in NMNgm and NMNnpcs - which I again assume is via an extension.


So, there are definitely things to look at here:

Export and delete some of the PC records that aren't being used.
Remove images that aren't being used any more and also see below regarding moving data to modules.
Move data that doesn't change regularly to modules.
Remove other data that isn't needed - be it old FG data or MKshops, NMNgm and NMNnpcs


The main thing is removing large data that you're no longer using, or don't change the data. The second point is where to look at in more details - if you create something (a shop, a map with LoS/lighting on it, etc.) and this won't change much, then put it in a module. Do most of your creation work in a "module development" campaign and then export that data to a module, and load that module up in your campaign. If the module may have a lot of data, then use multiple "module development" campaigns - have one for shops, one for maps of a specific area, another for maps of a different area, etc.. This will reduce the amount of data being saved when you're doing your development work, and also significantly reduce the amount of data saved in game.

Cozy
July 6th, 2021, 15:17
Thanks for explaining it all.
A lot to take in, but I think I understand the most of it.
The rest will clear when I have read it a couple of times.

I will give it a go :p

Before changes DB.XML = 6102kB
Exported some characters: 5323kB
Moved shops to own module: 4567kB
Moved all images to own module (including my larger maps): 2480kB
Save time now: ca 1s

Trenloe
July 6th, 2021, 15:39
I've just done some testing with your campaign loaded up in my FGU. I don't have DotMM, but can load up most things.

If I type /save in the chat window, FG takes about 10 seconds to process the save, during which time it is unresponsive. If I delete the "JFG - Level 3 DotMM" image the save times drops to 2 seconds. So, the majority of the issue here is that one big map. Reducing the other areas will only provide small improvements compared with the big impact of that one map.

Cozy
July 6th, 2021, 17:37
Se post 87 below where I moved som data to modules and deleted som not used data.
I have no idea if moving my higher resolution maps to its own modules is a good idea. But it is a test that works so far.

A nice feature would be to show save time in the chat for the /save command.

Cozy
September 26th, 2021, 16:15
As I wrote in July 2021. I shrinked the DB.XML from 6MB down to 2.5 MB. Still very large but the saving time also shrinked from over 5s down to 1s.
Now I see slow saving times again. It takes about 10-12s to save the game. But the DB.XML is still only 2.5 MB.

Any ideas???

edit:
I searched and found this out.
I was recommended here to place my large maps and stories into a module.
When I have that modul loaded it takes a very long time to save.
If I unload the module it only takes 1-2s to save.

I need to use the maps and my changes story texts. So what should I so?
Should I make one module for each map and load/unload them as I need them?

Moon Wizard
September 26th, 2021, 17:28
Questions:
* How large is the map in pixel dimensions?
* Approximately how many line-of-sight blocker points are on the map?
* How many tokens are currently on the map?
* Does this happen only when players are connected; or even when working without players connected?

Regards,
JPG

Cozy
September 26th, 2021, 21:33
The maps are abput 6MB each and the number of pixels varies, say 3580x5180 (one of the maps)
There are about 25 maps in the modul with many many occluders.
There where only 5 tokens on the map when I tested the save times.
No players where connectet.

Moon Wizard
September 26th, 2021, 22:53
You probably are going to need to simplify the occluders to use less points in order to control the overhead of both LoS and FoW. More LoS points means more data for both the map LoS and per token FoW data. Line-of-sight occluders do not need to be as fine-grained as most people tend to make them; and the extra data incurs overhead.

There's a new feature in the image data panel where you can open the line-of-sight section, select a line-of-sight block and simplify. (Uses a line simplification algorithm)

Otherwise, we'd need to get a copy of the campaign folder and images in order to test and see what is happening.

Regards,
JPG

Cozy
September 27th, 2021, 07:29
Ok, I will try the simplifyer

Thanks