Release v3.2.1 is live

[Nickademus]

With the changes to the minimum width of images, it seems the radial menu option to Resize -> Original Size puts the image to the width it would be before 3.2.1.

In the attachment below I literally just added this image to the campaign. It showed up the proper size with the Name and UnId'd fields being clipped. But when I used the radial menu for Original Size, it blew back up to the size it was in the other campaign I'm using the image in.

(Well, can't attach things in this thread so you'll just have to imagine it.)

[Rades]

You're using the enhanced image extension - this has not been updated to v3.2.1 yet.

See post #2 of this thread!

Ah that's totally it, doh! Thanks for the fast reply! I'll have to be sure to monitor the Enhanced Image post to see when it updates.

[Trenloe]

I'll have to be sure to monitor the Enhanced Image post to see when it updates.

Maybe 4, maybe 5 minutes...

[Trenloe]

[CoreRPG+] Minimum size of image window reduced.

The code that scaled based off minimum size off the right-click "imagesizeoriginal" menu hasn't been removed, so this right-click menu doesn't size the image correctly for small images (less than 500x300). CoreRPG script = campaign\scripts\imagewindow.lua

[Nickademus]

Thank you Trenloe. I was able to find and comment the offending code in my CoreRPG ruleset. The resize is working fine for me now.

[Chidgey]

The 3.2 release has pretty much made the game unplayable for me. If you have a large module such as a complete 4e parser output then since 3.2 you will constantly get a "Runtime Error: Exception: bad allocation" with the application going over the 2gig process limit. In the last session I run there were 7 crashes from this error alone.

It seems that there is a memory leak in the module code (same as in 3.0.3) so when you open something in a module its memory stays allocated. With large modules you quite quickly go over the limit. Its fairly easy to reproduce, if you just open and close the feats section of the 4e parser scrape the process memory jumps 100mb each time and when the process hits 2GB it crashes. Upping your memory limit or changing the process to be large address aware mitigates the problem as it takes longer to reach the limit but you will eventually get a bad allocation when you hit 4GB.

There is also a second module error, when you try to open a very large powerlist such as a list of all 9000 odd 4e powers the server becomes unresponsive and constantly resizes from full screen to fullscreen minus the windows start bar, every 3 seconds.

Neither of these problems existed pre 3.2.

[Trenloe]

Upping your memory limit or changing the process to be large address aware mitigates the problem as it takes longer to reach the limit but you will eventually get a bad allocation when you hit 4GB.

As mentioned in the other thread you posted in - FG is a 32-bit application and is already Large Address Aware (has been for 4 years). So, if you're running a 64-bit operating system it can utilize approx 3.7GB of memory. If you're on a 32-bit operating system the theoretical limit is 2GB, but practically you'll find FG becomes unstable around 1.6-1.7GB of memory utilization.

Thanks for providing some info regarding re-creating high memory use. Hopefully that will help the devs pinpoint the issue.

[Patou]

Hi Team FG,

I ran into problems on Friday night during my home game. As I flipped open my laptop and the other laptop I use for the players FG needed to be updated. Once the updates complete on both computers I proceeded as I usually do before every game which is load my game first and then have the other laptop join the game by clicking on the IP address. No extensions were loaded.

The first bug happened right after I clicked on the first PC portrait when adding the Characters to the game. The script menu opened ........
I closed FG and reloaded it and emptied the cache = problem solved

As my players were beginning to arrive I wanted to show them the cool reference manual layout since the update. The PHB is a shared module but it would simply not load on the pc computer... everything seemed to stop.... then the script window opened and began filling up the window without end. I couldn't even close FG. I had to Ctrl Alt Delete and close via Task manager. Before joining the game again I re-emptied the cache

After rebooting I came to loading my players map of the Ice Cave in Tyranny of Dragons and proceeded to sharing it. It would not finish loading and then the script window appeared again and began filling up to no end. Now everything also seemed jammed on my end. i verified our connection and the internet and everything was fine. I had to repeat the process as i had done before.

Crossing my fingers and my players gone for a beer break I proceeded in rebooting both computers completely. I went straight with the module images and no longer used my updated ones I had made with CC3. Everything ran smoothly for the rest of the night.

I wanted to copy the clipboard and log in to the Forum but with all the delays and my players getting upset I told myself I would try to repeat the process when I had the chance this week. Hopefully it was simply an update the laptops needed to have things run again. I'll keep you posted as I try this again tonight.

[Nickademus]

If you're on a 32-bit operating system the theoretical limit is 2GB, but practically you'll find FG becomes unstable around 1.6-1.7GB of memory utilization.

I find this interesting. I'm on a 32-bit OS and I've had FG run flawlessly at around 1.8 GB for over a year. Recently in a game, something happened to make the memory usage (for that game only) go up to around 2.5 GB which lagged the opening of new programs but didn't seem to affect FG. The next session it got up to around 2.9 GB and that's when FG became unstable. I was under the impression that greater than 2 GB was impossible on a 32-bit system, for the same reason you are citing here.

[Trenloe]

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

If your OS allow 4-gigabyte tuning (4GT) you can get up to 3GB use. But most operating systems don't have this.