Frequent, disruptive crashes

[Gix]

So as a developer I realize this is a huge vague problem and you need details, but not sure what details would be helpful...

I am hosting a weekly game on an Ultimate version on a Mac.

All my players are on the demo version, all on PCs except for one, (we have 7 total)

Invariably ... every week ... we'll have 1-3 players who have to shut down, quit process, or otherwise restart their game before they are able to:

A) Connect at all: the server says Soandso connecting ... Soandso dropped over and over... (this while others have connected just fine)
B) View a map: I share a map and some players see it and it loads just fine, others get the "Image of Doom" where they get all kinds of loading errors and have to restart the app.
C) Get their game to stop crashing: Sometimes instead of just B, they get the "Superior Image of Doom" The description for that item is: "Once per long rest causes you to no longer be able to connect to the server, or in the odd case that you do, cause the image to crash your game. The only solution to this is to roll a DC 15 Intelligence saving throw, and blow away your game cache"

Lets see, what else...
We're playing D&D 5e and I have all the primary books (though not all adventures) but the content we're running is custom.

I wouldn't know what else would be relevant.

[SirGraystone]

My best guess would be you have too many images/tokens shared, or your map files are too big. We had a game in which the GM FG kept crashing when everyones was logging, to learn that one of the player was trying to use an image for his token that was 1.6 MB.

[Trenloe]

99% of the times this will be caused by the FG instance using too much memory - usually due to too much being shared with the players.

1) FG is a 32-bit application, so it is limited to the memory it can use. You'll start having issues (errors and crashes) above 3GB of memory use.
2) The player side instance loads all resources - shared and open modules. These all take up valuable memory.
3) Tokens - don't share too many tokens with players, and make sure tokens are not large in file size - 500kb or less is a good guide.

So, check what modules you have allowed the players to access. Only give them access to player designated modules. Don't allow access to DM side modules like the MM or DMG or adventure modules. Once you've reduced what the players can access, get the players to clear their cache (Nuke button in the top right of the "join game" screen") before they next join your game.

If you've shared a lot of images, unshare the ones you no longer need.

If you've added custom images/maps check their resolution - the recommendation is to keep maps/images 2048x2048 or below. The more pixels the more memory FG will need.

[Gix]

Hmm... This isn't on load ... at least... the big nasty map causes crash isn't. It does take time to load initially though... and they are all using my tokens which are right-sized

[Trenloe]

the big nasty map causes crash isn't.
What is the resolution of this big nasty map? Also, as a second thing to consider for file sharing time, what is the file size?

[Gix]

99% of the times this will be caused by the FG instance using too much memory - usually due to too much being shared with the players.

1) FG is a 32-bit application, so it is limited to the memory it can use. You'll start having issues (errors and crashes) above 3GB of memory use.
2) The player side instance loads all resources - shared and open modules. These all take up valuable memory.
3) Tokens - don't share too many tokens with players, and make sure tokens are not large in file size - 500kb or less is a good guide.

So, check what modules you have allowed the players to access. Only give them access to player designated modules. Don't allow access to DM side modules like the MM or DMG or adventure modules. Once you've reduced what the players can access, get the players to clear their cache (Nuke button in the top right of the "join game" screen") before they next join your game.

If you've shared a lot of images, unshare the ones you no longer need.

If you've added custom images/maps check their resolution - the recommendation is to keep maps/images 2048x2048 or below. The more pixels the more memory FG will need.

Thank you! That is very detailed and specific. (and appalling, in the case of 32 bit). I'll try that next time.

[Gix]

What is the resolution of this big nasty map? Also, as a second thing to consider for file sharing time, what is the file size?


The map isn't big and nasty, the crash is what is big and nasty :). The map is about 2k x 2k.

[Bidmaron]

You didn’t answer second half of his question. What is size of image file?

[Gix]

You didn’t answer second half of his question. What is size of image file?

Yes, sorry. I can't answer that right now. It's at home... I'm at work... clearly working hard :D

[LordEntrails]

Note, that if a client is on a 32-bit OS (as opposed to a 64-bit OS) the process size limit for them will be around 1.5GB and not the 3GB mentioned before.

[Gix]

I just threw up a little in my mouth.

[Moon Wizard]

The FG application is compiled as large address aware, which means it can access up to 4GB as long as the OS supports. Due to the way short/long term memory management works, this usually means a cap of long-term memory around 3.2-3.4GB. This is where those numbers come from.

Regards,
JPG

[Gix]

So a couple questions.

1. What Language is FG written in?
2. How difficult would it be to recompile 64bit? (Global replaces on variable types being such a safe thing to do and all...) :p
Just thinking that perhaps an effort to 64bit-iffy as an interim to the Unity replacement might resolve a lot of issues for a lot of folks and therefore be worth it.

[Trenloe]

It relies on a lot of legacy code and libraries that are 32-bit only, so I don't think it's possible.

Wait for the Unity version (I know that's easier said than done) - no need to divert development resource to a short term effort, even if it was possible.

[damned]

Additionally the way the current engines memory usage on images is just inefficient. Adding 64bit and allowing people to use 4/6/8+GB of ram will create just as many issues as players would also need similar amounts of memory and not all will have. The Unity rewrite is a complete new engine and has much better graphic support an *should* be a whole lot better at putting all the current content into a much smaller footprint... of course I could be dreaming... time will tell.

[Gix]

Well, I asked because I'm in software myself (not games). It'd be nice if FG was a little more open vest on where exactly they are on the Unity work... As it is now as far as I know it could be years until we see it... I mean equally it could be released tomorrow, but I wouldn't know. (And yes, I get the not promising dates thing) It would be nice to see maybe a checklist of major sub-systems and a progress indicator or something... so we can cheer it on.

[damned]

Well, I asked because I'm in software myself (not games). It'd be nice if FG was a little more open vest on where exactly they are on the Unity work... As it is now as far as I know it could be years until we see it... I mean equally it could be released tomorrow, but I wouldn't know. (And yes, I get the not promising dates thing) It would be nice to see maybe a checklist of major sub-systems and a progress indicator or something... so we can cheer it on.

Many people have asked and expressed similar views and many more will yet.
The project has taken them much longer than they believed it would and still has a way to go hence they dont want to post misinformation.
I believe there is a soft target of completing this year but that is inferred from one of Doug's posts.

[dulux-oz]

Besides, they kept getting distracted with releasing new Rulesets (5E at the time) and various other things that we (the FG Community) end up wanting and/or enjoying immensely :)

[LordEntrails]

If you check out the FG Friday from yesterday (on Twitch, probably on YouTube also) Doug talks for a couple of minutes at the very end about Unity. In short, if I remember correctly, he basically said they just finished the networking portion that they built from the ground up.

Otherwise you can read the thread on FG Unity to see recent info.

[Gix]

I gotta say, despite my frustration with some FG stuff, the community is exceedingly helpful. Thanks again, guys!

[Gix]

You didn’t answer second half of his question. What is size of image file?

File is about 2.7meg. and is 2k x 2k (ish)

[LordEntrails]

File is about 2.7meg. and is 2k x 2k (ish)
Did you figure out why you are having crashes, or is it still an issue?

[Gix]

Did you figure out why you are having crashes, or is it still an issue?

No I haven't figured it out, but we haven't met again yet. We meet Thursdays.

As for Token quantity, it should only matter on the Shared Tokens, right?

[LordEntrails]

So, stability, as mentioned before is almost always due to too much shared. That image should be fine. File size just means it will take longer to share, but won't cause crashes. In your case, it's most likely players trying to load too many books. Make sure you are only sharing player books, and that they are only loading the ones they need. Then watch the processes sizes, if the crash happens around 1.5GB on 32-bit O/S or 3.+ GB on 64-bit O/S, then you know sharing (books, images, tokens) is the cause.

Yes, it is the shared tokens that will cause player problems much sooner than it will cause problems with the host/GM.

[Gix]

So I validated I am only sharing Player materials, and only the Player versions of: PHB, DMG, Volo's,*Xanthar, And Sword Coast. (so they could build whatever class/race they wanted and have access to all the backgrounds)...

[damned]

No I haven't figured it out, but we haven't met again yet. We meet Thursdays.

As for Token quantity, it should only matter on the Shared Tokens, right?

Nope.
Well not totally true - if the player instances are crashing then Shared.
If your instance is crashing its any tokens.

[Gix]

Oh, my instance doesn't crash... it's a random assortment of players. It isn't even consistent who gets the crash.

[damned]

Once you do the cleanup make sure that the affected players clear their cache for that campaign. They will need to also join the session 15mins early so they can redownload everything without slowing your session down.

[Valdemar]

Nope.
Well not totally true - if the player instances are crashing then Shared.
If your instance is crashing its any tokens.

Damned - can you elaborate on this - I am seeing "bad allocation error" and crashing any time I go to ANY other window (even switching between my dm and local host versions of FG (Classic).

[Trenloe]

Damned - can you elaborate on this - I am seeing "bad allocation error" and crashing any time I go to ANY other window (even switching between my dm and local host versions of FG (Classic).
Look at the memory use for FantasyGrounds.exe processes. If you're running a 64-bit operating system, with Fantasy Grounds Classic (not Unity), and either process is using more than 3GB of RAM, then memory use is the issue.