1.4.1.7 features and bugs

Developer discussion regarding MapTool 1.4

Moderators: dorpond, trevor, Azhrei

Forum rules
Posting now open to all registered forum users.
User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

1.4.1.7 features and bugs

Post by aliasmask »

I just downloaded and started to use this and I was wondering why my library images take so long to load? Will there be a function to propagate all my thumbs while I set aside some downtime?

Also, the Generate VBL tool is very awesome and I plan on doing a video to demonstrate. It works great, but the preview image with the VBL is offset so it doesn't line up (minor bug). I was hoping the movement would have been sped up with complicated vbl (caves). Any tips on my settings for generation. I left it on the defaults.

Anyway, about the slow down. I set vision for map to 60ft, FOW, Night, 1 light source carried. If I move 15ft, it takes around 22 seconds for it to reveal the movement. Although, I am moving the token, cancelling the movement then moving it 1 square at a time. If I change the vision to Day, then it only takes 6 seconds which is still a long time but far better than 22. I turned off my movement code so it just moves and it takes 5 seconds with night and light source and 2 seconds with vision day. I'm assuming because I move to each square with my code it essentially multiplies the time (5 original move, +15 to move 3 squares with vision set to night). I do have the only reveal FOW at way points.

User avatar
Jagged
Great Wyrm
Posts: 1306
Joined: Mon Sep 15, 2008 9:27 am
Location: Bristol, UK

Re: 1.4.1.7 features and bugs

Post by Jagged »

With regard to the library load speed, clicking one of the resource icons on the bottom right of the screen clears your image cache and speeds things up.

Can't remember which one ;)

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

Re: 1.4.1.7 features and bugs

Post by wolph42 »

with the vbl did you use the yellow or the blue (generated or drawn) vbl? I've noticed this issue too with the yellow vbl and discussed it with Jamz. His suggestion is to turn the yellow vbl into blue, which indeed speeds things up considerably.

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: 1.4.1.7 features and bugs

Post by aliasmask »

wolph42 wrote:with the vbl did you use the yellow or the blue (generated or drawn) vbl? I've noticed this issue too with the yellow vbl and discussed it with Jamz. His suggestion is to turn the yellow vbl into blue, which indeed speeds things up considerably.
How do you turn yellow in to blue? If you mean draw it manually, that kind of defeats the purpose. I had a detailed cave map and I used a filter to find the borders. This allowed me to clear the floors. I then created a 2nd image widening the paths to include part of the walls and then used the generate vbl tool. I then swapped the image back to original keeping the generated vbl. I did start tracing the walls manually, but found that to be very time consuming. I was also the duplicate the image and rotate it connecting the two cave structures together to gain a larger cave system.

Now if the problem is with the yellow vbl, a tool to drop it on to the map and turn it blue would be useful if that could speed things up. Also, I'm not sure what the sensitivity to transparency setting means. Will it not include colors from the color pallet starting with black or feather out from the transparency? Could someone demonstrate that and the Visibility Tolerance? I may mess with it to try and figure it out for myself. I have an inkling what it may be though, but not sure on its use.

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

Re: 1.4.1.7 features and bugs

Post by wolph42 »

I used a macro. I'll need some time to dig it up. So 'I'll be back'.

edit: this I use with ápply to selected tokens' turned on:

Code: Select all

[r: transferVBL(1) ]
[r: finalVblData = "{'shape':'none'}"]
[r:setTokenVBL(finalVblData)] 

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: 1.4.1.7 features and bugs

Post by JamzTheMan »

Hi AM. Wolf has you on the right path but to clear things up a bit...

The auto generated vbl sticks with the token, so its really useful and meant to use with objects that may move during play, eg doors, cars, etc. We have to calculate this vbl dynamically ẃhenever a token moves so it can be costly if over used.

So if you want to take advantage of the auto-generation, you can use macros to transfer the vbl to/from the vbl layer (remember to erase the old though!) This is useful for caves like you are doing but i also use it for statues/columns/barrels, etc.

Note, you can mark an object always visible without auto generating vbl and manually draw it.

As far as visibility tolerence, think of the object divided into 9 squares, ie tic tac toe. Other tokens need to see x squares of it before it is shown. So a statue or small object, you may want to set it to 4 or 5 so its not revealed until the pc can see the majority of the object. A larger object, like a building/rooftop, you will want to use a tolerance of 1 otherwise it may never show (the vbl or size of the roof may cause a token to never see more than 1 or 2 squares at a time). Generally the default 2 is fine for most applications...
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: 1.4.1.7 features and bugs

Post by aliasmask »

Thanks for the code and explanations.

I imagine the visibility tolerance is all or nothing for the object, but FOW will still hide areas not seen yet? For example, a building layout. If I'm on the outside of a building I'll be able to see the exterior walls, but not the interior until I actually enter the building?

One more question. If a token is invisible to a player, is the vbl invisible to that player? I know, that's a weird one.

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: 1.4.1.7 features and bugs

Post by JamzTheMan »

Visibility Tolerance only affects the "Always Visible" function. And it only affect the visibility of the token and does not affect any VBL that is drawn over it or stored on it (eg blue or yellow vbl).

Not sure what you mean by building layout? Like a blue print layout? Depending on the vbl, I suppose if you are "on" the token/stamp/building vbl could still restrict showing the token, if that's what you mean?

And no, VBL is always visible/used regardless of the tokens visibility.

That would be a wierd one but I don't think it would have many use cases that I can think of?. Although, I suppose a door/wall could be set as invisible to a player via x-ray vision or such and so you would want the vbl to go away as well. But you could also macro/move the object with vbl to obtain the same results?
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

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

Re: 1.4.1.7 features and bugs

Post by wolph42 »

building layout: that depends on the application of the VBL. You can see INSIDE it but NOT BEYOND it. So if you draw yellow vbl wall then you can see the wall, but not what's beyond. If however you draw a yellow vbl square over the entire building then you can see the entire building.

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: 1.4.1.7 features and bugs

Post by JamzTheMan »

FYI, for building layouts, what I would do usually is, draw the VBL for the exterior/interior walls of the building with doors and all that. I would then place a roof object over it. Now, the interior walls is going to cause the roof to only be partially (and wierdly) shown, so you click the Always Visible option on the roof and bam! You could also store VBL on the roof to block vision, but the exterior walls should handle that for you.

So as the pc walks down the street, he will see all the roofs/buildings and only see between the buildings. As they enter, you just move the roof away.

Also note, Always Visible objects are drawn "Last" regardless of layer, so they always show up over other tokens, drawing, etc. It had to go after VBL was handled so there wasn't a way to do it without a complete rewrite.

BTW, you can set PC tokens to "Always Visible" as well and that helps them from getting lost under roofs, darkness, or other such things...
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: 1.4.1.7 features and bugs

Post by aliasmask »

JamzTheMan wrote:That would be a wierd one but I don't think it would have many use cases that I can think of?. Although, I suppose a door/wall could be set as invisible to a player via x-ray vision or such and so you would want the vbl to go away as well. But you could also macro/move the object with vbl to obtain the same results?
Yeah, that's what I thought. I was thinking of vbl stacking like with different floors of a building, but as you said, it could just be moved with a macro.

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: 1.4.1.7 features and bugs

Post by aliasmask »

wolph42 wrote:I used a macro. I'll need some time to dig it up. So 'I'll be back'.

edit: this I use with ápply to selected tokens' turned on:

Code: Select all

[r: transferVBL(1) ]
[r: finalVblData = "{'shape':'none'}"]
[r:setTokenVBL(finalVblData)] 
Thanks. Code worked like a charm. It's odd that I couldn't run in chat as gm, so I just put as a macro on image.

As far as speed, it went from 5 seconds to 4 seconds, so it is an improvement but not as much as I was hoping for.

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: 1.4.1.7 features and bugs

Post by JamzTheMan »

aliasmask wrote:
wolph42 wrote:I used a macro. I'll need some time to dig it up. So 'I'll be back'.

edit: this I use with ápply to selected tokens' turned on:

Code: Select all

[r: transferVBL(1) ]
[r: finalVblData = "{'shape':'none'}"]
[r:setTokenVBL(finalVblData)] 
Thanks. Code worked like a charm. It's odd that I couldn't run in chat as gm, so I just put as a macro on image.

As far as speed, it went from 5 seconds to 4 seconds, so it is an improvement but not as much as I was hoping for.
Feel free to post the map. And also understand, depending on the graphics, it can be a pixelated VBL and if it's a whole map of it, maybe it's just to complicated of vbl?
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: 1.4.1.7 features and bugs

Post by aliasmask »

JamzTheMan wrote:Feel free to post the map. And also understand, depending on the graphics, it can be a pixelated VBL and if it's a whole map of it, maybe it's just to complicated of vbl?
I did notice, if I didn't have a server running it only took 2 seconds to move a token, but with the server running (all checkboxes checked with no other connections) it takes 4.
Attachments
Silver Mine.rpmap
(6.08 MiB) Downloaded 59 times

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: 1.4.1.7 features and bugs

Post by JamzTheMan »

Ok, well, I can see why you didn't want to draw that manually... :) And as I suspected, it's pretty pixelated so you probably have 10's of thousands of right angles to process. Unfortunately, MT isn't smart enough to properly slice and render the map and basically has to process vision for all the tokens when a light source changes and all that so the more VBL you have on the map the worse it gets.


Now, with that said, with a server started, moving a token 40ft, I was able to get it down to less than 1 second. The trick was I had to remove the VBL for 2 of the maps... So you have a few options.

1. Redraw all the VBL by hand (yuck! And no idea on what the performance gain will end up being)

2. Put each map on a different MT Map and use teleporters (or transfer manually), not the most graceful but depends on how the maps hook up, I saw ladders so it may make sense they can't see the next map?

3. Create a few macros and dynamically generate/remove the VBL as needed.


Personally I'd go with #3. I did a quick test and using auto-generated vbl on the token performed just fine (for 1 map). Which makes sense, it's only grabbing 1-3 "Areas" of vbl at a time. In my test, performance degrades when the # of objects approaches a 50+ tokens.

PS I noticed the one map was off centered in the layout panel, restoring it made the token VBL show properly. Looks like we got a bug in the "preview" window for token vbl not handling anchor points properly. It's only a preview window bug and doesn't affect the actual VBL used...

So using auto-generated VBL, I'd store those tokens (maps) on a different map, and use a macro to move said map token to/from storage. As the players approach the new map, bring it over (performance degrades a bit) and once on the new map remove the old. It's pretty quick as you are just moving tokens (although you could store generated VBL on a token and draw/erase vbl using that, i think the other approach is cleaner).
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

Post Reply

Return to “MapTool 1.4”