[Bug]: Hill VBL doesn't block the 2nd occurrence of itself

[kwvanderlinde]

Describe the Bug

A token inside Hill VBL will never have its vision blocked by that region, even if it "wraps around" to show up a second time in the token's line of sight. This makes it impossible to do local reasoning about Hill VBL's effects - bits that extend off-screen might happen to connect with each other, completely changing the behaviour. Especially now with the addition of Cover VBL (which is much better defined), Hill VBL stands out as the only unpredictable VBL type.

To Reproduce

1. Draw two parallel rectangles of Hill VBL.
2. Place a PC token with vision on one of the rectangles. Notice that vision is blocked by the back side of the other rectangle.
3. Draw thin line of Hill VBL to connect the rectangles by a corner.
4. Now notice that the PC's vision is not blocked at all.

Expected Behaviour

When a token is inside a region of Hill VBL, the token's vision should be blocked by the back side of that region, as long as vision would have already passed outside of the Hill VBL to get there. Or to put it another way, if a line-of-sight had to enter Hill VBL, it should be blocked when it tries to exit the other side.

Screenshots

This is the first case in the reproduction steps:

And this is the second case (no blocked vision):

If we imagine we were zoomed in just a little, the scenarios would look identical in setup but not in behaviour.

MapTool Info

1.14.1, all versions that have Hill VBL

Desktop

Linux Mint 21.2

Additional Context

The current behaviour is due to technical limitations. We didn't have a way to "count" the number of crossings, so all we could do is check which Hill VBL regions a token is in or next to, and try to act as reasonably as possible. Hill VBL is unique in this regard as it is the only VBL type that can't be defined purely in terms of boundary orientation, but also needs to be able to ignore certain boundary segments in certain cases.

[thelsing]

I'm not sure if I would see this a bug. IMO If I'm on the hill this hill shouldn't block my sight, regardless how complicated it is.

This is more a symptom of the quite complicated new vbl types. Maybe it would be better to get rid of them and implement proper elevations. Maybe we could assign elevation levels to vbl areas and use them to calculate visibility?

[ColdAnkles]

Is there appetite for a more complex elevation implementation? I have thoughts.

[FullBleed]

Maybe it would be better to get rid of them and implement proper elevations. Maybe we could assign elevation levels to vbl areas and use them to calculate visibility?

I don't think we get rid of what we have because they're good for "uncomplicated" setups, but the idea of elevation VBL sounds very interesting because it opens doors for more complex maps.. But, once you open that door, you should consider vision type VBL, too. So, would one single type of Custom/Configurable VBL be sufficient?

[ColdAnkles]

I'd leave the existing VBL options alone, and usable for maps where users choose to not enable the elevation controls.

[bubblobill]

I have seen this "quirk" used to advantage. See https://discord.com/channels/296230822262865920/296657960720007169/961399117681131560

[ColdAnkles]

The addition of Cover VBL should mitigate that one use case at least.

[bubblobill]

Question: Imagine your two blocks are trenches, i.e. Pit VB, does the same thing happen?

[bubblobill]

We should probably define vision blocking using something like this as a reference

[kwvanderlinde]

Question: Imagine your two blocks are trenches, i.e. Pit VB, does the same thing happen?

Doesn't apply to Pit VBL. Vision can't leave Pit VBL so there's no way for a line-of-sight to encounter the second trench.

[bubblobill]

@kwvanderlinde Think deeper my friend. Can token in Pit 1 see token in Pit 2 if they are connected by a line?

Consider my picture, can black and yellow see each other even though there is no line-of-sight?

[kwvanderlinde]

@bubblobill No black and yellow can't see each other. That would be true whether or not the Pit VBL was one connected area or two disconnected areas.

[ColdAnkles]

Visibility of Yellow to Others for each VBL Type:

Yellow to:	Red	Black	Blue
Hill	Y	Y	N
Pit	N	N	N
Wall	N	N	N
Cover	Y	N	N

Same for Red:

Red to:	Yellow	Black	Blue
Hill	Y	Y	N
Pit	Y	Y	Y
Wall	N	N	N
Cover	N	N	N

[kwvanderlinde]

What @ColdAnkles posted is what I'm suggesting should be true of Hill VBL, but today is only true if we separate the bits occupied by yellow and black:

For the original case, today's behaviour is:

Yellow to:	Red	Black	Blue
Hill	Y	Y	Y
Pit	N	N	N
Wall	N	N	N
Cover	Y	N	N

Red to:	Yellow	Black	Blue
Hill	Y	Y	N
Pit	Y	Y	Y
Wall	N	N	N
Cover	N	N	N

Notice the only difference is that yellow can see blue in the Hill VBL case.

[bubblobill]

That's why I made the picture. We can use it to define what "should" be. Your case definitely fails what Hill is expected to be, but it also defines an as-yet unnamed but potentially useful extra type.