Loading a Fantasy Ground Campaign - two times waiting

[Snippels]

Hi Everyone,

I've an annoying problem with Fantasy Grounds. When I load my (GM) campaign, the loading image appears and it takes half a minute or so. This is totally fine and nice. Then the chat window appears, the dice are in the lower right corner and on the right hand side I've all the icons.

Everything looks smooth. Now, I'd actually like to use Fantasy Grounds productively.

However, once I click into the FG window, usually on a "Story" or "Images" button, then the Fantasy Grounds window gets a little bit larger, the taskbar dissapears for another 20-30 seconds, Fantasy Grounds is not reacting and I am asked if I want to end the process. Then I wait (cause I don't want to end the process).

Suddenly the message disappears, the FG window get's smaller again (meanging fullscreen and the windows taskbar is back) and now I can use Fantasy Grounds.

It's hard for me to explain, but it really annoys me.

Any idea how I could resolve this?

Many thanks,
Roland

PS: Sorry for bad English, non-native guy here.
PPS: I believe I've no driver issues. I update my nvidia drivers regularly.

[Zacchaeus]

Firstly does this happen only in this campaign? Have you tried in a new campaign without any extensions loaded? If so does the problem go away?

If it happens only in the one campaign then it may be an extension that is causing the issue. Disable all of them (including themes and decals) and then re-enable them one at a time until you find the culprit.

If that isn't the problem then you may be running out of memory. If, whilst the campaign is running, FG is using 3Gb or more of memory then you have too much loaded. Unload unneeded modules and especially token modules.

Also check that you are not using massive image files. Images should be .jpg files and should be limited to around 2048x2048 and < 1Mb in size. Don't use .png files for images.

[Snippels]

I just created a new empty project, and here I've the same behavior.

In the attached screenshot, you see how my system looks after loading the campaign for another half a minute:

27703

Edit: The empty campaign eats already 2gigs of memory. I've got 16 GB of ram.
Is there 64 bit client somewhere?

[Snippels]

I guess I found it:

Suppose it's my 600mb tokens library. However, I don't wanna miss it. Any ideas how I could resolve this issue?

[Zacchaeus]

Yes, that'll do it.

Create modules for your tokens. Here's a video showing you how https://www.fantasygrounds.com/forums/showthread.php?43011-How-to-make-a-Token-Module&p=382389#post382389

Remember that you don't need to have tokens modules open once a token has been allocated.

[Snippels]

Remember that you don't need to have tokens modules open once a token has been allocated.

Thank you for answer.

I also love to use the FGData\tokens\host directory to work with my tokens. If I allocated a token from this directory, is it also saved within my campaign? (meaning, that I could move out folders of this directory later when running the campaign)

[Zacchaeus]

Tokens placed in the tokens/host folder are loaded into every single campaign that you start in FG. They are always available and always use up huge amounts of memory.

Tokens stored in a module are also available in any campaign that you open the module in. The benefit is that once you allocate a token to an NPC or PC then you can close that module again and FG will remember the token. If you export the NPC into a module the token link will also go with it and when you open the NPC in another campaign the token will be there.

[Snippels]

Thanks Zacchaeus for your competent answers.

To sum it up: in order to resolve my memory issues, I will organize my tokens now in modules instead of using the tokens/host folder. When creating campaigns, I load my modules with the tokens (which eats up some memory but it's ok). Then, before playing the campaign, I make sure my token modules are unloaded. This is fine, because all allocated tokens where copied to my campaign before (or are linked accordingly, idk but it should work).

[Zacchaeus]

You will have to relink your tokens if you move them; but you need to do so otherwise you will continue to have issues.

[Bidmaron]

Anyone know if this problem is fixed in FGU?

[Zacchaeus]

Anyone know if this problem is fixed in FGU?
Which problem? The memory limits of a 32 bit application? If so, yes, since Unity is 64 bit.

[Bidmaron]

Give me some credit, Zach. The load time problem, of course. Guess I should have been more proscriptive

[Zacchaeus]

Give me some credit, Zach. The load time problem, of course. Guess I should have been more proscriptive
I did wonder if that really was the question :)

I seem to remember Moon Wizard saying that load times would not change that much. Something to do with XML nodes or some such. I don’t know the technical details.

[Mortar]

Pretty sure the way it works in the XML that a node gets loaded, then all child nodes get loaded before moving onto the next. Every ability, stat, attack, action, trait, drawbacks, and piece of gear just adds more nodes to load. All of them individually which is why Celestian was experimenting with the json objects for the CT.

[The Canterbury Tail]

Pretty sure the way it works in the XML that a node gets loaded, then all child nodes get loaded before moving onto the next. Every ability, stat, attack, action, trait, drawbacks, and piece of gear just adds more nodes to load. All of them individually which is why Celestian was experimenting with the json objects for the CT.

Yeah XML is notoriously inefficient. Very simple structure and extremely easy to work with, but inefficient once it gets large. Most industries have moved to JSON as mentioned above for internal data transmission.

[Bidmaron]

This is a library implementation problem. There is no inherent inefficiency with XML (well, anymore than any text-based database is storage inefficient). I am no fan of Microsoft, but if you use their actual .NET libraries, you don't have to import an entire XML tree at a time, you can control exactly what gets loaded.

If FGU ever recognizes its potential as a campaign data manager, SW will have to adopt a better library for XML. Intelligent, on-demand node loading is non-trivial, however, and will require a significant effort beyond just switching to a different XML library. Multi-threading in the background will be a part of this solution, and it appears that SW has, for the time-being, decided to keep FGU single-threaded. This is a great solution in the short-term for a small development team coming from an inherently single-threaded platform, but they will eventually have to revisit this decision if they ever decide to make FG a more capable campaign manager (just go look at how RealmWorks is struggling with scaling issues associated with large campaign databases). This will be FG Beyond Ulimate because it is likely that the reason for their single-thread decision is because many of the libraries they are using are not compatible with multi-threading.

[Thete]

This is a library implementation problem. There is no inherent inefficiency with XML (well, anymore than any text-based database is storage inefficient). I am no fan of Microsoft, but if you use their actual .NET libraries, you don't have to import an entire XML tree at a time, you can control exactly what gets loaded.

If FGU ever recognizes its potential as a campaign data manager, SW will have to adopt a better library for XML. Intelligent, on-demand node loading is non-trivial, however, and will require a significant effort beyond just switching to a different XML library. Multi-threading in the background will be a part of this solution, and it appears that SW has, for the time-being, decided to keep FGU single-threaded. This is a great solution in the short-term for a small development team coming from an inherently single-threaded platform, but they will eventually have to revisit this decision if they ever decide to make FG a more capable campaign manager (just go look at how RealmWorks is struggling with scaling issues associated with large campaign databases). This will be FG Beyond Ulimate because it is likely that the reason for their single-thread decision is because many of the libraries they are using are not compatible with multi-threading.

Thats really interesting. I guess the solution for world building in the current software is to create a series of modules for a larger campaign or world and open/close them as the game progresses?

[LordEntrails]

Thats really interesting. I guess the solution for world building in the current software is to create a series of modules for a larger campaign or world and open/close them as the game progresses?
It depends upon how large your world database is. I mean if your world database is for all accumulated knowledge of mankind on the planet earth, well then no database, and certainly not a flat xml one, is going to be something you are going to want to use *G*

But, if your world database is equivalent to something like a typical RPG setting book, a single FG module is fine.

To me, it's more about organizing the data lists. How many objects and pages of stuff do you want? How many groups do you want in the group list? Separate modules is just one more way to divvy it up and control not just how much gets loaded, but how big the lists etc are.