[Bug]: Movement distance not shown in player mode (either server client or "show as player")

[jbrown123]

Describe the Bug

In this particular campaign file (attached) I don't see the token movement distance when in "show as player" mode. Same thing happens when using a client to a server session. I was asked to post this by @Azhrei on the discord server in #maptool-support.

I attempted to recreate this from scratch by starting a new campaign file but I'm not able to reproduce the bug in a new file. I THINK it has something to do with VBL. I note that this is the same behavior (no distance shown) when you move a token into a VBL area or into an area where there's no possible path from the origin to that location. It seems as though MT is partially confused about the VBL coverage. This is further confirmed by moving the token completely outside the area originally defined by VBL (outside the 'dungeon'). Outside that area (in the "grasslands") you DO see the movement distance displayed. Inside the "dungeon" you don't see it displayed (as player).

Campaign file (renamed to .zip): movement bug.zip

To Reproduce

1. Load the attached campaign
2. Make sure "fog of war" is on (Map | Fog-of-War)
3. Move the token "inside" the dungeon area
4. Note that you see movement distance both as a line and in the box below the token
5. Turn on View | Show as player
6. Move the token again inside the dungeon area
7. Note that you do NOT see the movement distance displayed nor the path of the token
8. Now move the token to a spot completely outside the dungeon area into the "grasslands"
9. Now move the token around on the grassland area and note that you DO now see movement distance

Expected Behaviour

I expect to see movement distance displayed when "show as player" is active

Screenshots

Movement distance shown when not in "player view":

Movement distance NOT shown in "player view":

Movement distance IS show in "player view" outside of VBL area:

Here's the defined VBL:

MapTool Info

1.15.2

Desktop

Win 10 64 bit

Additional Context

No response

[kwvanderlinde]

Haven't debugged it yet, but it seems there is some incorrect FoW information saved for the token. I'll try take a deeper look sometime this week to see exactly why that could be.

As a workaround, I tried restoring FoW. This seems to fix the issue. With the map open, go to the Map menu and select Restore Fog-of-War. After that the token movement should show properly again.

[jbrown123]

@kwvanderlinde interesting that restoring FoW fixes it. It's definitely something in the VBL / FoW code.

Edited to add: BTW, in the original campaign file this was happening to all the PC tokens, not just this one token. So it isn't unique to this one token or it's FoW information.

@Jmr3366 suggested on discord that this might be a known issue. Here's his comment:

I think this maybe a known issue but under another name.
When BL is drawn in a certain way something breaks* and this is the side effect. I removed all your BL, took your map to 25 per cell from 100, redid the VBL holding ctrl down (to lock BL to grid points), put your map back to 100, and it worked as expected. There are several points in your BL that are floaters (and it is a bug).

[kwvanderlinde]

Finally took a look at this. It is indeed very similar to the referenced BL issues, but this is the first time I've seen FoW being the cause. Not that it should be surprising - for players hard FoW is just like MBL, preventing players from dragging tokens into hard FoW. So an issue that plagues MBL is of course possible with FoW as well.

I've been gradually tuning our MBL code to better handle these cases. I'll see what we can tweak to handle your case as well.

[kwvanderlinde]

For visualization purposes:

The red area is the true exposed area, i.e., the places the token is allowed to move. The green area is what the pathfinding algorithm sees as the exposed area. Obviously it gets this completely wrong as the red and green should perfectly match, but in this case they don't overlap at all.

[jbrown123]

Interesting. Why? What's in the vbl that is causing this anomaly?

[Pmofmalasia]

I've been gradually tuning our MBL code to better handle these cases. I'll see what we can tweak to handle your case as well.

I had an issue come up that was similar, and solved in the same way by resetting the FoW - would an additional map be helpful for you in nailing down the issue? Or is the issue clear and just need to think of a way to resolve it?

[kwvanderlinde]

Interesting. Why? What's in the vbl that is causing this anomaly?

@jbrown123
It's when two different points in the VBL are extremely close to one another. It makes it difficult to properly detect what counts as "inside" vs "outside". And unfortunately the current VBL implementation is pretty susceptible to producing these kinds of points.

I've been gradually tuning our MBL code to better handle these cases. I'll see what we can tweak to handle your case as well.

I had an issue come up that was similar, and solved in the same way by resetting the FoW - would an additional map be helpful for you in nailing down the issue? Or is the issue clear and just need to think of a way to resolve it?

@Pmofmalasia
I will certainly not turn down an extra test case!

[jbrown123]

Seems like one solution is to use the same code for displaying FoW as for movement. Then at least you could see that there was an obvious issue.

[kwvanderlinde]

Seems like one solution is to use the same code for displaying FoW as for movement. Then at least you could see that there was an obvious issue.

Typically I would agree with this sort of thing. Unfortunately that makes movement extremely slow outside of the most basic cases, and same goes for vision. Although I do want to do something in this vein to hopefully quash this problem once and for all, but it is going to require some bigger changes.

[kwvanderlinde]

This is the problematic part of the VBL that results in problematic FoW. Redoing just that should fix this map.

[FullBleed]

This is the problematic part of the VBL that results in problematic FoW. Redoing just that should fix this map.

I take it that the new wall topology will help eliminate these kind of hidden vbl problems?

[jbrown123]

Being able to see a map like the one you showed in #5159 (comment) would be helpful. At least that way people could know something is up.

I'm curious what is "bad" about the VBL area in question and how you determined that was the issue. When I look at it in MapTool, even zoomed way in, I see nothing odd or out of place.

[kwvanderlinde]

This is the problematic part of the VBL that results in problematic FoW. Redoing just that should fix this map.

I take it that the new wall topology will help eliminate these kind of hidden vbl problems?

Yes, it will not be subject to the same problems. Though this reminds me, I should put in a change to walls to constrain coordinates to some reasonable resolution just to be safe.

[kwvanderlinde]

Being able to see a map like the one you showed in #5159 (comment) would be helpful. At least that way people could know something is up.

I'm curious what is "bad" about the VBL area in question and how you determined that was the issue. When I look at it in MapTool, even zoomed way in, I see nothing odd or out of place.

Yeah, this one is so subtle it could never be visible to the naked eye even with no limits on zoom. One of the corners (I can't remember which one) is actually two corners placed extremely close to each other (we're talking less than one trillionth of a pixels apart). And the step from the first to the second actually goes "backward", which is what is tripping our algorithms up.

I have written up a change that would address this case. But this stuff is getting pretty patch-work, and I know there are variations on this case that can't be handled with the same sort of approach. So I'll aim to implement a more thorough change around how we represent VBL that would allow things to remain robust over time. Only trick is to not break anything when I do it ...

[jbrown123]

Only trick is to not break anything when I do it ...

That's the best trick, and the hardest to perform ...

My suggestion is to focus on visually surfacing the error to the user, even if it's a "special mode" or whatever that would help users know where the problem is.

What about an option (or automatically when saving VBL) that combines points that are within some margin. If I can't see it zoomed in, it's effectively a single point to the user so why not combine those points? Maybe make it 1 or even 2 pixels as the hysteresis for the combine function.

I did something similar when processing map data to reduce the volume of points for objects like roads. I looked at 3 adjacent points on a line. If I could eliminate the middle point and the line didn't offset by more than some small margin, I'd just drop the middle point. I moved along the shape examining each set of 3 adjacent points and repeating the process. Thus, if you had 5 points in a row that all formed a (sufficiently) straight line, I'd drop all 3 middle points eventually and just leave the outside 2.

Just a thought ...

[kwvanderlinde]

My suggestion is to focus on visually surfacing the error to the user, even if it's a "special mode" or whatever that would help users know where the problem is.

That sounds good, assuming we can automatically identify problem points.

What about an option (or automatically when saving VBL) that combines points that are within some margin. If I can't see it zoomed in, it's effectively a single point to the user so why not combine those points? Maybe make it 1 or even 2 pixels as the hysteresis for the combine function.

I did something similar when processing map data to reduce the volume of points for objects like roads. I looked at 3 adjacent points on a line. If I could eliminate the middle point and the line didn't offset by more than some small margin, I'd just drop the middle point. I moved along the shape examining each set of 3 adjacent points and repeating the process. Thus, if you had 5 points in a row that all formed a (sufficiently) straight line, I'd drop all 3 middle points eventually and just leave the outside 2.

Just a thought ...

Doing this automatically is trickier than it seems. It cannot be done in the derived representation used for pathfinding and vision as that has the potential to change the overall topology, which is essentially the same issue happening here just getting there a different way. It may be possible to adjust the primary representation if it's sufficiently robust, but could have the same problem. I have a utility to do the latter, but I would only include it with plenty of cases to test it on (I've only got a handful at the moment).

[kwvanderlinde]

There is another option I am considering in hopes of quashing two sides of this issue:

1. Dealing with existing BL and FoW with these ultra-precise defects.
2. Preventing more of these defects from being produced in the future.

The idea is to partially bring back a concept we used to have where BL was internally represented structured as a tree when passed to the vision algorithm. This worked quite well, and did not have these precision issues like we're seeing now. The big downside is that it's pretty slow to build and not very useful outside of vision specifically.

But what I hope to do is use it specifically as a correction measure. E.g., when a campaign is opened, we transform existing BL into this tree structure so we really know what belongs where, then reduce that to the representation we actually want for vision and pathfinding. This should keep all the topological information intact while also allowing us to reduce coordinate precision.

That said, I haven't proved it out, so maybe this will all come to naught. And same as in my previous comment, I would want to do a lot of testing before committing to it.

[Pmofmalasia]

I would only include it with plenty of cases to test it on (I've only got a handful at the moment)

I heard someone asking for me ;)

Sorry for the delay in uploading my map, was moving house this week and took longer than expected to get the computer back up and running. It's a huge map, so either sorry or you're welcome for a lot to work with, whichever applies.

Google drive link as it's too big for GitHub: https://drive.google.com/file/d/1IiahkZpjlcNqepH6nLYWw7175MdGDkpW/view?usp=sharing

[jbrown123]

Doing this automatically is trickier than it seems. It cannot be done in the derived representation used for pathfinding and vision as that has the potential to change the overall topology, which is essentially the same issue happening here just getting there a different way. It may be possible to adjust the primary representation if it's sufficiently robust, but could have the same problem.

Why not do it in real time as VBL is being drawn (or as soon as a shape is completed). That would prevent any inverted inclusions from being generated without the users knowledge (they'd see it as it happened) and it would limit the number of times that the algorithm has to be run (meaning it wouldn't slow down FoW or movement during the game).

That said, I haven't proved it out, so maybe this will all come to naught. And same as in my previous comment, I would want to do a lot of testing before committing to it.

What if you turn any of these algorithms on/off via a flag in campaign properties? That way users could turn it on or off depending on what works for them.

[kwvanderlinde]

Doing this automatically is trickier than it seems. It cannot be done in the derived representation used for pathfinding and vision as that has the potential to change the overall topology, which is essentially the same issue happening here just getting there a different way. It may be possible to adjust the primary representation if it's sufficiently robust, but could have the same problem.

Why not do it in real time as VBL is being drawn (or as soon as a shape is completed). That would prevent any inverted inclusions from being generated without the users knowledge (they'd see it as it happened) and it would limit the number of times that the algorithm has to be run (meaning it wouldn't slow down FoW or movement during the game).

No, I don't see this as a viable way forward. If the problem happens while a user is drawing BL, then you're right that a user will be made aware that something went wrong. But they will also have no indication of what, why, or how to avoid it, and in the meantime their BL has gone all screwy.

There are also other ways for these issues to crop up which don't involve user interaction (e.g., macro functions, token BL on moving tokens). If the user doesn't have the BL tools open, they won't see the problem as it happens. Worse, if they do have the BL tools open, they could be subjected to a BL dance party depending on how much automation there is in their campaign.