MapTool 1.3 Development Build 63

[Hawke]

Had a great session with b63... a bunch of newbies who'd never used it before and it went pretty smoothly. Other than than half the initiatives getting overwritten if too many people rolled at once several times, I think the only annoyance I saw was a bug that stuck my spacebar-pointer on the map. I could spacebar and move it around but it never went away, even if I disconnected/reconnected. I just moved it off to the side of the map so it wasn't a big deal.

Good times... so does it seem like 63 might be final?

[dorpond]

I think the only annoyance I saw was a bug that stuck my spacebar-pointer on the map. I could spacebar and move it around but it never went away, even if I disconnected/reconnected. I just moved it off to the side of the map so it wasn't a big deal.

I have seen this behavior with one guy at our gaming table from time to time. Not often, maybe once every 10-12 gaming sessions. This has been happening for a long time and hasn't been introduced in b63 - I am curious what could be causing this though.

[Guyon]

Fist post so I hope this is not user error but...
My mouse wheel only zooms in on maps, I can not zoom out.


info:
OS: Vista
Java installed (Version 6 Update 17)
Mouse: Microsoft Comfort Optical Mouse 3000

[aliasmask]

So, is 1.3b63 the last before 1.4 comes out? I hear some good thing about the new build and I look forward to using it.

[Rumble]

Fist post so I hope this is not user error but...
My mouse wheel only zooms in on maps, I can not zoom out.


info:
OS: Vista
Java installed (Version 6 Update 17)
Mouse: Microsoft Comfort Optical Mouse 3000

Nah, not user error - it's a mouse driver issue with Java. If you uninstall the Microsoft drivers (and just use the basic drivers), it should allow you to zoom in both directions.

[Cweord]

I'm don't have MT on this machine, but if I remember correctly, z was mapped to reverse the direction of zoom to help with this.

[Guyon]

Great hint Cweord. That worked great,

[saricmaxim]

My group and I just recently jumped from .b56 to .63, and the stability is very solid. We only had like 2 d/c's but that's because that particular player has fluctuating internet issues. Either way, the server didn't melt down and the macro speed didn't seem to lag like some of the post .b56 versions. (I had been trying them on the side and didn't like waiting for a simple change state macro to take 5 seconds).

Either way, I wanted to say thanks to the devs for this build and all the hard work they have put in maptool throughout the years. If any bugs come up in other sessions, I'll try to post about it.

[Taragnor]

The only macro lag I seem to get is doing macros on multiple tokens. For whatever reason, whether you do a foreach loop with getSelected() or you have a campaign macro that runs the macro on selected tokens, you still get a geometric increase in macro run time the more tokens you select.

This doesn't seem to be a problem with smaller macros, but larger ones cause MT to choke.

Oddly however, if you have the initial macro just spawn a macro link to your bigger macro and execute it. It definitely speeds up execution time a lot. That method seems innately superior to the previous methods.

[Gringoire]

Oddly however, if you have the initial macro just spawn a macro link to your bigger macro and execute it. It definitely speeds up execution time a lot. That method seems innately superior to the previous methods.

Interesting.

[Darinth]

Oddly however, if you have the initial macro just spawn a macro link to your bigger macro and execute it.

That... is very odd. Not something I would postpone a 1.3 official over, but definitely a performance issue to take a look at in 1.4.

[lmarkus001]

Ran two sessions over the weekend ( ~ 8 hours and ~3 hours ). Did not have a single disconnect (but all of the machines were on the same local LAN (albeit wireless).

Encountered a couple of notable hiccups (not sure they need attention, just figured I would share).

Memory and Hosting. The GM was originally hosting and his machine was working way too hard and he was readily approaching the 1024M he allocated for MapTools. I started hosting (on a beefier box) and my memory needs never broke 400k and his reduced to about the same level. We did not take time to try to figure out why he was having those memory issues when hosting.

Hosting and Macros. I have found that if the GM is hosting the server and running lots of macros, a rare lockup can occur. So now I always host on a separate machine that runs no macros. This provides a very stable server and GM client environment.

Random Lockup. My framework provides a character sheet in a Frame. Sometimes when I initially try to open the Frame, MapTools just locks up and the process has to be killed. This is totally random. I "think" it might be tied to fetching images from a table, but I am just guessing.

Image Propagation and memory. We had some players drop images on the map that did not propagate to everyone. After some exploration, we found increasing the amount of memory Java was allowed resolved the issue. The folks having the issue were launching with 512M and when they relaunched with 768M the images came across just fine (they were at ~200/500 memory usage when it failed to bring the 50k image over).

So in recap, we were overall very stable and functional. MapTools is definitely not perfect, but it is sure good enough!

[lmarkus001]

The only macro lag I seem to get is doing macros on multiple tokens. For whatever reason, whether you do a foreach loop with getSelected() or you have a campaign macro that runs the macro on selected tokens, you still get a geometric increase in macro run time the more tokens you select.

This doesn't seem to be a problem with smaller macros, but larger ones cause MT to choke.

Oddly however, if you have the initial macro just spawn a macro link to your bigger macro and execute it. It definitely speeds up execution time a lot. That method seems innately superior to the previous methods.

Have you tested with the Selected window totally closed? I think the redraw function that compares token macros and provides a grouping of common macros is a major processor hog. If that window is closed, the getSelected() might not need to do that window refresh work and might get faster???

[Rumble]

Have you tested with the Selected window totally closed? I think the redraw function that compares token macros and provides a grouping of common macros is a major processor hog. If that window is closed, the getSelected() might not need to do that window refresh work and might get faster???

IIRC, Dorpond and I saw definite differences in speed on tokens with fewer macros (which may have been more related to having that window visible, as opposed to actually having lots of macros). Could be unrelated, but it's worth checking.

[jespley]

My group also has experienced a significant increase in the number of disconnects recently; I honestly can't remember if this started with b62 or b63. In all cases, we were able to get people reconnected easily. I don't know if anything has changed in the networking part of the code recently or if these are just random glitches. This thread has a couple of reports of similar experiences but that could just be coincidence.

Thanks for the great program!