PDA

View Full Version : Runtime errors from images



osarusan
April 26th, 2017, 06:48
A number of my players have been getting runtime errors recently, in regards to image files.

At first I noticed that they were getting them from jpegs that I had added to the images library, so I unshared those files and the errors stopped.
However, now I've noticed that players are getting errors from images in official modules as well.

For example, just testing it out now, a player tried to open the Volo's Guide to Monsters Players module and got a bunch of runtime errors:


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/Volo.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Unable to save file (images/Beholder Lair Embed.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Unable to save file (images/Chapter1-1.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Unable to save file (images/Giant-Magic.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Unable to save file (images/Giant-Rock.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/Hag-Lair-Players.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Unable to save file (images/Chapter 1-2.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Unable to save file (images/Beholder.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Unable to save file (images/Cloud-Giant-City.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Unable to save file (images/Beholder-2.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.
Runtime Error: Unable to save file (images/Fire-Giant-Forge.jpg) to cache. Please restart Fantasy Grounds and reset cache on launch screen before rejoining game.

It seems that my players are getting errors like these at random whenever they try to open modules. The modules are properly shared (green checkmark) and opened by me (the DM).
Is there anything else that could be causing this? And is there a fix?

damned
April 26th, 2017, 07:10
On your computer check your FG Data Folder permissions and re-apply them to all subfolders as a precaution.
In chat window type /flushdb
This will unshare all the stuff you have shared....
Have one player clear her cache and reconnect and then reshare a couple of images.
The first connection might take some time...
Have them also check access to shared modules (typically only the PHB).
If that works have all the players nuke that cache and relogin at least 30mins early on the next session.

Trenloe
April 26th, 2017, 15:43
I think the issue here is that you've shared modules that are primarily for the GM and this is overloading the player side as it accesses everything when the player opens a module. This causes FG to run out of memory resources and do all sorts of strange things - the "Runtime Error: Exception: bad allocation" error is usually a sign of running out of application memory.

Don't share GM modules with players. Share individual entries with the players as needed. Only give access to things like the PHB, SCAG and similar.

Go into your module activate screen and put red X's against the GM modules you've shared. The players will then need to clear their cache - click the nuke button in the top right of the "Join Game" screen to remove all of the previous cached data from the shared modules.

osarusan
April 28th, 2017, 00:27
I haven't shared GM modules though... just the player ones (PHB deluxe, SCAG players guide, and so on). The DM ones are all blocked.

I'll try the /flushdb command and see if that helps this week.
We have kind of figured out that going slowly (one at a time) helps alleviate the issue somewhat, but people still end up getting the errors.

When this happens, does this problem cause further instability in the game? Is it better if the players relog/clear the cache every time they get a runtime error? Or is it ok to just ignore them?

Trenloe
April 28th, 2017, 00:46
I haven't shared GM modules though... just the player ones (PHB deluxe, SCAG players guide, and so on). The DM ones are all blocked.
Hhhmmm, all of those image names in the errors in post #1 aren't from player modules, they're from Volo's Guide to Monsters. And you said that you were getting errors like these when players opened modules - so I guessed that you had at least Volo's guide to Monsters shared. If you have, then it needs to be unshared and the players need to clear their cache.

Don't ignore any type of errors, unless you know specifically what they are. Runtime Error: Exception: bad allocation is symptomatic of running out of memory. So you'll need to clear some things out (unshare modules, unshare individual images no longer needed, etc.) and the players will have to clear their cache to reset the data in this instance.

If you get runtime errors that are to do with scripts (they'll have a .lua filename in them) or XML files/controls, then these are to do with the code and don't require players to clear their cache - the GM should check that they are running compatible extensions and have the most up-to-date "live" rulesets downloaded.

Nickademus
April 28th, 2017, 00:56
You would think, with as many people post here about crashing issues, that Smiteworks would change the Module Activation process to block the sharing of modules that are GM only. (They would have to be classified as such, but that isn't hard.)

Bidmaron
April 28th, 2017, 03:59
Just like it would be nice for the launch screen to put a red warning when you are using an unpacked extension or unpacked ruleset, as that is another frequent problem.

I really think the issue is that FGU is so close no one wants to do much but work on game improvements (at least that is what I choose to hope!)

damned
April 28th, 2017, 04:19
Just like it would be nice for the launch screen to put a red warning when you are using an unpacked extension or unpacked ruleset, as that is another frequent problem.

I really think the issue is that FGU is so close no one wants to do much but work on game improvements (at least that is what I choose to hope!)

This statement is very strange to me.
FG is continuously being updated.
Almost all the code that JPG writes goes into both platforms.
There have been significant updates to the current FG experience while the FGU project has been underway.

Trenloe
April 28th, 2017, 14:01
This statement is very strange to me.
FG is continuously being updated.
Yeah, strange statement.

Bidmaron
April 29th, 2017, 02:40
We agree, damned. I was just pointing out like Nickademus a feature that would cut down on the help requests here and observing that no one probably wants to tackle such software changes because they are busy on enhancements in-game, which will be in both platforms. I was hoping that the drive to get to an initial, stable launch point for FGU was the reason SW might not be receptive right now to suggestions that reduce the number of errors people make in setting up for their game (unpacked, old rulesets, and Nickademus's suggestion).

damned
April 29th, 2017, 04:15
Hi Bidmaron, I'm also not dismissing your views. This is just another view point. Regular forum users see these posts a few times a week. That really isn't that many in the scheme of things. My guess would be that most users never unpack a ruleset, many probably never even load an extension. So while it might be a good thing it might just not be affecting enough people that it gets to the to of anyone's list. From my end I'm almost always running an unpacked ruleset do I would just be clicking OK in the alert and I would still go thru the troubleshooting process, slap myself on the head and delete and unpack again until the next time it happened.

Another good suggestion is to have some sort of extension compatability/approval checking but that creates a burden on dungeon to keep that system maintained and still might not detect when someone mods an extension or ruleset.

The biggest technical issue for me is the NAT challenges that many people have and it can't be solved with the current engine.

We all have different pain points so it's only natural we are not always going to agree.

Bidmaron
April 29th, 2017, 12:53
Hey, damned, I'm right there with you. It is up to SW to determine the best use of scarce resources. I just hope guys don't attack someone with a suggestion as has happened in the past. Perfectly fine to point out that there are valid reasons NOT to do what someone recommends or that it is simply too hard to make it worth the while or that it doesn't fit SW priorities right now.

In most cases, I float things here to see what reaction is before I put it into the wish list.

I was just responding because Nickademus mentioned something that would cut down on the support necessary, and I chimed in with another one. It has been several weeks since a push, but you will find after nearly every release, there are several cases of folks with unpacked rulesets that require assistance on these boards.

osarusan
May 1st, 2017, 02:30
Hhhmmm, all of those image names in the errors in post #1 aren't from player modules, they're from Volo's Guide to Monsters. And you said that you were getting errors like these when players opened modules - so I guessed that you had at least Volo's guide to Monsters shared. If you have, then it needs to be unshared and the players need to clear their cache.

Well that's the weird thing, because Volo's Guide (Players module) was shared, but the DM module wasn't shared. I'm not sure if the images are from the players' module or the DM's module... in any case, we cleared our caches, and for now the errors aren't coming back.

I also noticed that every time I added a custom image to the images folder, it was automatically shared, so I had to manually unshare those. I think part of the problem may have been having lots of custom images suddenly sharing to the players after I added a large number of battle maps.

Last weekend nobody complained about errors though, so here's hoping that clearing the caches did the trick...