Bad allocation, maps not going to players and crashing when opening modules

[Beltaur]

I gm the session and also use a player client for DM players (not npc's) (I only have 1 player playing D&D at this time)

The issue is when sharing a map (map size is small about 1m). My player client will not open said map without a load of bad allocations.
So I nuked the cache and went to open the module we use (players handbook & 1 for homebrew which is open for all players (just the 2 of us)). I then received a whole lot of run time errors when trying to open the players handbook and now whenever I open the player client version it crashes always.

Restart comp, still did it.
Cleared cache still did it.
Shut down comp and it still did it.

We did this setup for months with no problems. Ever since the last sword coast adventure guide update this has been going on. (yes I did redownload all my modules when steam intergrated with the store. Since nothing but problems. It seems like there is a memory leak or something because the longer fantasy grounds is running the more problems.

I mean no offense in how this is worded, it is just getting frustrating not being able to play without all these problems.

Old Wise ones you are our last hopes!

[Nickademus]

1. Can you post the error messages?
2. Have the player nuke his/her cache as when
3. Check your Windows permissions for the location that FG stores stuff.

This is a start.

[Moon Wizard]

Bad allocations are usually caused by FG running out of available memory. The player client is not as efficient at handling modules, so you need to make sure that you are only sharing the PHB with the player clients in the Library->Modules window. If you're sharing the GM modules(DMG, MM, adventures) as well, they are too large to be shared all at once, and not needed. Players can then review the entire book/module which is not recommended anyway.

Instead, you can share any record window individually by right clicking on the window and selecting Share Sheet option.

Regards,
JPG

[Beltaur]

The error message was bad allocation image not loading or something along those lines.
We did nuke all caches.
My resident comp export checked permissions and all is well.

I did just try an experiment, I delete all the maps from our campaign and now I have no problem. We have one large map and that being the Sword coast map. I was wonder if it would be better to make a module for all the maps of the sword coast that I make for each location and save them in a module that we pull into the campaign instead of saving them into the campaign like we do?

I only have the PHB as shared and a homebrew class module and that is all.

[LordEntrails]

Images (including maps) should normally not be larger than 2048x2048 in pixel size). I don't know the maps you are using, but it is easy to find large maps online and want to share those with your players through FG. Don't forget if you find a map online or have your own, you can always just give your players a link to the URL so you don't have to share it via FG.

[Beltaur]

So far so good. I deleted all images from my campaign and had player log in and my player client on my machine, no problems. We logged out and then we recompiled and shrunk our images by a bunch, only 1 being 1 meg but that is the sword coast map and that was shrunk about as far as we could tolerate. We relinked all maps to the stories of each place and then reshared all image that were pre-travelled to and so far so good.

Just want to know Lordentrails that when you say pixel size, if you mean when we make our map from cc3+ to jpg if the 2048x2048 refers to the height and width of the saved map. We then take the map into gimp and exported with between 5-10% quality? Is this correct?

[Zacchaeus]

The 2048 does indeed refer to the height and width in pixels. I usually export out of CC3 as png files and then open them in photoshop (or GIMP) and export as jpeg at medium quality (about 50%). You might haven't go lower if your maps are big. Try to keep the image to under 1Mb but that isn't vital if you don't share too many.

[Andraax]

open them in photoshop (or GIMP) and export as jpeg at medium quality (about 50%).

Also, use "chroma quartered" (advanced options, subsampling) on your jpeg out of GIMP.

[Trenloe]

Side note - pixel resolution of images effect the memory use of FG, which is a 32-bit application and has finite memory limits, even if the computer has lots of free memory. Bad allocation errors can be caused by lots of maps and/or a few large maps. Hence the 2048x2048 image pixel resolution recommendation.

File size only effects share time to players, it does not effect memory use. Below 1MB is the recommendation for file size as this results in a reasonable share time to multiple players, higher file sizes result in much longer share times and delays in game. "Is it there yet?" ;-)

[Beltaur]

I want to thank all the excellent people who answered my question. I did research the subject before posting but it wasn't helping my problem. You guys did help and it is deeply appreciated. This community rocks.

[Beltaur]

Well we went to play some D&D again today and I keep getting this error message after wiping the cache and just trying to open the players handbook in the module activation window.

Runtime Error: Exception: bad allocation

Runtime Error: Exception: bad allocation

Runtime Error: Unable to save file (images/Cover.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Exception: bad allocation

Runtime Error: Unable to save file (images/Cover.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Exception: bad allocation

Runtime Error: Unable to save file (images/Cover.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Exception: bad allocation

Runtime Error: Unable to save file (images/Cover.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Exception: bad allocation

Runtime Error: Unable to save file (images/Cover.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Exception: bad allocation

Runtime Error: Unable to save file (images/Cover.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Exception: bad allocation

Runtime Error: Unable to save file (images/Cover.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Exception: bad allocation

Runtime Error: Unable to save file (images/Cover.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.

Runtime Error: Unable to save file (images/Gnome.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Unable to save file (images/GnomeStuff.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Unable to save file (images/Tiefling.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Unable to save file (images/Half-Elf.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Unable to save file (images/Half-Orc.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Unable to save file (images/DragonbornSkull.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Unable to save file (images/BarbStuff.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Unable to save file (images/ClericStuff.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Unable to save file (images/Druid.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.

Note that we made all images below 1 meg. cleared cache on all machines even deleted the campaign in the cache directory. These are only a few of the error messages.

[LordEntrails]

Are these errors showing a the DM or player console?

"Unable to save file " almost always means you don't have access permissions on the FG Data folder set correctly. From the FG launch screen, click the folder icon in the top right, this will open your FG Data folder, then you can check permissions on it.

The other possibility is that the person getting these errors is out of disk space. Can you check that?

[Beltaur]

These errors were on my player client, but my other person playing on his machine is getting similar errors when opening the players handbook on the module activation screen for both normal player separate machine and also my player client version.

[Trenloe]

The "Unable to save file" error message is caused by the client running out of memory - the Bad Allocation exception is the base cause here. This isn't being caused by folder permissions.

Run Windows task manager when you have Fantasy Grounds open and look at how much memory FantasyGrounds.exe is using. If you're running a 32-bit operating system, you'll start to get issues at around 1.7GB of memory use. If you're running a 64-bit operating systems the issues will start to occur around 3.3-3.5GB of memory use.

Check to see how much memory is being used when you start to encounter these issues.

[Nickademus]

Are you or the player running in test mode? This sounds related to the recent change to read-only images from modules in the test version.

[Beltaur]

no we are running under live mode.

[Trenloe]

99% of bad allocation errors are memory related. Please see post #14 for the next steps to check this out.

Also, recently discussed in the last two posts here: https://www.fantasygrounds.com/forums/showthread.php?39176-End-User-Error.

[Beltaur]

I read the other posts and from what I'm getting Fantasy grounds needs to put its data in a default location (am I correct). What if I told it to save in a different area and made sure permissions were for all who connect that should do the same thing? As for running out of memory when bad allocations show up, what does it tell you if it shows up 2 seconds after starting Fantasy grounds from the player client? Also it only happens when the player wants to access the Players Handbook!


(other modules open fine for the player (homebrewed and UA) it is always happening with the Players Handbook. Should players be able to access it?)

[Trenloe]

@Baltaur - please do as I mention in post #14. Run Windows task manager before you start FG and monitor the memory use.

If you're getting these errors with FG not using much memory then we can look elsewhere. But as 99% of these issues are caused by memory use you're potentially wasting your time looking at other possible issues until you've confirmed/eliminated memory use as the cause. It's a simple check, so please give it a go. Thanks.

[KlatuB]

I'm Beltaur's player, the below screenshot is of the open modules and at the time current memory used. When I open the Players Handbook, I started getting similar errors to the ones in post #11.

https://www.fantasygrounds.com/forums/images/attach/png.gif

[Beltaur]

with task manager open and just starting the GM version my memory 54.8m before starting campaign. Now I started my campaign up and it says 736.1 mb. This is without any players. Then I started a player client which has pushed the GM version to 1,417.3 mb and the player version to 1,500 mb and climbing (this being without opening any modules (as I nuked it before starting) so also no maps)

[Trenloe]

I'm Beltaur's player, the below screenshot is of the open modules and at the time current memory used. When I open the Players Handbook, I started getting similar errors to the ones in post #11.

https://www.fantasygrounds.com/forums/images/attach/png.gif
Yep, memory use is the issue - you're using 3.2GB of memory before opening the PHB. The PHB is known to take 600MB+ (I've just done a quick test on my PC and memory use jumps by 800MB when opening the PHB).

So, this is definitely the issue.

I'd recommend the following steps to check where the big memory use outside of the PHB is:
1) On the player side, close all modules in the Data Module Activation screen.
2) Close FG and then restart, on the "Join Game" screen, click the Nuke button in the top right corner to clear the cache. This will ensure nothing from previous use will load.
3) Open Windows Task Manager.
4) Join your GM's session. Once FG has loaded and you've selected your character check how much memory FantasyGrounds.exe is using. This is the first step to see if the base campaign has too much data shared, or if it's the data modules.
5) You can then open the PHB - how much memory is used?
6) If it's still OK (well below 3GB) then open the other modules you really need, one-by-one and see what you can have open with the memory well below 3GB - because more memory will be used when you open maps, etc..

[LordEntrails]

As usual, Trenloe has got you :)
I'm betting (a free web browser cookie) that you have too many shared tokens. But follow Trenloe's direction and he'll help you figure out just what the issue is.

[KlatuB]

Without opening any characters or modules I'm at 3.1GB.

[Trenloe]

Without opening any characters or modules I'm at 3.1GB.
So you closed the PHB and all of the other 6 modules you had open - as shown in your screenshot in post #20? Then exited and cleared the cache before re-joining? If so, then the base campaign data being shared with you is causing the issue. The main culprits are lots of images and/or tokens (as Lord Entrails mentioned).

@Beltaur a few questions:
1) What is the number and total size of tokens in <FG app data>\tokens\shared?
2) Go to your "Maps" list in the campaign sidebar, make sure the "Group" at the top shows "(All)" and click the "All" button so that it changes to "Shared" - expand the window to show all of the entries and post that here please. It won't be a spoiler for the players, this is the list of all images the players can already access when they are playing in your campaign.

[KlatuB]

As a test Beltaur removed all the tokens and with all the available modules open I'm sitting at (3.3GB). Beltaur was wondering if running the player client on the GM computer is a good idea.

Also any word on when the Unity version of FG will be ready.

[Trenloe]

Beltaur was wondering if running the player client on the GM computer is a good idea.
That won't effect the memory use of the player instances of FG connecting remotely.


Also any word on when the Unity version of FG will be ready.
There's no release date been announced.

[Trenloe]

...and with all the available modules open I'm sitting at (3.3GB).
Close all of the modules. Exit FG, restart FG and clear the cache (Nuke button in the top right of the "Join Game" screen). Then join the game, and don't open any modules. How much memory is your player instance of FG using?

[KlatuB]

Below is a list of the shared maps. The size of the shared tokens folder before Beltaur removed them was 186MB

https://www.fantasygrounds.com/forums/images/attach/png.gif

[KlatuB]

With no character(s) selected, no modules activated and no tokens I'm sitting at 2.4GB

[Trenloe]

Below is a list of the shared maps. The size of the shared tokens folder before Beltaur removed them was 186MB

19924
I'm not familiar with these maps. What is the image resolution (width x height in pixels) of each of these maps?

[KlatuB]

Below are the sizes of the maps in the images (not all shared at the moment)

https://www.fantasygrounds.com/forums/attachment.php?attachmentid=19925&stc=1&d=1500860269

[Trenloe]

Below are the sizes of the maps in the images (not all shared at the moment)

https://www.fantasygrounds.com/forums/attachment.php?attachmentid=19925&stc=1&d=1500860269
Thanks for the detailed info.

The image resolution is the issue here. The recommendation for all Fantasy Grounds images/maps is to keep to a maximum of 2048x2048 if at all possible - as mentioned by LordEntrails in post #5 of this very thread. It's OK to have one-or-two a little over this (e.g. 4000x4000 or less for a couple), but no more.

There are currently 9 images/maps that are shared with the players that are on average 6000 pixels wide, and on average 5000 pixels high. These are way too much for FG's current 32-bit architecture to handle - and is what is causing the issues you are seeing.

I'm sorry, but you'll need to reduce the image size for all of these to keep them within the 2048 x 2048 recommendation. If that causes too much degradation in the image (if you get below 30 pixels per 5' foot square it gets pretty bad, the average for most FG maps is 50 pixels per 5' square - also keeping within 2048 x 2048) then split the maps up into sub-maps - you can use a very scaled down map of the whole area with links to the higher detail sub-maps to make map navigation easier.

[KlatuB]

11 of the maps are exports from CC3+, I exported the at high res so that when they were scaled down we wouldn't lose a lot of quality, thinking the file size was the issue. I can export the maps at a lower res and see what happens

Would putting the maps in a module help with the memory issue.
Would it be better if we only share maps as needed then unshare when done.
Would it be better to use the "DOE: Extensions" extension to link to the CC3+ maps (non combat maps)

[Trenloe]

I can export the maps at a lower res and see what happens
Yep, that's a good plan.


Would putting the maps in a module help with the memory issue.
Would it be better if we only share maps as needed then unshare when done.
Would it be better to use the "DOE: Extensions" extension to link to the CC3+ maps (non combat maps)
Answers in order for the above three questions:
1) No - images will use the same memory within FG.
2) That would reduce it a little bit - but as mentioned above, you can have a couple (one or two) maps above 2048 x 2048 (but still much smaller than the ones you have now). I'm sure at some point you'll forget to unshare the other maps, or maybe decide to push it a bit and see if FG can cope - then your gaming will be impacted when you start encountering issues.
3) Yeah, you could do that to link to a map on the web for the players to load up. You can also just put a web link into the chat window for the players to click on. You don't need the DOE extension for that.

In the end, the 2048 x 2048 recommendation is there for a reason. You will get a much smoother, faster Fantasy Grounds experience for the sake of reducing your maps to this size or smaller. Sure, it's lovely to have huge resolution maps for everything, but you don't *need* them - especially when they cause issues and impact your gaming.

[Beltaur]

We both figured that the module thing would use the same memory.
We both sit in the same room playing D&D and use Fantasy Grounds for combat, so can you do a link in chat window to a file on your computer or give him a link from my computer to use. We are hooked up wirelessly through the modem.

We use fantasy grounds to manage our campaign, we really don't need to use it for our version of the sword coast (we could use the one that comes with the sword coast module) which saves some of the memory. We have shrunken our maps they look blah but it is what it is.

On a different subject how come the sword coast map in the sword coast module is not a memory hog when it is better quality than ours?

[Trenloe]

so can you do a link in chat window to a file on your computer or give him a link from my computer to use.
You can use a URL that will open a browser with the data in the URL. If you both have all of the image files on your local hard drive you can use a file:// URL. For example: file:///D:/Images/SwordCoast.jpg

If you put that in a chat bubble in a story entry, you can have a bunch of links and just click the speech bubble to add them to the chat window, then click on the link in the chat window.


On a different subject how come the sword coast map in the sword coast module is not a memory hog when it is better quality than ours?
I'm not sure what the actual resolution of that map is (it looks about 6000 x 3000 = 18,000 pixels), it certainly looks smaller than 6000 x 5000 (30,000 pixels) which is the average of your image files. And, as I mentioned above, it's OK having one or two of these images only (if they're around 4000 x 4000 = 16,000 pixels) - not 9 or 10 that are around 30,000 pixels.