[Bug]: FOW is inconsistent in blocking non-snap-to-grid tokens

[kwvanderlinde]

Describe the Bug

When a player drags a non-snap-to-grid token through a FoW boundary, the amount that the token can enter the fog depends on the direction. Most directions allow the token to enter about halfway before being blocked. But if dragging up and to the right, the token is hardly able to enter the fog.

Also, in the diagonal case above, if I try to drag the token far, it is stopped by the fog. But if I then slowly drag the cursor back, eventually the token jumps halfway into the fog where it is once again stuck.

To Reproduce

1. Create a gridless map with fog of war and a low vision distance.
2. Place a token on the map with sight and clear its visible area.
3. Start a server and connect as a player
4. As the player, drag the token to the right until it crosses the fog boundary. Should go about halfway.
5. As the player, drag the token diagonally up and to the right until it crosses the fog boundary. It will barely go in, and a pog-style token will appear to not go in at all.

Expected Behaviour

Tokens should be permitted to move halfway into fog before being blocked. This will make the FoW case more consistent with itself, and make it more consistent with MBL works for snap-to-grid tokens.

Additionally, the token should not become stuck when blocked by fog. Changing the angle of the drag should have the token respond accordingly.

Screenshots

No response

MapTool Info

1.13.2, 1.15.0-rc.3

Desktop

Linux Mint 21.3

Additional Context

No response

[bubblobill]

Apologies, I started a simple comment and got carried away with thinking about how we should address moving into FoW.

Snap-to-grid should not be your reference point for behaviour. Gridless should (more-or-less) mirror a real world case, where StG is a bit of a cludge from the early days that made it easier to write game rules.

FoW implements a compromise between the idea of situational awareness, the ability to charge blindly into the unknown. Abstract all that to a user's third-party control paradigm, then design based on two principles. Firstly, a token should _ALWAYS_ be visible in its owner's client. The whole point of the client is to interact with that token. Secondly, FoW is not meant to block movement.

UI constraints;

• Interacting with a token that you cannot see is challenging.
• Interactions with tokens concealed by FoW can reveal information that defeats the intent.
• What is visible changes according to what is selected (shared vision stuff).
• Being able to click on a tiny corner of a token is not the same as being able to pick it with a finger or select it with some weird accessibility tool.

What is deisrable. An experience where I can drag my token off into the wild unknown and do things when I get there. This gives us two situations to deal with based on whether or not the token can sense where they are going;

1. Token can see where they are going, easy - we have waypoints, or you can just execute the move in baby steps - this is good enough for government work.
2. Blind, not so straightforward.
   • Any movement needs to be committed to before before being acted upon, with no feedback given beforehand, e.g. I should be able to drag the token into the darkness and not produce a highlighted path or have my token stopped by a wall.
   • Once committed, allow the move, in a straight line, until movement is blocked. If you need to provide feedback at this point, alter the token facing to be perpendicular to the blocking element.
   • Alternately: Hold the move in suspense and pass control to a GM. This way you get to fall into pits and get whacked by critters.
   • Expose the FoW along the successful move in a line that is narrower than the footprint. Something minimal to show that you walked it but not broad enough to risk exposing the monsters you nearly collided with.

Gonna shut up now