MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

New build announcements plus site news and changes.

Moderators: dorpond, trevor, Azhrei, Craig

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Post by jfrazierjr »

Azinctus wrote:
jfrazierjr wrote:
Azinctus wrote:The problem I reported with Individual Fog of War (IFOW) in B.80 persists in B.81. Someone said it was because of the teleport gates and copy token that the players are erroneously exposing fog of war for everyone. Is there any plan to fix that or are teleporters and IFOW simply incompatible?
Can you give me some more details. I have been real busy the past few weeks and not had a chance to keep up with the forums.
Here is a link http://gallery.rptools.net/v/contrib/Az ... cmpgn.html to my campaign file. This file had the problem in B.80. We ran with the same campaign on Monday in B.81 and had the same problem.

On the map pub interiors there are six PCs. Angelo Rackham explored the upper floors of the house where he is and by doing so inconsistently exposed FOW for Aspharagus, Verity and Bossdrum.

Your best bet to find the PCs is to use the map explorer. This map uses widely spaced small areas to represent the interiors of various buildings in the city, doors and floors are connected by teleport gates.

As an aside the players mentioned that they could see more in the map explorer window than normal. They could see NPCs and other PCs listed in the Tokens and Players sections.

All options are ticked on the server, the map is day, vision and FOW on.
I briefly checked this out, but due to the large distance between cleared areas with intervening FOW, I could not tell anything was changing. Perhaps you can recreate on another, smaller map with the same tokens? Was there light on the map(I did not notice)? If there WAS light on the map, was it possible that the light was within the three token's vision range? If so, this would easily account for what you are seeing as that is...well by design.

I really won't be able to check into this more for at least several days.
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Post by Azhrei »

aliasmask wrote:I spoke too soon. I reopened campaign and using the -50 to the asset and it gives me the graphical glitch. I changed it use the height and width and the error goes away but the "?" obviously shows up when the image is loading for the first time.
Using the asset:// URL is just like using the http URL -- the protocol handler code has to find the image and then build a new one based on the requested size. Since image loading is done asynchronously, it's possible for the "?" to show up because the asset handler doesn't have the info yet but the rendering code wants it! Once the thread has finished scaling the image, the "?" should get replaced with the actual image.

I have no idea why a portion of the image wouldn't show up, however. It's possible that with incremental loading that only portions of an image might be displayed except that (a) MapTool doesn't use incremental loading, and (b) that wouldn't explain a chunk missing from the upper right corner (since both JPEG and PNG read an image from row0 to rowN).

Since the clipping rectangle for an image is set to the size of the image itself when it's drawn, again you wouldn't get a chunk missing out of one corner if the problem were the clipping rectangle.

Can you start a new thread about this? Please document your machine config as well, as this could be a display driver problem. (The image drawing code would be handing the information off to DirectX on Windows and it's possible that DX is getting it wrong.) Maybe we can find out if others are having the same problem.

Azinctus
Giant
Posts: 133
Joined: Tue Nov 18, 2008 10:16 am

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Post by Azinctus »

jfrazierjr wrote:I briefly checked this out, but due to the large distance between cleared areas with intervening FOW, I could not tell anything was changing. Perhaps you can recreate on another, smaller map with the same tokens? Was there light on the map(I did not notice)? If there WAS light on the map, was it possible that the light was within the three token's vision range? If so, this would easily account for what you are seeing as that is...well by design.

I really won't be able to check into this more for at least several days.
I can try and create a new map to replicate the problem but it is an inconsistent problem. And I haven't been able to make it happen by myself, it may require people logged into the server.

The map I have uploaded represents the problem. The three PCs on the ground floor (Yappi, Asphragus and Verity can see parts of the upper floors in the building (zoom out, the upper floors are approximately 130 hexes to the left of the previous floor). But those characters did not go there, only Angelo went there.

It is a day map so light sources shouldn't have any effect and I think no one has a light source either. Anyway the location revealed is on the other side of 130 hexes of light blocking layer.

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Post by Azhrei »

Azinctus wrote:The map I have uploaded represents the problem. The three PCs on the ground floor (Yappi, Asphragus and Verity can see parts of the upper floors in the building (zoom out, the upper floors are approximately 130 hexes to the left of the previous floor). But those characters did not go there, only Angelo went there.
I have seen this as well.

It appears that one of the tokens exposed an area of fog that was added to the "global exposed fog area" for the map and not the individual token. I'm going to take a look at this to see if it can be fixed before tomorrow's build (oops, "today's build" now ;)). Otherwise we'll probably push back the final build until we get this fixed. This particular problem is not acceptable for the final build. :?

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Post by wolph42 »

Edit:SOLVED IN b81

I've come across another bug, which fortunately is very easy to duplicate.
It seems that when you use the setLibProperty function on a map while the lib:token you're setting is on another map, its duplicated to the current map.
This means that when you're running a macro and part of it sets or saves a value, you get an error immediately afterwards: duplicate lib token.

As a work around I've tried switching maps and use removeToken, but nothing works.

Duplicating is simple:
Drag the dragon onto the map and put "lib:" in front of it.
Create a new map and paste this:

Code: Select all

[H:setLibProperty("Strength",50,"Lib:Dragon")]
into the chat.
Last edited by wolph42 on Wed Jan 12, 2011 2:11 pm, edited 1 time in total.

osman
Giant
Posts: 100
Joined: Sat Apr 12, 2008 12:23 pm
Location: Latham, NY

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Post by osman »

wolph42 wrote:I've come across another bug, which fortunately is very easy to duplicate.
It seems that when you use the setLibProperty function on a map while the lib:token you're setting is on another map, its duplicated to the current map.
This means that when you're running a macro and part of it sets or saves a value, you get an error immediately afterwards: duplicate lib token.

As a work around I've tried switching maps and use removeToken, but nothing works.

Duplicating is simple:
Drag the dragon onto the map and put "lib:" in front of it.
Create a new map and paste this:

Code: Select all

[H:setLibProperty("Strength",50,"Lib:Dragon")]
into the chat.
Oh dear. Does this happen even using the two-argument version of setLibProperty (with a macro running on the lib token)? I'm at work right now, but I've been building a new framework lately, and it relies heavily on this functionality.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Post by wolph42 »

I think this is a major issue for nearly every major FW. I'm surprised this has not been noticed before.
No clue if the two arg. Version has this as well.

I forgot to mention that I encountered this in MT b80

User avatar
CoveredInFish
Demigod
Posts: 3104
Joined: Mon Jun 29, 2009 10:37 am
Location: Germany
Contact:

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Post by CoveredInFish »

:idea: There was a fix on setLibProperty() causing double lib:token on cmpgn startup from b80 to b81, iirc - i lost track of the changes recently. Maybe this is already fixed...

edit: ... runs of for testing ...

seems to work fine with b81.
Last edited by CoveredInFish on Wed Jan 12, 2011 2:21 pm, edited 2 times in total.

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Post by jfrazierjr »

Wolph... check the latest checked in code(I believe you are part of the testers forum right?) Azhrei has fixed the issue from what i understand... assuming it is the same thing as previously reported.
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Post by wolph42 »

It has indeed been solved in v81. I hadn't noticed earlier that I ran into the problem in v80. My apos. for the spam and worries.

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Post by Azhrei »

Azhrei wrote:It appears that one of the tokens exposed an area of fog that was added to the "global exposed fog area" for the map and not the individual token. I'm going to take a look at this to see if it can be fixed before tomorrow's build (oops, "today's build" now ;)). Otherwise we'll probably push back the final build until we get this fixed. This particular problem is not acceptable for the final build. :?
It looks like this will not be fixed tonight. The dev team is looking at all of the various options to try to determine how it should function. We've added so many checkboxes on the StartServer dialog that it's been getting tough to keep track of what each one does vs. what it should do. And the complexity goes up exponentially as you add more checkboxes! :shock:

So it will be a few days before we've had a chance to hash this out, get potential fixes committed to SVN, and then tested. I'll be posting in the Testers forum as these fixes become available should some of you want to check out the latest and greatest. The more eyeballs the better.

osman
Giant
Posts: 100
Joined: Sat Apr 12, 2008 12:23 pm
Location: Latham, NY

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Post by osman »

I suspect this is going to slip through (it's not even that critical for me), but I have a campaign where I can reproduce the following error quite easily:

java.lang.NullPointerException
at net.rptools.maptool.client.ui.zone.ZoneRenderer.commitMoveSelectionSet(ZoneRenderer.java:446)
at net.rptools.maptool.client.tool.PointerTool.stopTokenDrag(PointerTool.java:203)
at net.rptools.maptool.client.tool.PointerTool.mouseReleased(PointerTool.java:521)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at net.rptools.maptool.client.swing.MapToolEventQueue.dispatchEvent(MapToolEventQueue.java:25)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

The basic scenario is that I have a library macro I'm running on two selected tokens. It removes one of the two tokens, while it's still selected. Then I grab the other one (still selected) and try to move it. ...Hmmmm, come to think of it, I bet if I change the macro to deselect the other tokens before I remove them, things will work. ... Yup. Nevermind. (Although it might be nice for removeToken to remove the token from the selection set so this isn't necessary?)

User avatar
warpoet
Kobold
Posts: 24
Joined: Thu Mar 18, 2010 4:54 pm

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Post by warpoet »

Yeow! I love maptools and always check in to see if there's a new version available. I use it extensively in gaming nowadays.

But build 81's link isn't on the main rptools page anymore--is that because of the latest issues encountered? :-o

edit: Awwww, the properties pane still doesn't size with the window it's in (using a mac). For comparison: build 66, 63, and others allow this. You maximize the window, and the properties pane maximizes with it. But with the recent builds (I think around the time the Visible to Owners Only checkbox became available), the properties window stays small even when you maximize the window. Since my campaigns rely on referencing this window a lot, this makes all the recent builds of maptools, despite their great new features, difficult for my group to use :(

User avatar
silversonic
Cave Troll
Posts: 59
Joined: Thu Oct 15, 2009 6:42 pm
Location: Cleveland, OH

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Post by silversonic »

warpoet wrote:Yeow! I love maptools and always check in to see if there's a new version available. I use it extensively in gaming nowadays.

But build 81's link isn't on the main rptools page anymore--is that because of the latest issues encountered? :-o

edit: Awwww, the properties pane still doesn't size with the window it's in (using a mac). For comparison: build 66, 63, and others allow this. You maximize the window, and the properties pane maximizes with it. But with the recent builds (I think around the time the Visible to Owners Only checkbox became available), the properties window stays small even when you maximize the window. Since my campaigns rely on referencing this window a lot, this makes all the recent builds of maptools, despite their great new features, difficult for my group to use :(
Not to harsh on your point, but I play maptool on a mac as well and I've never had a problem with the properties window maximizing with the main window. In fact I would prefer it stay small so I can see the background while editing properties. Also, are you talking about campaign properties or token properties?
I don't want the world, I just want your half.

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.3 Release Candidate Build 81 (1.3-RC4)

Post by Azhrei »

osman wrote:java.lang.NullPointerException
at net.rptools.maptool.client.ui.zone.ZoneRenderer.commitMoveSelectionSet(ZoneRenderer.java:446)
at net.rptools.maptool.client.tool.PointerTool.stopTokenDrag(PointerTool.java:203)
This is fixed in 1.3 Final (i.e. the next build).
warpoet wrote:Yeow! I love maptools and always check in to see if there's a new version available. I use it extensively in gaming nowadays.
Thanks. We like it, too. ;)
But build 81's link isn't on the main rptools page anymore--is that because of the latest issues encountered? :-o
Doh! Thanks for the note!

I had that new item set to expire on the 15th because I expected 1.3 Final to be out last Wednesday (it's been delayed). I went back and pushed the expiration of that news item to mid-Feb so it should show up for a while now. :)
edit: Awwww, the properties pane still doesn't size with the window it's in (using a mac).
Please define what you mean by "properties pane"? Do you mean the Campaign Properties dialog on the Property tab? Or the token editor dialog and its Properties tab? Or some place else?

It sounds like this is a bug that should be fixed prior to 1.3 Final.

Post Reply

Return to “Announcements”