Add two-way VBL/terrain walls #2755
Comments
|
A few things which you can try here:
|
|
I've typically gone with the first method, although the second method does seem rather appealing now that you mention it. Nevertheless, I believe that terrain VBL (and perhaps more advanced VBL in general, although that's a separate topic) could be useful to most users. |
|
Well, nevermind. According to Craig's message, the codebase is too tightly coupled with Swing to make this possible. Plus, no one wants to work on the Swing code anyway, least of all me! If anything, this just made me a firm supporter of the web-based client. Closing this issue now. |
|
In my opinion, this should be reopened. Just because we're not doing it today doesn't mean we're not doing it. :) |
|
I think so too. |
|
I agree |
|
I made a proof-of-concept for terrain VBL on this branch. The defining feature of this implementation is that vision can "enter" terrain VBL but can't "leave" it. It is by no means complete as it just treats all VBL as terrain VBL. A few more things would need to be done to get this fully and properly implemented:
I also haven't spent any time optimizing the implementation, so performance isn't great in some situations. But it is plenty usable in simple cases. |
Welcome to the Hotel California...
This is where being able to select VBL and modify its attributes would come in handy as well, but that is probably more of a pipe dream for phase 2 or 3 of this. But if you are looking at storing these VBL types separately and need to make some changes to how its stored then its worth keeping this in mind.
Since the VBL macro functions accept their arguments as a "JSON" string it will be easy enough to add this as a parameter so new functions would not needed.
I think that it would be desired as that would allow people to see more of the token doing the blocking. It would probably make sense for token VBL to be this new see into but not out of type by default too. Although I that can wait as its worth getting the rest in even without that as a first step.
What sorts of situations does performance suffer? |
|
Here is an example I simpified: On 1.9.3, dragging and dropping the token anywhere is a snappy operation. But on my feature branch there is a noticable though small delay when dropping. I'm also now realizing the delay is there whether or not I have terrain VBL enabled, so this is probably just due to some poor handling of geometry on my part. |
|
I've udpated the toolbar with a toggle for terrain VBL vs regular VBL. The icons are reused from another toggle as creating new icons is beyond my skill set. Terrain VBL is stored separately from regular VBL and has its own associated topology trees used for FoW calculations. Each island in the topology tree also stores a flag for whether it is terrain VBL or regular VBL, and FogUtil uses this flag to determine its behaviour. This way, if we somehow change it to a single topology tree for both kinds of VBL, FogUtil will continue to work with minimal changes to I also spent some time on performance and found that I was using JTS quite suboptimally. That's been fixed, thankfully wasn't too hard. Next steps are updating the VBL functions, adding token terrain VBL, and updating pathfinding to account for terrain VBL. Here's what it looks like right now. There's the new toggle button. When selected, terrain VBL can be drawn and erased: |
|
My first take on token terrain VBL is implemented. I decided to have tokens only have either regular VBL or terrain VBL. Or rather, that the token itself should either count or not count as terrain when it comes to VBL. New tokens will default to being terrain, while existing tokens (including existing imports) will not be counted as terrain. This is controlled by a checkbox in the VBL tab of the Edit Token dialog. If this is undesirable, I can separate regular VBL from terrain VBL at the cost of some more code duplication. And for a showcase, here's a simple room with a pillar and a rock acting as terrain. Please mentally fill in something fancier. Macro functions for token and non-token terrain VBL are yet to come. If anyone wants to try it out, my feature branch is up-to-date with everything I've showcased so far. |
|
Support for terrain VBL has been added to macro functions now. And with that, I think it is complete in terms of functionality, though there are still some loose ends to take care of. I've opened a draft PR for some better visibility into the changes and to accept some early feedback. There are a few specific questions I have at this point:
|
|
I've managed to answer some of my own questions after actually trying to use the features for a while.
|
I think it needs a better name as when I read "Terrain VBL" I am certainly not thinking about using it for nice walls/doors as newish user... But I am not sure what name "see into VBL" sounds even more terrible. One Way VBL? Single Direction VBL?
It sounds like that is probably the best way of doing it as it sounds like it would be less painful to jump between the two
|
Not walls/doors, but perhaps pillars and other obstacles. Which is really what it is for. There are real downsides to using terrain VBL for walls (at least interior walls) as players can see down the entire length of any such wall. VBL generally remains the best tool for interior walls. Here's my attempt at brainstorming some other names:
I'm kind of partial to something like "perceivable VBL", but not sure how to make that sound more natural. |
|
I'm partial to "One Way VBL", as it's the most descriptive (although not really accurate, since if you're on the other side of it, you can see out — it's not really "one way" in that regard. (Unless you think driving the wrong way on a one way street is okay because you're only going "one way". 😉) I'm also a little concerned about picking a name that implies how it should be used. For example, 1WVBL is no good for a large hill. As you point out, it's really for smaller objects, such as pillars, columns, or items in which the GM wants the players to see the great art work involved, but which should otherwise be considered solid. I'm also wondering about tokens placed next to 1WVBL — can the artwork of the token pierce the solid VBL? If so, a player could see into a pillar and tell there's another token on the other side. |
Yes it can: |
Phergus
added
documentation needed
|
I can't believe this feature is sneaking in under the radar... this has been desired for a very long time!
I personally quite dislike the selector as it is now... and adding more toggle states to it makes me cringe. I actually like the above suggestion since MBL isn't vision related at all. It is its own thing and I think it should be treated as such. I'm actually cool with Terrain VBL, but it's not entirely accurate (I just don't see characters and monsters as being "terrain".) 1-way/2-way VBL, brings up syntax debates. i.e. :
Reciprocal VBL seems too technical. But I think "Hollow VBL" is decent. As in having the VBL toggle be : Off/Solid/Hollow. |
|
Merged PR #2976 into feature branch Running from the branch and I don't see the new toggle button. Haven't investigated further. |
I've changed it to use the existing VBL/MBL toggle. So it's now a 5-state instead of 3-state button. |
|
An interesting possibility has been brought up in Discord. Right now, vision can "enter" TVBL but can never "exit" TVBL. The suggestion is to change TVBL so that:
Or, to put it another way, vision would be able to cross a TVBL boundary once but not two or more times. So the question is: should we modify TVBL to behave this way, or should we keep it as-is? I'm partial to changing it, but both behaviours are desirable for different reasons. |
|
As you said both are desirable, standing on top of a house vs standing in large pit, one you expect to be able to see beyond the VBL, the other you don't expect to be able to see beyond the VBL. Barring adding elevation into the mix, what is required is an "inside out terrain VBL" -- yes I am completely aware that name sucks. @kwvanderlinde how easy is it to add a "see out" attribute to the current terrain VBL so that it can act either way? |
Well, it's relatively easy to add yet one more topology mode. It would basically be duplicating most of the internal changes already made for TVBL and adding yet another toggle to the UI. The algorithm in The problem adding attributes to topology is that topology is that it's flat, i.e., it doesn't come in discrete, well-defined and easily manipulated chunks. Instead each point on the map is either covered by a given topology or it isn't. So as far as I can see it's not really feasible to simply tag a piece of topology as behaving one way or another. That would require some higher level of control. |
If its relatively simple then this might be the best solution as I am sure no matter which option you chose it wont take someone very long to ask how they get it to do the other one :) For the buttons we could have something like the following for the 3 types of VBL This way the icons represent things people would be familiar with and hopefully then "what is terrain VBL" would need less explaining. I am sure someone on discord will be able to produce something that looks way nicer than my ASCII art :)
Yeah this sounds a lot more complicated, something that is desirable in the future but out of reach in the short term. |
|
I was wondering if selecting a Terrain VBL shape and changing the "mode" of that shape would work. You could use a pattern to differentiate it. I meant to mock up how it might look but got busy. The downside is you need a selection capability and you wouldn't be able to overlap the types. Maybe that's a good thing though if you don't want to define overlapping terrain vbl and "inside out" vbl. Am I understanding that "inside out" is like looking over a pit, you can see in and over it when outside the shape, but if you are in it you can't see outside? |
|
@cwisniew I like your breakdown of the options. I also wouldn't mind using the terms pit and hill as it gives a concrete idea of how to use them. And I would say that seeing across a pit, not just into it, makes sense. Also, using the term "wall" for regular VBL might disuade using these new VBL options for things like walls where they aren't generally useful. For comparison, the current implementation is like pit-combined-with-hill in the most restrictive way. I.e., it's like a pit in that one can see into it but not out of it, but it's also like a hill in that you into it but not across it. And (assuming my brain isn't failing due to lack of coffee), a nice property of your breakdown is that the current behaviour could still be achieved by overlapping pit VBL and hill VBL. In terms of implementation, it's almost trivial to modify the current TVBL into "hill VBL". "Pit VBL" would be easily added as an analogue - I think it's case work is actually simpler yet than with hill VBL. |
|
I like where this is going and also the terminology. However I think that he current TVBL is NOT 'hill VBL'. TVBL is something you can look into but not beyond. 'Hill VBL' is something you can stand inside off and look out of. Now they do sound similar but im not entirely sure they are, so it would be good to do some mental exercises. That said, here's a wrench to throw into the system: there's also the use case of the cliff (similar to hill but just a bit different) which basically employs one way VBL, that is (assuming higher ground is left, lower right) you can look from left to right, but you can't look beyond the VBL from right to left. Other application would be one way mirror. To put it differently OWVBL achieves the same as the 'advanced' TVBL, but is only 1 VBL type and it has more use cases (e.g. with cliffs and one way mirror). Main reason for making this point is that (assuming that TVBL could be used for hill/pit) adjusting the current TVBL might be an easy win as the implementation is fairly simple, in the long run we would be shooting ourselves in the foot as there's a better alternative...but then we either have incompatibility issues or yaVBLt. O and before I forget: TVBL should be area only (so no 'hollow shapes') and OWVBL should be lines only (so no 'filled shapes') |
|
Completing the truth table of VBLs based on the three identified characteristics: See Into - the map and any normally visible objects or tokens inside of the VBL polygon can be seen.
How many VBL types do we really want? The current Terrain VBL has a definite and common use case that is currently covered by a combination of Token VBL with Visible Over FoW and is not the same as the Hill type. |
|
Ill have to disagree with that. OWVBL is not covered by any of those types. V3 somewhat emulates it but its definitively something different. But thats beside the point. You are right in asking how many is enough. If we look at our biggest competitor (FVTT) they have everything that MT currently has + OWVBL. (So VBL, MBL, TVBL and OWVBL) they structured it completely different but thats what it boils down to. So in that regard I'm inclined to say: those 3 types (MBL is not a vision type). else have a look at this: https://www.encounterlibrary.com/guides/adding-walls-doors-and-windows-foundry-vtt/ |
Disagree with what? I didn't say anything about your notion of OWVBL because it's not likely to happen with the current VBL system. VBL has no way to denote blocking direction. Read Kenneth's comments from above:
|
I disagreed with that your table covers all VBL situations. But you never claimed that to begin with so.... moot point.
I have to say that I read that part before but simply didn't understand it and did not make the connection to this specific part of the conversation. So if I understand correctly, adding the "see out" and "see over" VBL is relatively simple. Adding actual OWVBL is not. Hence for the short term we could decide to add those 2 variants but stay away from OWVBL. Does that sum it up correctly? And then the next question would be: do we want all those options? |
I don't want to put words in Kenneth's mouth but from my understanding of how VBL is implemented and from what he said I believe those are a true statements.
Yes but...
That's the important question. My opinion is that we definitely don't want all of those types of VBL but is 3 or maybe 4 enough? Say we go with 3 while replacing Terrain with Hill:
Hill is mostly a substitute for Terrain but if it was used on a big rock or tree a token could be moved/dropped into the Hill VBL area and see out in all directions whereas the intent would have been to have the rock/tree image be visible but blocking LOS. Something within it should be blind which we don't want for a Hill. Pit VBL only kinda sorta works for pits. You can't see the bottom of a pit nor what's in the pit unless you are standing right at the edge looking down. It does pretty good for shallow depressions however. Visually the V2 (Deep Pit) would be cooler as the FoW for it wouldn't be cleared until a token was actually in the area or manually cleared by the GM. But this brings up a bit of an issue with the 2nd characteristic of It all sounds so simple until you start looking at all the cases. |
|
I think we should go with Terrain, Pit, Hill for now. Give users a chance to use it and our intrepid macro writers an opportunity to see what corner cases they might be able to address with the new capabilities should the needs arise. If Melek can make lib:elevation do what it does we just can't underestimate what the possibilities may be once this is in the wild. On a tangent... Since I do not fully understand the underlying structure, it's hard to address this next point... but as I understand it, VB is really just a (potentially) complex shape. And once you connect two pieces, it becomes one shape which complicates all the options above immensely. Thus it seems to me that if the full boundaries (as it were) are going to be pushed, we need better segmentation so various planes of any shape can perform differently than other planes (maybe even be able to add vision and/or property related interactions to individual planes instead of relying on the shape to determine a universal behaviour.) So the question I'm wondering is whether there just needs to be a second, more segmented type of VBL available eventually if we really want to get further into the rabbit hole than this? |
This is accurate. It's a bit of case work, but wouldn't require revamping the VBL system. True OWVBL, on the other hand, would be quite different.
The only thing to add to this is that Pit overlaid with Hill gives the current TVBL behaviour (i.e.,
Assuming by "pit" you mean what you called a "Deep Pit", yes that is accurate (note that |
This is interesting... overlaying types to get different results... this seems like it could be... "interesting." But it begs the question managing different, overlapping VBL. It's sounding more and more like we might need a VBL Explorer (similar to the Draw Explorer.) |
ok makes sense. and do you also agree that we then should remove the 'line/hollow' vbl from the TVBL? As they have not function and are only confusing leading to people using it wrong and not understanding why it does not work...
I don't think thats what he meant. there will be two types in the end hill and pit each with their own 'quirks'. |
|
@kwvanderlinde agree with everything you said. I mostly brought up the The one case that seems to be in demand still would be VBL with |
or a cliff! |
|
I think I was one of the people that suggested how terrain vbl's combination of behaviors could simulate different kinds of terrain. I've created a use case scenario in pictures, my example has 4 use cases for terrain:
Here is my scenario in images 1.11.0a3 setup with current TerrainVBL: Rogue's view: Allied view: Enemy views: To implement the UI, I think selecting contiguous shapes and having a drop down in the toolbar to select their behavior would work. Then a pattern or special stroke on the shape perimeter that is different opacity could differentiate it, and selecting out would reveal the type in the toolbar selector. When nothing is selected, the toolbar selector could set which kind of terrain behavior you are drawing, and if you join shapes the currently selected terrain type of assigned to the new shape. If stroke decorations are possible, I think paper-map like conventions could work:
Whatever is done, I wouldn't expect any of this until a user interface is created where it can be differentiated without a bunch of additional colors, likely in 1.12+. I'll note the potential is huge if you could set elevation like priorities on shapes and overlap them to create topographic style maps with terrain vbl - but that is a tantalizing idea, not a serious suggestion (yet). |
|
With new changes the current code has issues opening up older campaign files (pre terrain VBL) presenting a "Could not load campaign" error message even though the maps are loading. Switching maps brings up: Example campaign from 7/4/21: |
|
Yep, I forgot to test that after refactoring. Should be simple to fix, I'll put up a PR today. The problem is that I've used the same field name for something that is structurally different. |
|
No additional issues reported during alpha testing. Closing. |
Is your feature request related to a problem? Please describe.
When setting up new maps with Fog of War enabled, I am always forced to choose between obscuring the art of the walls with accurate VBL, or creating VBL that approximates what should be there, while showing as much of the actual walls as possible. Also, I have to put an X across objects such as pillars or tall boxes, which gets the job done, but looks ugly.
Describe the solution you'd like
Terrain walls, straight out of Foundry.
Describe alternatives you've considered
Additional context
Let's say I have my test subject Agatha the hag standing in the Yawning Portal, looking towards the bar wall.
In the GM view, I can see the wooden wall that blocks her vision. However, in the player view, the wall is simply a fog-colored rectangle:
I would rather she (and by extension, my players) be able to see the nice wall art underneath.
Additionally, on a map such as this one
it's rather difficult to place VBL that is accurate to the map. but also reveals what's back there (specifically, the place where the outer wall merges with the inner wall).
The text was updated successfully, but these errors were encountered: