PDA

View Full Version : 3.3.0 Ultimate goes BOOM



Ebein
April 22nd, 2017, 19:27
I've been running test sessions with my players for about 2 weeks now, and last night was our first 'official' session.

I had 2 players connected on lan, and 7 connected on wan. and over a 3 hours session I had 2 serious crashes, are there logs I can look at or send. I was happy to see
that FG managed to bring us back to almost the instant of the crashes, but its still 5-6 minutes while I reboot and everyone reconnects. Annoying.

Help/suggestions appreciated.

System
Ryzen 7 1800x
ASrock X370 pro
32 gb ddr4 3200 ram (2x16)
Sapphire RX480 8gb driving 4 monitors( 1x4k & 3x1080 )

Software
Up to date Windows 10 pro
FG 3.3.0 Ultimate, all clients on FG Demo
Modules
DD Dungeon Masters Guide
DD MM Monster Manual
DD PHB Deluxe
FG Battle Maps
just one custom map loaded 2722x1778 24 bit PNG ( 3.81mb )

Zacchaeus
April 22nd, 2017, 19:34
Hi Elbein welcome to FG

That's an awfully big map; you should try to keep may size down to < 1Mb. Use .jpg rather than png format.

Additionally you've listed the modules you used but which of those were shared with the players? I think there might also be issues with LAN connections if that isn't set up properly but I'm no expert on such matters.

LordEntrails
April 22nd, 2017, 21:40
If FG exited/crashed, then that is most likely a process size issue. Even though you have 32GB RAM, FG can't use more than about 3GB. That's because FG is a 32 bit application. And that's why the map you mentioned is the likely culprit. Even though file size is only 3.8MB, when you open it, it will use a great deal more than that. You can test by watching your Task Manager and watching what hapens when you open your campaign and then the map.

Moon Wizard
April 22nd, 2017, 22:16
Also, you should ensure that only the PHB is shared with the players, and not the DMG or MM. You can always share individual records, but you shouldn't share the whole DMG or MM. In addition to requiring more memory on clients than GM, they usually are meant to be GM only data to be shared on a specific record basis.

Also, the number and size of the tokens in your tokens directory, as well as the number of token modules you have loaded can impact GM memory usage.

Regards,
JPG

Ebein
April 22nd, 2017, 22:24
Also, you should ensure that only the PHB is shared with the players, and not the DMG or MM. You can always share individual records, but you shouldn't share the whole DMG or MM. In addition to requiring more memory on clients than GM, they usually are meant to be GM only data to be shared on a specific record basis.

Also, the number and size of the tokens in your tokens directory, as well as the number of token modules you have loaded can impact GM memory usage.

Regards,
JPG

Thanks for the info. I will review my memory useage. Will there be a 64 bit port in near future?

I honestly dont know if i had books shared with the players at crash time, Im still fiddling with how to best organize the data for each session.

Ebein
April 22nd, 2017, 23:08
Is there a method to manually flush the memory? Ive restricted sharing on all books except the PHB from the players in the library. other suggestions? opening everything im only hitting ~800-850mb memory useage.

LordEntrails
April 22nd, 2017, 23:49
The players can clear their cache, which is the little nuke/folder icon on their start screen. That will force them to re-download the next time they connect, so if you do this, have them stagger their connections so your computer isn't overloaded (since FG is also single threaded).

Yes there is a new version in the works, usually referred to as FGU or Unity. But, no ETA on when it will be released as it is a complete re-write using totally new architecture (based on the Unity engine).

damned
April 23rd, 2017, 01:46
It is a big project and there is no ETA yet on FGU.

Ebein
April 23rd, 2017, 04:18
I was just messing around again, checking my converted PNG maps and watching the task manager at 497mb memory useage, I clicked on the navigator button in the layers menu and FG crashed again.

damned
April 23rd, 2017, 04:22
Ebein if you would like me to have a look with you please send me your email address via PM.

Ebein
April 23rd, 2017, 18:48
I was unable to replicate the nav button crash even while running north of 1 gb of memory used. All crashing issues seem related to map functions.

Trenloe
April 23rd, 2017, 18:52
I was unable to replicate the nav button crash even while running north of 1 gb of memory used. All crashing issues seem related to map functions.
Are you able to provide some steps to reliably reproduce please? With a publicly available map so we can test as well?

Ebein
April 23rd, 2017, 19:02
I've not been able to reliably reproduce the issue, though in all 3 events it has been manipulating the map ( panning, zooming, trying to use the nav fuction on a zoomed in map ).
Maps I have been using are scans of TSR products ( Keep on the borderlands is what I've started with ). The initial map was 3.8mb ( about 125mb when opened in FG ).
I have begun creating those maps in Dungeonographer and exporting simple png's in the < .5 mb size range.

Since being told FG is 32 bit I have been running with the resource monitor running in another window to ensure I stay well away from hitting a memory limit.

Im guessing I need a crash course on better managing which resources are in memory, and module organization.

Trenloe
April 23rd, 2017, 19:26
Can you do a quick check on the Settings window accessible from the main FG start screen. See if "Cross Compatibility..." is set? If so, disable it.

Trenloe
April 23rd, 2017, 19:28
Also, please clarify what you mean by crash. Does FG exit without an error? Do you get an error? Does FG become unresponsive?

If the latter, FG unresponsive or showing "Not Responding", then give FG some time to recover - it is single threaded so can become unresponsive at times when it is doing a lot of background processing.

Ebein
April 24th, 2017, 03:29
Can you do a quick check on the Settings window accessible from the main FG start screen. See if "Cross Compatibility..." is set? If so, disable it.

Its been disabled since i switched from Demo to Ultimate.

Other settings
UI scale 100
Check Steam for DLC on
Live mode updates, Enhanced Update Logging on

Ebein
April 24th, 2017, 03:32
Also, please clarify what you mean by crash. Does FG exit without an error? Do you get an error? Does FG become unresponsive?

If the latter, FG unresponsive or showing "Not Responding", then give FG some time to recover - it is single threaded so can become unresponsive at times when it is doing a lot of background processing.

takes the machine down to POST. Is there a Test mode I can switch too with more Verbose error logging?

Trenloe
April 24th, 2017, 03:41
takes the machine down to POST.
So it actually forces a reboot of your computer?

If so, this is something up with hardware setup/drivers in your computer. As you're running 4 monitors (1 being 4K) and this usually occurs when you're doing "stuff" with images I'm guessing it is something to do with your graphics driver/config.

Look in Windows event viewer to see if there is an indication of what caused the crash.

Might be worth playing with the advanced graphics settings - unfortunately, this will be pretty much trial-and-error, but start with reducing 3D settings (turn off anti-aliasing and antistropic filtering). Also, just for testing, turn off some of the monitors and try to reproduce the issue on just one monitor.


Is there a Test mode I can switch too with more Verbose error logging?
Nope. Test is for testing out upcoming versions - Alpha/Beta testing. Plus, to be perfectly honest, now that we know how your computer actually behaves with this then an immediate exit of Windows won't give the application a chance to log details of any issue.

Ebein
April 24th, 2017, 15:47
Spent some time talking to damned yesterday ( thanks! ) and will try his suggestions and see if stability improves.

1. Turn Steam overlay off for FG
2. keep images within 'recommended' size of 2k x 2k max
3. reduce window size on 4k monitor to approx 3k resolutions until stability is confirmed then increase the size and see if the system remains stable.

Are there any other hard limitations on the engine aside from the 3gb ( 32bit ) limit?

damned
April 24th, 2017, 15:51
3(might be 3.2)GB memory and it only uses a single CPU/Core/Thread.

Trenloe
April 24th, 2017, 16:04
The memory limitations usually result in the Fantasy Grounds application exiting. I've never known it to force a full restart of Windows.

Have you looked in the windows event viewer to see what it reports at the point you've had issues? That would be the first place to look...

Moon Wizard
April 24th, 2017, 17:50
I'll echo what Trenloe says. Whenever we've seen a full full crash of Windows while using Fantasy Grounds, it is typically related to graphics drivers. When any application code crashes due to memory limits, Windows will catch the error and exit the application. However, when driver code crashes, it can take down the whole operating system.

Regards,
JPG

Ebein
April 26th, 2017, 18:52
Having followed the advice given, last nights 9 player session went off without a hitch.

Ebein
May 12th, 2017, 16:20
Session Summarys
Session 1 : 2 crashes
--- this trhead starts and i get some advice
Session 2 : following the advice here no crashes
Session 3 : no crashes
Session 4 : no crashes
Session 5 : don't think i changed anything but we had 3 crashes to POST. Will update graphics drivers and clear caches before session 6 Saturday.

Moon Wizard
May 12th, 2017, 17:51
Make sure to check your memory usage again while FG is running. If not memory usage, see if you can think of anything specific you were doing just prior to crash.

Thanks,
JPG