[Bug]: Token facing is wrong on isometric maps

[kwvanderlinde]

Describe the Bug

Token facing on all grids - except isometric - measures an angle from the positive x-axis. But on isometric grid, it measures from the line y = -x for positive x.

IOW, 0° always points to the right of the screen. But on isometric grids, it should point down-right in keeping with x-axis.

To Reproduce

1. Drop a token on an isometric map and select it.
   • If it's a top-down token, you'll already see the bug as the token visibly faces downward.
2. Set the facing of the token to the default: [r: setTokenFacing(-90, getSelected())]
   • For non-top-down tokens, the bug is now apparent as its facing arrow points down the screen.
3. Zero the facing of the token: [r: setTokenFacing(-90, getSelected())]
   • Now the token points to the right of the screen instead of down-right.

Expected Behaviour

Facing values should correspond to these directions:

• -90°: down-left
• 0°: down-right
• 90°: up-right
• 180°: up-left

Screenshots

This is what I expect to see for different facing values:

-90°

0°

90°

180°

MapTool Info

1.11.5, 1.15.2

Desktop

Linux Mint 22

Additional Context

No response

[bubblobill]

After playing with rendering state images on tokens I had a quandary with how they should show on isometric tokens. Since I was only addressing the resizing of the images for rotated tokens I left it alone, but I was sorely tempted to change it from to

It would probably make life easier if we just drew them square and morphed the result.

[kwvanderlinde]

Off-topic for this issue, but I'll bite :slightly_smiling_face:

It's an interesting question. I see bar and grid image states as part of a "HUD" that sits over the map, not as part of the map or token itself. So I prefer those it to be left as-is. But other states, like X or Circle states feel like a modification of the token image, and so I would be in favour of those being transformed on iso grids.

[kwvanderlinde]

Bleh, facing is used as keys in image tables. And there it really matters which number is mapped to which screen direction, otherwise the wrong image is used. So changing the meaning of iso facing would break image tables. Or if we try to pass a modified value during image table lookup, it would break any macros that try to use an image table as a regular table along with getTokenFacing().

I think this would be solvable if image tables were a real thing - we could just auto-update the keys to account for the change. But image tables are just regular tables, so messing with them is not a sound option.

Open to suggestions. But for now I don't see a way forward. We may just have to live with iso facing being a little weird.

[FullBleed]

Off-topic for this issue, but I'll bite 🙂

It's an interesting question. I see bar and grid image states as part of a "HUD" that sits over the map, not as part of the map or token itself. So I prefer those it to be left as-is. But other states, like X or Circle states feel like a modification of the token image, and so I would be in favour of those being transformed on iso grids.

I was thinking the same thing about the states and bar needing to be more like a HUD. They look very odd flattened to the map.

[bubblobill]

I always thought image tables were a bit of a crapulent hack when the images should instead be stored on the token and load them to the table panel for editing.

[kwvanderlinde]

I always thought image tables were a bit of a crapulent hack when the images should instead be stored on the token and load them to the table panel for editing.

#644

---

Problem solving time: all we need to do is leave existing calls to getTokenFacing() and setTokenFacing() alone, and leave image table keys alone. Nothing stops us from adding a new way to get the true on-grid facing. E.g., we can just add a parameter to the existing functions:

getTokenFacing(token, map, true)
setTokenFacing(angle, tokenRef, mapname, true)

[bubblobill]

GridCapabilities - add a double FACING_OFFSET Token -

public int getFacing(Grid grid) {
    double offset = grid.getCapabilities.getFacingOffset();
    return offset += facing == null ? -90 : facing;
  }

[FullBleed]

I always thought image tables were a bit of a crapulent hack when the images should instead be stored on the token and load them to the table panel for editing.

I think that could work.

And if the feature is going to continue to be be called an "image table" instead of what it actually is (a "facing table"), then it would be nice if we could store an unlimited number of token images to the token and not limit it to only Facing. It's actually kind of weird that MT has held on to a single-image limitation for as long as it has.

[bubblobill]

Well the limit is 360 since we only have integer facing. I have updated the code in my build to choose "facing mod maxValue" so if you only have 120 frames you cycle through all the images 3 times per spin. Provided you left them numbered 1-120