MapTool 1.3 Bugfix Build 76

[LeopoldVonRanke]

My version of Java: 1.6.0_22, 64bit, running in an 8GB real-memory Mac OSX Snow Leopard

Excellent, thanks. I have almost the same environment (4GB laptop though). That also means that this is not a JRE-specific issue; it's definitely MapTool code.

Uuh, the file is 22 MB. But on top of that -- I just reopened it after a fresh restart,--- and the problem wasn't there! This is crazy!
So far is has happened reliably every time.
The only difference is that I added a macro today which registers a method in a lib that moves the map to the handed coordinates; only registering them, not calling them upon load, mind you. Is it possible that registering a macro for a lib triggers an additional initial draw already? I wouldn't think so. This is very confusing.

Wait... I did manage to re-trigger the problem again: By using the Screenshot Export function (make sure you export the entire map). After that, the screen was again only partially properly drawn; this time though, only the Token layer was missing, but the Hidden and Object layers had been drawn properly and completely.

Sorry for the complication... Azhrei, do you want the campaign file despite its 22 MB size?

[wolph42]

Az I have the same problem with my campaign file, moreover you can move the map around select tokens that are visible and still at least one remains invisible until the zoom button is touched. This happens in my framework (see sig) you can download it from the forum.

Also, the dungeon tool I just designed show this behaviour after a screenshot has been taken as Leopold mentions. This campaign file is also on the forum an can be found here: http://forums.rptools.net/viewtopic.php?f=3&t=16676

[Azhrei]

Thanks wolph, I grabbed yours. And I have DW's as well. @Leo: no thanks, keep your 22MB.

The larger the campaign, the more work there is in eliminating things that are not factors.

I have some custom mouse pointer stuff I plan to work on tonight so it'll probably be tomorrow before I look at this.

[wolph42]

ok I encountered an annoying issue. It's not really a bug, but annoying nonetheless. When you set tokens to free-size and snap to grid, Maptool aligns them differently in the background layer. The tokens are in the Token, hidden and object layer centred to grid, but in the background layer they are aligned to top-left corner. I'm currently making tokens in Photoshop for my dungeon-builder tool and I'm trying to make them align correctly in all layers, but that's currently impossible.

Attached is a sample token and the original png file.

Set grid to 100px
Set token snap to grid
Set token to freesize
It's currently correctly aligned for token, hidden, object layer
Move it between these and the background layer and observe the change.

I would assume this must be consistent over all layers

[dorpond]

@wolph42
Yeah, this has been known behavior since forever. Objects snap differently than backgrounds. I think that is what you are getting at.

I recall that being by design since objects would mostly be in the center of a cell and background tiles would snap to corner. That was Trevor's logic anyway.

[Edit] which BTW we really shouldn't change at this point in 1.3 because it would affect many or our existing campaigns and already released art packs (Torstan's for example)

[Azhrei]

I recall that being by design [...]

Yep, it was. I remember a LOT of discussion about it!

It had something to do with common use but I don't remember the details. I know part of it was that when tokens and objects were dropped on the map it would be expected that the center of the image would be the snap point. This makes a lot of sense if you think about how you use it.

The background layer holds maps though, and when people put maps on the background layer they likely would want to specify the upper left corner as the snap point.

That's the way the code is now. Having said that, it's theoretically possible that the snap point could change only when changing the layer of an existing image. Dropping them would work exactly as it does now, but when changing an image from one layer to another it would (also) make sense to ensure that the image doesn't move appreciablly, ie. more than one-half of a grid cell.

So a token with a snap point in the center could have the snap point automatically offset by enough to move to the snap point to the upper left when the token is moved to the background layer. That way the image wouldn't move at all. The reason for the one-half grid cell adjustment is because images that are snap-to-grid might have to be tweaked slightly so that the snap point is still grid-aligned. But it would never have to be offset by more than one-half of a grid cell's width and/or height in order to snap properly.

However, this is only an issue when moving things to the background layer and there's really not much need for that. The background layer (generally speaking) is only used once: when the GM is building the map. So this is only a problem when the GM is building a new map and accidentally ends up dropping images on the wrong layer and then wants to move them later.

In short, this would be a nice thing to fix but it won't be very high priority since there's a work-around ... "don't do that".

[wolph42]

I recall that being by design [...]

Yep, it was. I remember a LOT of discussion about it!(...) since there's a work-around und layer and there's really not mu... "don't do that".

I understand the reasoning, if you drop a complete map in MT with the correct grid and px setting, you don't want it to snap to the center but to the corner.
...
I don't think you should fix that (even considering how much I would like that). I guess the 'best' solution is either creating an extra layer 'Map(s)' and leave the background on top or as you plan in 1.4: make the layers customizable, then you could just add a button 'snap to corner or snap to center'.

For now I'll work around it.

[PolaroidNinja]

I dont know if anyone else has had this issue, but my group and I didnt start getting it until we switched to this build tonight.

Every so often, usually right after copying a group of selected tokens for me - I didnt ask what my players had done, Maptool would just lock up completely. The only action I could take was to minimize the window and then after maximizing the winidow the view area would be black, but I could still see the file menu (which was still unresponsive). Only a restart of the program would fix this issue. Strange thing was that when it would happen, the server would not disconnect.

Im runnning it on a Windows 7 (64-bit) laptop (4GB) with Java 1.6.0_21.

Just figured I'd mention it.

[Azhrei]

That sounds like the GUI event thread was in an infinite loop.

And you haven't had any updates recently? Network or video drivers?

If it happens again, please check task manager to see if your cpu is pegged at 100% (that would indicate a tight/short infinite loop).

If you installed the entire JDK instead of the JRE (Java Development Kit instead of the Java Runtime Environment) you might have a program called jconsole on your system. That application can look inside MapTool and determine detailed statistics on what's going on inside. If you can run it -- and it works -- it has the ability to dump the internal state of the Java runtime and that could help us determine the location of the problem.

[aku]

This sounds similar to an issue i had had a couple of weeks ago. GENERALLY a ctrl-alt-del would "fix" it Try reducing your max mem to maptools a bit to like 1200, or 1000 if you're above that. Even though i have both 32 and 64 bit java installed (i think) it seems like maptool will only use 32 for me, and that seems to have fixed the problem.

[Dracuul]

Greetings all.

First let me thank all the folks who put so much work into MapTools. It is an awesome tool.

I recently upgraded from 1.3b70 to 1.3b76 and aside from the few things I have read in this thread I have also experienced some issue with saving a campaign. That is to say that it happens occasionally when I am saving a campaign. The specifics (as specific as I can be):

Windows 7 64bit
4g ram
AMD2+

MapTools 1.3b76
Java (Version 6 Update 22)

I am working on my framework so my campaign only has 2 maps atm. My system map and a test map. Campaign file is 10.8m. Occasionally when I save it it will suddenly take 30+ seconds to save, as opposed to the normal 3-4 seconds, and "usually" when it is done saving I suddenly have horrible lag, my memory usage shoots up to almost 1 gig during the save then drops back to about 600 megs and then hovers there. The lag is severe... It takes maybe 1.5 secs for the selection window to refresh and another second or two until the target frame appears over the selected token.

Restarting Maptools, even a reboot, does nothing and the campaign loads but continues to exhibit the same lag. I can then export the map, or drag each of my Lib tokens back onto a new map, in a new campaign, load properties, campaign macros and such and everything is fine. I then do some more work and it will happen again. It has happened to me 3 times in as many days.

Noteworthy:

I am pretty sure I did not have this issue prior to beginning my work with the OnTokenMove function. Not positive but I believe so. At first I thought it was maybe a clash with the auto-save feature but I have since turned that way back, in terms of frequency, and make sure I look at the info line in MapTools to make sure it is not currently auto-saving when I go to manually save it.

Anyway, thank you all very much for your hard work. If someone else posted about this and I have missed it, my apologies.

[Full Bleed]

Had a small issue with a game I played last night with the "All Players" check box sticking when assigning ownership. Not sure when I last tried this, but figured I'd mention it here for verification before putting in a bug report.

[Azhrei]

All Players can't be turned off unless you turn ON the ownership for one of the other players. I think this is a bug, but it's such a small one I've never bothered to look for it...

[Craig]

All Players can't be turned off unless you turn ON the ownership for one of the other players. I think this is a bug, but it's such a small one I've never bothered to look for it...

Or it's a feature. Or at least it was when it was added, no player can remove the all players or the last player from the token as a player should not be able to create a GM owned token (this also stops them from making trusted macro libraries). If the GM can not remove all players then something has changed since that fix, in which case that would be a bug as the GM should be able to.

[Full Bleed]

Not sure I'm totally following what you guys are saying.

The circumstance in which I was trying to use the feature was that the party was split and some of the players couldn't see what was happening in another room. Since I was ok with them seeing it I switched to another player's token in the room and clicked "All Players" under ownership, expecting them all to then all be able to see through the token (and move it, etc.) The "All Players" selection would not stick.

Ultimately, I had to check all the player's boxes individually on the token to give them all ownership and then they all could see through the token.

Likewise, if I fire up MT right now, go to a token and select the "All Players" box it never sticks... in further testing it appears that the "All Players" selection box only sticks if no other boxes are checked.

If it has to be that way, why not make selecting the box deselect all the other boxes? It actually makes more sense to me to see it select all the player's boxes if selected... but, basically, it's just tough to tell what's going on when nothing happens.