[Feature]: Add an option to MapTool to have non-AI routing mode MBL block players from dragging their tokens across it to provide blocking behavior common in other VTTs.

[adventuremagic123]

Feature Request

I'm used to VTTs providing this behavior and would like to see it in MapTool. MapTool, with this feature, would be my favorite VTT -- but this is a must have feature for me.

I do not use AI routing, so I want an option that with AI routing turned off enables MBL to stop players from dragging their tokens across MBL.

The Solution you'd like

With AI turned off, click a toggle button on MapTool placed on the UI near the AI button to enable and disable MBL from blocking player token movement across MBL. Also, it would be nice to have a server startup option as a checkbox to enable or disable MBL blocking as a default when AI is turned off.

Alternatives that you've considered.

Members in the community suggest using AI, but I very much don't like it because ...

For me AI routing reveals too much information (see example below) to players as they move their mouse around about possible pathways available to them without requiring them to reveal FoW. It eliminates too much of the mystery of the game map. I prefer to have my players take their tokens and carefully venture forward, which is what they do without AI.

I'm not saying AI is a bad feature. I'm just saying I don't want to use it. I still think it's pretty cool. But as a GM, I don't want my players to use it. As the GM, though, I wouldn't mind using it, myself -- but that is another story for another feature request.

Additional Context

No response

[adventuremagic123]

Please consider this feature. It seems to be the way MBL is handled by most other VTTs such as Foundry VTT, D20Pro, Fantasy Grounds, etc. and it's how I'd prefer to use MapTool with my players.

These are examples of things I don't like about AI routing and MBL. As I said, I prefer using a model where MBL is enforced because moving across when a player shouldn't be able to, whether on purpose or by accident, spoils the adventure.

1. This is where an area on the map is surrounded with MBL -- but the player is able to move his token inside:

2. This is where AI displays too much routing information to players -- without AI most players move their tokens in a particular direction slowly and cautiously in a more realistic manner while exploring. With AI, they move their token for a desired outcome and get information they should not have -- but there's no way they'd know that they are attempting an illegal move until it's too late:

[adventuremagic123]

I think there might be an option to limit the distance of AI routing -- but that is beside the point. Even that doesn't work well because the movement rate and sight distance change from character to character -- or sometimes even situation to situation.

[adventuremagic123]

AI routing also causes a LOT of awkwardness in a campaign because it gives players the ability to skip standard, realistic exploration because they are not forced to reveal FoW as they go. Instead, players can simply drag their token to a new location on the map, skipping over all of the FoW in between.

I want my players to be forced to reveal FoW as they move -- just like in real exploration and as it is done in most other VTTs.

[adventuremagic123]

I think there is an option to reveal FoW along the path. I will attempt to use this option with AI routing and make the AI routing distance limited to the maxium movement a party member can make and see how that goes. It may or may not be an acceptable work-around.

[adventuremagic123]

Another issue with AI routing as can be seen in my first example is that it allows player token movement, even when there is no legitimate path.

[adventuremagic123]

Please don't get distracted with AI routing, here. This issue is more about how I would like to have standard MBL behavior as we get in other VTTs.

[melek]

I'll pitch in that I'd never seen that ai routing through hard fog before, that definitely seems like incorrect/unintended behavior!

[Azhrei]

Agreed. Any cell with hard fog should be considered inaccessible by the AI routing. Perhaps even soft fog, given that a PC doesn’t know what’s actually there (although having them plot a route and then running into a dragon around a corner in soft fog would be totally amusing. 😁

[adventuremagic123]

I'll use non-AI mode for our games.

[adventuremagic123]

Actually, we do see a benefit to using AI routing, so we're trying it out in our games.

[kwvanderlinde]

Preventing routes through hard fog sounds like the right thing to do and should be fairly straightforward to implement. I'll look into that / file a separate bug report for it.

As for preventing moves across MBL without pathfinding enabled, we could use the same logic as used in our A* algorithm to check for valid steps, i.e., check whether a line going center-to-center from one cell to the next intersects with any MBL. But I don't know if every GM would like this particular logic. Here are a set of possibilities just off the top of my head:

1. As said already, prevent a step where a center-to-center line crosses some MBL
2. Prevent a step into a cell that contains any MBL.
3. Prevent a step into a cell whose center is covered by MBL.
4. Prevent a step into a cell that is more than 50% MBL.
5. Prevent a step into a cell that is completely covered by MBL (e.g., stepping into a solid rectangle of MBL).
6. (not a totally serious suggestion) Use pathfinding to decide if any route is possible, but don't show it to the users in any way.

Aside from that last one, I think all of these options and more can already be implemented via onTokenMove, or nearly so (keep in mind I don't actually use this event, so I may be overlooking something). onTokenMove can deny movement, and gets passed the token's complete path. It's also able to lookup the map MBL within an area of interest which should make it possible to decide whether to deny the move.

[Azhrei]

I think @JamzTheMan had indicated that the VBL blocked movement by breaking the target cell into 3x3 pieces and counting how many of those pieces contained VBL (I could be thinking of the logic to determine whether a token visible above FOW should be displayed, but even if so, this same approach might be a useful technique for movement blocking as well).

@kwvanderlinde If you're going to look into this, there's a related issue where a player can drop a token into a cell that partially contains VBL, then not be able to drag it back out. Not expected behavior, I think. :)

[kwvanderlinde]

I think @JamzTheMan had indicated that the VBL blocked movement by breaking the target cell into 3x3 pieces and counting how many of those pieces contained VBL (I could be thinking of the logic to determine whether a token visible above FOW should be displayed, but even if so, this same approach might be a useful technique for movement blocking as well).

That's definitiely the logic for visible above FOW. But, yeah, make that option #⁠7 😄

@kwvanderlinde If you're going to look into this, there's a related issue where a player can drop a token into a cell that partially contains VBL, then not be able to drag it back out. Not expected behavior, I think. :)

I don't recall seeing this anywhere. If you have a link to a bug report handy, I can take a look.

[Phergus]

Issue #3293 opened for the AI pathfinding through unexposed areas. Please move all discussion of AI pathfinding there.

[FullBleed]

As for preventing moves across MBL without pathfinding enabled, we could use the same logic as used in our A* algorithm to check for valid steps, i.e., check whether a line going center-to-center from one cell to the next intersects with any MBL. But I don't know if every GM would like this particular logic. Here are a set of possibilities just off the top of my head:

1. As said already, prevent a step where a center-to-center line crosses some MBL

2. Prevent a step into a cell that contains any MBL.

3. Prevent a step into a cell whose center is covered by MBL.

4. Prevent a step into a cell that is more than 50% MBL.

5. Prevent a step into a cell that is completely covered by MBL (e.g., stepping into a solid rectangle of MBL).

6. (not a totally serious suggestion) Use pathfinding to decide if any route is possible, but don't show it to the users in any way.

If I had to pick one for default, I'd pick #1 because I think it's more visually intuitive. But, if we had a function that could use the various calculating methods like checkMBL("centertocenter/contains/center/percent", target loc, tokenID/origin loc) then macros and onTokenMove methods could provide more custom/situational options.

[Jmr3366]

This #3293 "done" shouldn't this have closed as well? (or should it not be closed now)?

[kwvanderlinde]

This issue should be kept open yet. MBL still has no effect when AI Pathfinding is disabled.

[melek]

I don't think this issue should be closed until there is a determination on whether we will add an option to block non-ai moves across mbl.

I still think it is an interesting option to consider for games that don't use snap to grid or ai pathfinding, and @kwvanderlinde's center line (option 1) would be a straightforward way to do it.

[kwvanderlinde]

This has come up enough times in casual discussion, plus formals requests like here that I do think it should be done. I've been thinking about taking this on (along with #2844 for the pathfinding case) - maybe once 1.12 is out I'll take a proper look at it.

[Phergus]

This #3293 "done" shouldn't this have closed as well? (or should it not be closed now)?

No. That was specifically a problem with AI routing tokens through unexposed FoW which is supposed to stop movement.

This issue is about MBL not blocking general token movement because it was only designed and implemented to affect the AI routing.

[melek]

My thought for the feature would be a toggle to block/cancel player initiated moves across MBL, probably next to the AI Pathfinding (I'd actually put it to the left of AI Pathfinding so it is a bit clearer that this setting isn't related).

I think behaving exactly as though there is 'hard fog', where the token is stopped at the MBL and snaps to the last valid point along the path, would be good. (Ideally I'd like to modify that behavior to show a 'red' path instead of the current behavior, but that's a new feature request...)