Page 1 of 1

[1.4.1.7] Generate VBL Bug

Posted: Tue Dec 20, 2016 7:28 pm
by aliasmask
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.

Re: [1.4.1.7] Generate VBL Bug

Posted: Tue Dec 20, 2016 11:00 pm
by JamzTheMan
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" :mrgreen:

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.

Re: [1.4.1.7] Generate VBL Bug

Posted: Wed Dec 21, 2016 1:39 am
by aliasmask
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.

Re: [1.4.1.7] Generate VBL Bug

Posted: Wed Dec 21, 2016 4:21 pm
by JamzTheMan
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:
Transfer Token VBL to Map VBL

Code: Select all

[r: transferVBL(1)]
[r: finalVblData = "{'shape':'none'}"]
[r: setTokenVBL(finalVblData)] 
Edit VBL and transfer back to token:
Transfer Map VBL to Token VBL

Code: Select all

[r: transferVBL(0) ]

Re: [1.4.1.7] Generate VBL Bug

Posted: Wed Dec 21, 2016 9:00 pm
by MandyRae
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?

Re: [1.4.1.7] Generate VBL Bug

Posted: Wed Dec 21, 2016 9:49 pm
by aliasmask
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.
VBL object always seen.jpg
VBL object always seen.jpg (18.5 KiB) Viewed 1106 times
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.

Re: [1.4.1.7] Generate VBL Bug

Posted: Wed Dec 21, 2016 11:03 pm
by MandyRae
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 . . .

Re: [1.4.1.7] Generate VBL Bug

Posted: Wed Dec 21, 2016 11:57 pm
by aliasmask
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.

Re: [1.4.1.7] Generate VBL Bug

Posted: Thu Dec 22, 2016 12:41 am
by MandyRae
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.
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.

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 . . .

Re: [1.4.1.7] Generate VBL Bug

Posted: Thu Dec 22, 2016 3:35 am
by aliasmask
Ah, I was thinking it was an override or something rather than apart of the same feature.

Re: [1.4.1.7] Generate VBL Bug

Posted: Fri Dec 23, 2016 3:49 pm
by JamzTheMan
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.