[1.4.1.7] Generate VBL Bug
Moderators: dorpond, trevor, Azhrei
Forum rules
Posting now open to all registered forum users.
Posting now open to all registered forum users.
[1.4.1.7] Generate VBL Bug
When it generates the VBL it seems to be 1 pixel too high. I discovered this when trying to create VBL door. If the door goes to the bottom edge the vbl generated leaves a 1 pixel gap. When used as a door players can see through this gap.
My current fix is to just alter the image so it goes to the top edge and then generate the vbl.
My current fix is to just alter the image so it goes to the top edge and then generate the vbl.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
- JamzTheMan
- Great Wyrm
- Posts: 1872
- Joined: Mon May 10, 2010 12:59 pm
- Location: Chicagoland
- Contact:
Re: [1.4.1.7] Generate VBL Bug
Ahh, I see, you mean there's a 1 pixel shift? What are the image size and grid sizes? There could be a 1/2 pixel math issue or some such? I assume you've tried other graphics and gotten the same? If you want to post a test campaign, I'll test it out. It's always better to be working with the same graphics/settings for these cases (lesson learned testing VBL macro's with Wolph!).
I generally overlap my VBL anyway just to make sure (as you can't tell as the door vbl is going to overlay it). In other words I draw my VBL over the hallways, then place doors with VBL, then go back and erase the hallways, leaving "door jambs" aka "door jamz"
But ya, if it is truly off by 1 (and not a 53 pixel door resized to 50 pixel grid, .5 pixel rounding thing) I'll fix it.
I generally overlap my VBL anyway just to make sure (as you can't tell as the door vbl is going to overlay it). In other words I draw my VBL over the hallways, then place doors with VBL, then go back and erase the hallways, leaving "door jambs" aka "door jamz"
But ya, if it is truly off by 1 (and not a 53 pixel door resized to 50 pixel grid, .5 pixel rounding thing) I'll fix it.
-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
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
Re: [1.4.1.7] Generate VBL Bug
You can see it in these 2 images. Both are 100x100. The 1 px box doesn't have any VBL created on the top or bottom. The 3 px box only does 2 px on top and bottom shifted up. The VBL sensitivity doesn't seem to matter. Used 1 and 100, although I'm not sure what that number represent. So, yeah, it's not a shift but perhaps some rounding issue or something.
- Attachments
-
- test 3 px box.png (431 Bytes) Viewed 1154 times
-
- test 1 px box.png (419 Bytes) Viewed 1154 times
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
- JamzTheMan
- Great Wyrm
- Posts: 1872
- Joined: Mon May 10, 2010 12:59 pm
- Location: Chicagoland
- Contact:
Re: [1.4.1.7] Generate VBL Bug
Got it, thanks! And ya, was a truncation issue. A simple +1 and now we're grabbing that last row of pixels.
Thanks for the catch, I never noticed it because the doors I use were drawn horizontally so 1 pixel "thickness" never affected the doors as much as they do when drawn vertically.
Fixed. If you need a work around, these macros are good to keep/have:
Transfer (and clear) auto-generated vbl to normal VBL layer:
Edit VBL and transfer back to token:
Thanks for the catch, I never noticed it because the doors I use were drawn horizontally so 1 pixel "thickness" never affected the doors as much as they do when drawn vertically.
Fixed. If you need a work around, these macros are good to keep/have:
Transfer (and clear) auto-generated vbl to normal VBL layer:
Transfer Token VBL to Map VBL
Code: Select all
[r: transferVBL(1)]
[r: finalVblData = "{'shape':'none'}"]
[r: setTokenVBL(finalVblData)]
Transfer Map VBL to Token VBL
Code: Select all
[r: transferVBL(0) ]
-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
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
Re: [1.4.1.7] Generate VBL Bug
Not sure if this should be here because it's related, or it's own topic . . .
I noticed that when you have the always visible option enabled for a token with VBL, it jumps to a layer above the token . . . is there anyway to get it below the token?
I noticed that when you have the always visible option enabled for a token with VBL, it jumps to a layer above the token . . . is there anyway to get it below the token?
Re: [1.4.1.7] Generate VBL Bug
Well, is shows above the FOW if any part of token can be seen. I think that is by design. But it does have this effect.
The token above can see a sliver out one door and can see the doors below eventhough normal VBL should block the vision to see them.
The token above can see a sliver out one door and can see the doors below eventhough normal VBL should block the vision to see them.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: [1.4.1.7] Generate VBL Bug
The issue I am talking about is more apparent in this image.
The door token is on the background layer, yet when it is set to Always Visible it shows up above the token layer. After my previous post about this I realized that there's most likely no way to get around it, since I'm pretty certain the way it's set to always reveal has something to do with placing it above the FOW layer, which I believe is (was) the topmost layer . . .
The door token is on the background layer, yet when it is set to Always Visible it shows up above the token layer. After my previous post about this I realized that there's most likely no way to get around it, since I'm pretty certain the way it's set to always reveal has something to do with placing it above the FOW layer, which I believe is (was) the topmost layer . . .
- Attachments
-
- Untitled.png (190.56 KiB) Viewed 1129 times
Re: [1.4.1.7] Generate VBL Bug
As far as I can tell, the Visibility Tolerance doesn't work. I set it to 1 (only 1 zone needed to be seen) and it still doesn't show door.
- Attachments
-
- Visibility Tolerance example.jpg (28.38 KiB) Viewed 1127 times
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: [1.4.1.7] Generate VBL Bug
Did you check Always Visible? From what I gathered, they work in conjunction: each token is split into 9 regions, and if a number of regions equal to or above the number set in Visibility Tolerance is visible to a token with vision, then at that point is the token with VBL shown above the FOW.aliasmask wrote:As far as I can tell, the Visibility Tolerance doesn't work. I set it to 1 (only 1 zone needed to be seen) and it still doesn't show door.
I did play around with this, and it does conceal/reveal the token with VBL based on how much of it is visible, but keep in mind that it's going off the token image size, not the visible portion of the token . . .
- Attachments
-
- Untitled2.png (104.19 KiB) Viewed 1125 times
-
- Untitled3.png (103.51 KiB) Viewed 1125 times
Re: [1.4.1.7] Generate VBL Bug
Ah, I was thinking it was an override or something rather than apart of the same feature.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
- JamzTheMan
- Great Wyrm
- Posts: 1872
- Joined: Mon May 10, 2010 12:59 pm
- Location: Chicagoland
- Contact:
Re: [1.4.1.7] Generate VBL Bug
Mandy is correct, the "tolerance" is based on the whole token because of obvious reasons. So using double width doors just so they rotate on center can give issue. (I'm working on a method to rotate objects other than center so we can stop using that as a work around).
As far as overlaying on top of tokens, it's not so much as by design as it is what it is. There is a pretty long/complicated method that draws all objects layer by layer and then applies FoW. I had to put "Always Visible" tokens back onto the map AFTER FoW is draw so unfortunately they will overlay on top of anything else. It would have required a pretty big rewrite to do it any other way and I thought it was better to have it now as is then wait.
FYI: For PC tokens, it really doesn't hurt to check them as "Always Visible" and push them to the top. It gives an added benefit that players can always find there tokens even when blind or FoW isn't revealed or inside VBL or what ever. Although it may not be what you want and doesn't work well for NPC's in most cases. But I have used it on NPC tokens when they are on top of, say, a large object that has TokenVBL but I need the players to see the token still.
As far as overlaying on top of tokens, it's not so much as by design as it is what it is. There is a pretty long/complicated method that draws all objects layer by layer and then applies FoW. I had to put "Always Visible" tokens back onto the map AFTER FoW is draw so unfortunately they will overlay on top of anything else. It would have required a pretty big rewrite to do it any other way and I thought it was better to have it now as is then wait.
FYI: For PC tokens, it really doesn't hurt to check them as "Always Visible" and push them to the top. It gives an added benefit that players can always find there tokens even when blind or FoW isn't revealed or inside VBL or what ever. Although it may not be what you want and doesn't work well for NPC's in most cases. But I have used it on NPC tokens when they are on top of, say, a large object that has TokenVBL but I need the players to see the token still.
-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
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork