MapTool 1.3 Bugfix Build 66

[Phergus]

EDIT: as a note, when I check the process memory while it is hanging, javaw.exe is using more than the alloted max RAM set when I launched MapTool. I am thinking that java is hitting the memory cap and this is why it is hanging. Anyone knowledgable in Java have any suggestions on how to solve this problem... I am already maxing the memory at 1G allotted.

You're certainly going to get memory thrashing at that point and it might just fail altogether. With 32-bit OS you can go up to 1.4G which would give you some breathing room for saves. As Azhrei noted the save process itself uses quite a bit of memory over and above what is currently being used.

On a related note, if your campaign is using 1GB of memory then you may want to look at the resolution of your images. In most cases using that much memory indicates that you have loaded images which are a much higher resolution than you are actually using them.

[paulstrait]

Has anyone else noticed a problem with MapTools hanging while it autosaves? Autosaving used to not have any impact on using the tool, but I have noticed since 1.3.b63 that everytime my campaign autosaves it locks the process while doing it. I know it is autosaving doing it because it was happening every 5 minutes or so. I changed the autosave timer to 300 minutes and, like clockwork, when 5 hours hit the process hung. If no one else is noticing a problem, it may just be my campaign (or computer... I'll have to test it on a different PC).

Autosaving is super slow for me too. I'm still using build 64 (waiting for the DMG for 66 b/c two of my players use macbooks). There's another interesting thing I noticed re: memory usage-- I recently upgraded to 64-bit Java, and am therefore able to set my max memory to 2048 (in 32-bit Java, I had to keep it just above 1 gig or I'd get weird errors). The same maps that used to use less than a gig of memory are now using almost the entire 2 gigs. I don't know enough about how MapTool uses memory to know why this occurs, but I thought it was noteworthy.

[Azhrei]

The same maps that used to use less than a gig of memory are now using almost the entire 2 gigs. I don't know enough about how MapTool uses memory to know why this occurs, but I thought it was noteworthy.

Really? The same maps, same campaign?

A 64-bit JVM will take somewhat more memory for its own internal housekeeping, but I would expect the size of maps and such to not grow by more than a few percentage points.

[paulstrait]

Yeah, a map that I can open in maptool when the max memory is set to 1400 will, when opened in maptool w/ the max memory set to 2048, use just shy of 1900 megs...

[Gringoire]

I'm late with dmg file and i'm sorry. I have connection problems. Now i'm writing from iphone. Dmg is ready anyway. I will put it online as soon as i can.

[RPTroll]

On the lauch pages all I see is

config file err: maptool-development.txt

where the link used to be. (sorry if this is a duplicate)

Running Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100402 Ubuntu/9.10 (karmic) Firefox/3.5.9

Edit: Downloaded it from the dowlloads page and it seems to work ok with my framework.

[Richard Weimer]

On the lauch pages all I see is

config file err: maptool-development.txt

where the link used to be. (sorry if this is a duplicate)

Running Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100402 Ubuntu/9.10 (karmic) Firefox/3.5.9

Edit: Downloaded it from the dowlloads page and it seems to work ok with my framework.

Ditto for me, using IE8 under WinXP SP3.

[Azhrei]

Okay, it looks like the hosting service changed the .htaccess file; our hosting server wasn't allowed to use a URL to talk to itself. I.e. the server wasn't allowed to use "download.rptools.net" as a source in a request to retrieve a file.

I had initially set it up that way to make it more scalable and allow for some things to be off-loaded to other hosts.

Anyway, I removed the "deny" line from the .htaccess and everything works fine again. Sigh.

[Pyroman]

A quick update on the save issue. Thanks to everyone's input I have determined that it is not related to saving, per se, but instead is a java memory issue. The save process is just pushing me to the limit, but I experienced the process hanging last night. I attempted to increase the max memory to 1200 and the campaign would not even load. It would hang on the campaign load screen. I then tried to decrease the memory limit from 1024 to 768 and it ran solidly the rest of the night. Apparently Java is real picky about memory usage when playing around near the 32-bit cap.

On a related note, how does one force the use of 64-bit Java? Is it tied to the default browser? I ask because I am running Windows 7 Ultimate (64-bit) on a 6GB machine and it still runs Java in 32-bit. I do not know where to change this to make it use the 64-bit version which I have installed in the 64-bit IE8. My default browser is Google Chrome which is only a 32-bit browser.

There's another interesting thing I noticed re: memory usage-- I recently upgraded to 64-bit Java, and am therefore able to set my max memory to 2048 (in 32-bit Java, I had to keep it just above 1 gig or I'd get weird errors). The same maps that used to use less than a gig of memory are now using almost the entire 2 gigs. I don't know enough about how MapTool uses memory to know why this occurs, but I thought it was noteworthy.

I have done some checking around on this and it seems that there is an increase in memory usage when going from 32-bit to 64-bit because each native pointer in the system uses 8 bytes instead of 4. More (semi-)useful info can be found at the following link: http://java.sun.com/docs/hotspot/HotSpo ... escription

[Gringoire]

here is dmg file.

[RPTroll]

Okay, it looks like the hosting service changed the .htaccess file; our hosting server wasn't allowed to use a URL to talk to itself. I.e. the server wasn't allowed to use "download.rptools.net" as a source in a request to retrieve a file.

I had initially set it up that way to make it more scalable and allow for some things to be off-loaded to other hosts.

Anyway, I removed the "deny" line from the .htaccess and everything works fine again. Sigh.

We appreciate all you're doing Az. Thanks for the fix.

[Gringoire]

Okay, it looks like the hosting service changed the .htaccess file; our hosting server wasn't allowed to use a URL to talk to itself. I.e. the server wasn't allowed to use "download.rptools.net" as a source in a request to retrieve a file.

I had initially set it up that way to make it more scalable and allow for some things to be off-loaded to other hosts.

Anyway, I removed the "deny" line from the .htaccess and everything works fine again. Sigh.

We appreciate all you're doing Az. Thanks for the fix.

i'm agree. I love this work and all you can do for us.

[Azhrei]

Heh, thanks guys.

I've put the .dmg on the download page. One of these days I'll figure out how to add the dmg creation to the ANT build script when running on OSX...

[Gringoire]

Heh, thanks guys.

I've put the .dmg on the download page. One of these days I'll figure out how to add the dmg creation to the ANT build script when running on OSX...

You should create .app file first.

[Azhrei]

I have done some checking around on this and it seems that there is an increase in memory usage when going from 32-bit to 64-bit because each native pointer in the system uses 8 bytes instead of 4. More (semi-)useful info can be found at the following link: http://java.sun.com/docs/hotspot/HotSpo ... escription

That's correct. Pointers inside the Java runtime will be twice as big. However, integers and longs will be the same size they always were (defined by the language spec) so it's only the internal memory sizes that grow. Because some of the image handling libraries in Swing are "native code" (i.e. written in C and not Java) they will have larger pointers. The size increase due to those pointers should be insignificant compared to the size of the images themselves: a small JPEG of 100x100x24 is 30KB and due to the way the native libraries rasterize the image there will be some overhead for each row of data, I'd guess an extra 8-16 bytes. With 100 rows that means 800-1600 bytes compared to the image size of 30,000 bytes. In other words, about 5%.

I've put the .dmg on the download page. One of these days I'll figure out how to add the dmg creation to the ANT build script when running on OSX...

You should create .app file first.

I have the link to Apple's page that discusses the JAR Builder, but I need command line utilities that can do the work. Do you know of any such utilities?

Edit: Woohoo! I found this page which describes an ANT task for running the JAR Builder. I'll read up on this over the next few days... It would be particularly cool to associate the .cmpgn files with the .app so that double-clicking the campaign file would run MapTool and load the campaign.