Add the ability to select and enable or disable VBL and MBL to support flying, levitation, and characters who climb to a higher elevation and thus have temporary, unimpeded vision over lower elevations.

[adventuremagic123]

Is your feature request related to a problem? Please describe. When a token is flying, I'd like to disable parts of my VBL and MBL that I consider are no longer blocking the token's view. If that token lands on the ground, again, then I'd like to re-enable that part of the VBL and MBL.

Describe the solution you'd like I'd like to be able to apply enable or disable to a region of VBL and MBL buy drawing a block-shaped or polygon-shaped selector that enables when I release my mouse button or finish drawing the polygon and does a disable if I also have the shift key pressed. A design something like that. Very similar to the controls used for drawing VBL and MBL.

Describe alternatives you've considered Currently, the only solution I have is to grab the flying token and whisk it around the map to let the player temporarily see what should be visible to the icon. It would take too long to erase the VBL and MBL when the token is flying and redraw the VBL and MBL when the token lands.

Additional context This request is different than issue #2003 (A type of VBL and MBL (I'm assuming MBL stands for "movement blocking layer) that has buttons to enable or disable it -- like for a door or window) because that feature is asking for a different kind of VBL and MBL where a continuous track that is selected by only clicking on part of it would be enabled or disabled, instead of selecting regions of VBL and MBL as I'm asking to be able to do here. Could this feature be used in place of #2003? Maybe. Can #2003 be used in place of #2004 -- no.

[bubblobill]

Elevation allows you to see over walls until someone puts a roof on the building. How would you deal with your guy being able to see through roofs and forest canopy? You can either see through everything in a given range, or you can't. Otherwise you will need to define VBL as 3D objects. A wall is a plane of length and height h, a building is a hollow box with except for the where the windows and doors and chimneys and battle damage are. A ruin is is a rectangular prism with height that varies along wall length.

The only viable means I see of doing this is to expose everything within vision range that is contiguous with the current area occupied by the token. That would use a fill algorithm which would be cheaper than line tracing.

[adventuremagic123]

Being able to selectively enable or disable VBL and MBL would enable me to disable the VBL and MBL at a particular elevation while leaving the VBL and MBL for buildings intact.

[JamzTheMan]

For now your best bet is to use TokenVBL.

For roofs and objects like that are more easy, as you just transfer the VBL to the roof token and then move the roof off the map/out of the way when needed (leave a second copy of the roof behind on another layer if needed). This could all be done via the UI (no macros needed).

For macro use, there are transferVBL as well as draw/erase vbl macros you could create that would grab the VBL as a JSON under a token (like a roof) and you can store it on the token. Then with another macro copy the JSON VBl info back to the token/vbl layer.

If this comes up often, I'd invest in creating a couple of generic macros for this. For one off situations, I'd do it via the UI.

You can also drag some random token to the map, size it for the area you want to remove, snapToGrid so you can easily put it back, transfer VBL to TokenVBL and then move that token.

Right now all VBL is one "object" after you draw it. Later it may become individual polygons and which may let us add UI elements to let you move corners/points and manipulate the VBL "areas" a little easier. It's on the road map but it's going to take us a little while to get there so in the meantime I provided some 'work arounds' above.

[bubblobill]

How hard would it be to implement additional VBL layers on Tokens or Maps that were additive? For instance; Tree VBL at elevation 0

          x

Tree VBL at elevation 20

     +----------+
     |          |
     +----------+

[cwisniew]

Extra layers (just just for MBL / VBL) is something I want to look at adding, but it will have to wait for the map renderer rewrite.

[JamzTheMan]

We would have add in an Elevation field the token. For "simple" rendering it would be doable, grab all token VBL where elevation == token elevation. But that's very simple rendering.

It wouldn't handle vision well for tokens at different elevations at angles, for instance token A at the base of the tree and token B at elevation 30 and 15' to the right of A, and token C at elevation 25 and 120' to the right of token A. For that you would really want/need 3D points and VBL.

Depends on how complicated you want things to get.

[bubblobill]

It's a map, not a virtual environment. I see no reason to go beyond simple rendering. An alternative occurred to me. This is not really any different to having people on different levels of a building. There are effective techniques for managing that already. It might be a better idea to look at ways of implementing those techniques natively instead of via macro.

[adventuremagic123]

I think what I've described would work with a variation of how VBL and MBL is erased. Instead of erasing the VBL or MBL, disabling it would cause the existing VBL or MBL to be replaced with a type of VBL or MBL (indicated by using dashed lines or different color lines) that would be ignored for vision in the case of VBL and movement in the case of MBL. Then, enabling it would be the reverse of this process, restoring the VBL or MBL.

[adventuremagic123]

I may have convoluted things. I'm trying to make suggestions for an implementation that would avoid potential issues with copying the design currently used in Foundry VTT with the "Wall Height" module.

What they do is allow a top and bottom dimension to be assigned to wall segments. The default for top is infinity. The default for bottom is -infinity. Tokens have an elevation property. If a token has an elevation that is equal to or greater than the top height or less than or equal to the bottom dimension of the wall segment, the token can see over it.

Further more, Foundry VTT has terrain wall segments that have the property where there must be two intervening wall segments to block a token's vision. I find this useful but might not be entirely necessary. Not sure.

What that enables you to do is to have terrain objects that can be seen -- but not seen past.

[adventuremagic123]

It's come to my attention that part of my request may have been miscommunicated. I think considering token height is too complex to try to implement as a first pass for this feature. Instead, the elevation for a character is considered while ignoring token height. As long as the elevation for a character is high enough or low enough, regardless of distance from the VBL, that character can see past the VBL. I recommend using this simple concept. Trying to get more complex is just too much for a first release -- and may be computationally prohibitive.

[adventuremagic123]

rgwynnjr#6467 notes that there's another Foundry module that might be a worthy enhancement:

https://foundryvtt.com/packages/levels

It seems to allow different layers to be used to provide multi-level maps. It's used in conjunction with the "Wall Height" module.

Levels _ Foundry Virtual Tabletop.pdf

[adventuremagic123]

This is the description for the "Wall Height" module used for Foundry. These are all just ideas but show proof of concept that these types of issues can be tackled by a VTT. There may be other ways. Point is, though, that this feature is badly needed to support outdoor adventures which have terrain of various elevations, trees that block views up to a certain height, flying characters, etc. It's almost as important as lighting and darkness.

Wall-Height.pdf

[adventuremagic123]

Here's the URL to how Foundry does walls:

https://foundryvtt.com/article/walls/