MapTool 1.3 Development Build 55

[trevor]

The "I know I'm going to regret doing a build this late with untested features" build

Since my taxes were done months ago, I can spend tonight working on MT !

Here's what's new:

Build 55 (4/15/09)
* Optimization: clear out erased drawables when loading a campaign
* Spanish translation update (Contributed by Patricio)
* Fix bug: double clicking a token in the initpanel should center on selected token
* Fix bug: memory issues when saving a campaign with lots of drawables
* OSX menu bar and hot key integration (Contributed by Craig Courtney)
* Conic and square vision (Contributed by jfrazierjr and Mrugnak)
* Optimization: cache label rendering (Contributed by Derek Dohler)
* Fix bug: player password not working when connecting to server (Contributed by derek dohler)
* Spanish translation update (Contributed by Patricio)
* Confirm dialog when deleting tokens (Contributed by Mark Basham)
* Fix bug: multiple disconnected colored lights are not always trumped by bright light
* Fix bug: initiative panel can throw an error when a token is deleted from the map
* Show vision as the selected tokens see it

Contributed by applekor
*Clear Group and Clear Panel popup menu options now prompt for confirmation before execution.
*Internationalization support has been added to the macro button editor dialog. Only English has been added to the resource files. Volunteers are welcome to translate to other languages.
*Internationalization support has been added to the Selection panel menu button tool tips. Only English has been added to the resource files. Volunteers are welcome to translate to other languages.

Contributed by Craig W
* added options to output to self and gm as well as a list of players to macro links.
* added getCurrentMapName() function
* added getMapNames() function (trusted)
* added getVisibleMapNames() function to get player visible map names
* added second optional argument to getTokenStates() which specifies group of stated to get.
* added execLink() function (trusted) to execute macro links passed to it.
* fixed bug with getGMName() and setGMName() returning wrong error mesage.
* fixed bug where names in form with method=json contained html escape sequences.
* fixed bug where clicking on an input image would only return x,y and not form values
* fixed bug where using moveTokenToMap(), moveTokenFromMap() to/from the map the token is on loses the token.
* fixed bug removed spurious \n characters from macro output.
* fixed bug where some of the slash commands were double reporting errors.
* exception stack traces that were caused as a result of macros/slash commands that were being dumped to the console are now sent to log file. Not all of them just those that are caused by non checked errors.
* String extraction for internationalization for slash commands errors and output.
* Fixed for loop off by 1 error that some times occur when step size != 1
* Right click -> macros menu on token stack and init panel now runs macro against token that was clicked on.
* Token movement/copying functions now do not force "snap to grid" when using the distance values (cell based movement still snaps to the grid).
* Fixed bug when moving tokens to maps with different grid size/type when using moveTokenToMap/moveTokenFromMap


Please post clarification discussion directly to this thread, and bug reports to the MapTool->Bug Reports forum

I fully expect bugs in this one, I put in a couple last minute changes that haven't been tested, and doing a build at 1:45a, so I'm sure something will break.

Have no fear ! we'll do another build if anything critical comes up

Thanks again to everyone who contributed patches

[DJuego]

I must admit this build (1.3b55) has been the most desired by me in two years. Now I just feel so empty... and happy!

DJuego

[simonutp]

I played with low-light and dark vision with a colored light and I was VERY pleased to see that low light vision works like a charm : when a low light vision token is selected the colored lights areas are properly doubled, and when a normal vision one is selected it comes back to normal areas, GREAT!
Unfortunately, dark vision still erases the colored light areas...
BUT selecting a normal vision (or even low-light vision) token draws back correct colored lights THAT is a great improvement.
I tried to make screen shots but it all shows the same erased-by-drakvision situation even if it not the case on my screen !!

Keep the good work Trevor, one more step and we old dd3.5 users will have our dreams come true...

[dorpond]

Great work with the new 'select vision', Trevor!

Couple Notes:
1. When the background or NPC's are selected (assuming NPC's remain at their default 'Has Sight = off'), I would suggest that light be represented in Normal perspective, instead of Lowlight. The reason is simple - we DM's have normal vision and we want to be able to see the light sources on the map in a normal perspective. Lowlight is a 'special' vision and trust me when I say this, we DM's don't want to see the map as an elf when we are moving our monsters around. If we wanted them to see as an elf, we would simply assign Lowlight to them and enable "has sight', but if Has Sight is off, then the GM should see light as true light.

2. You told me yesterday that you thought the select method felt a bit odd to you when you were testing it. I am actually the opposite, in that this feels very comfortable and just as I would expect it to operate when trying to GM groups with multiple visions. Nice job!

3. Color bright light is still wonky it seems. I know you didn't address this but I am starting to wonder if we should somehow make it so that users cannot assign color to (both at the same time) bright and shadowy just so we can get one step closer to 1.3 final. I personally am OK with bright having no color and shadowy having color. Just thinking outloud I guess.

Great job Trevor! Man, this is finally allowing a GM to manage the game better for D&D 3.x. I am excited for the D&D 3.x crowd. One step closer to final *wipes brow*

[dorpond]

I think there is something weird going on.

1. Place an NPC on the left side of the map and place a PC on the right side of the map.
2. Give them both a light source -d20 torch for example.
3. Set the map to Night mode.

Note: Notice that the light sources are dark.

4. Turn on FOW
5. Expose the player token.
6. Select the NPC token and select Has Sight.
7. Expose NPC vision.
8. Walk NPC around an expose a larger area.
9. Walk PC around an expose large area.

Note: This also shows how the light displays as dark in the soft fog.

I attached a campaign file showing the above.

[Azinctus]

Great job Trevor! Man, this is finally allowing a GM to manage the game better for D&D 3.x. I am excited for the D&D 3.x crowd. One step closer to final *wipes brow*

And for the GURPS players too. I've tried out conic vision and it works a treat, the new "see as selected token" effect is a godsend and since Trevor sent it...

[trevor]

My 1am brain had forgotten about the dark vision issue. That should be a pretty straightforward fix so will definitely be in b56.

Bright colored light should also be pretty easy to fix.

I think these are the last of the critical fixes for 1.3. If there isn't a need for a critical build, I'll plan the next build for next week.

[jfrazierjr]

Trevor, we might want to add the same type of code that was added to FacingTool to the CampaignPropertiesDialog to enumerate each token if expose vision is turned on. Right now, if a GM adds or modifies a vision source, the fog is not exposed when they click the ok button. Let me know if you want me to build up a patch for that or if we want to call that expected behavior....

[trevor]

Yeah, go ahead and attack that one and I'll work on colored light

[jfrazierjr]

Yeah, go ahead and attack that one and I'll work on colored light

Ok.. will do tonight hopefully... a few quick questions though. I assume in addition to the existing check for the autoshow flag, as I enumerate the tokens on the map, I want to check for things like isPC, isVisible, hasVision, etc and only call expose in the right situations. Are there any other checks(ie, what verifications should I do) I should make to keep from exposing something the clients may not need to see?

[dorpond]

I have a question for the community:

Thinking in a D&D3 perspective, do you think that when a human explores and the GM is exposing FOW for that human, that the exposing should be for the human eyes, or for the Elf in the party who has lowlight?

I am trying to imagine the character with lowlight in the party. Every time the GM exposes something for the human, I am imagining that the Elf player will be like "OK, what do I see now?" and the GM will have to then click on the elf and expose for him too. The GM will have to be jumping back and forth - exposing for the human and then for the elf. Might get old fast.

I am not really sure how this should be handled.

On the same hand, I cannot see a human exploring and seeing much more of the map exposing because there happens to be an elf in the party..

Any ideas how we should handle this in 1.3?

There is actually one fix for this but it but I am afraid it probably wouldn't make it for 1.3 - different hard FOG for each player. This way when the human explores, the hard fog only exposes to his eyes. The elf would gets a totally different exposure. Some day.

[trevor]

different hard FOG for each player.

Definitely not for 1.3

[jfrazierjr]

Dorpond, when you get a few minutes,could you play around with the Vision stuff and how that might relate to your questions? I have no idea at this point how the multiplier might work with specifically set vision ranges in conjunction with light being on.

[dorpond]

I think the best way to approach this jfrazierjr, is to test each game system, one at a time. We have so many different lighting and vision settings available that if we try to make them all work together happily, we will go bonkers in the process.

I am going to test D&D3 and D&D4 rules and report back for them.

When it comes to the other game systems I would hope that others will report back on what they experience, mainly because I am not familiar with those rules.

Hopefully after testing and tweeking, we can at least have it 'good enough' and move on to 1.4.

[jfrazierjr]

I think the best way to approach this jfrazierjr, is to test each game system, one at a time. We have so many different lighting and vision settings available that if we try to make them all work together happily, we will go bonkers in the process.

I am going to test D&D3 and D&D4 rules and report back for them.

When it comes to the other game systems I would hope that others will report back on what they experience, mainly because I am not familiar with those rules.

Hopefully after testing and tweeking, we can at least have it 'good enough' and move on to 1.4.

I had a few minutes and did a quick test and so far it looks good... Note that distance=x in the Vision settings are THE hard limit, so the multiplier does nothing to override that.

I set up two visions -
Square 10: square distance=10.5
Square 10 + Lowlight: square distance=10.5 x2

Light -
Special - 5 : square 5.50#000000

Fired up two instances of Maptool and started a server. I added a second token(PC) to be the light source and a third token as a NPC, and then the original token I changed his vision around a few times. As I moved around the lowlight seemed to work great and limited my vision as I would expect. As a check, I also modified the square 10 + lowlight to have a distance of 30 instead of 10 and the lighting was still the normal lightsource range * 2 as expect... yea!!!!