Token Layout setting doesn't properly scale with grid

[melek]

Describe the bug When using the 'Layout' feature of a token, changing the grid size will incorrectly push to token inward or outward on a grid square.

We use this option for familiars/small creatures co-occupying a square, and often run into issues when changing grid sizes.

To Reproduce Steps to reproduce the behavior:

1. In a new campaign add a new token.
2. Change the token size to 'Tiny' to see the effect more clearly.
3. Edit the token and click the 'Config' tab.
4. Drag the token to the extreme top right corner of the grid area and click 'OK'.
5. Observe the token in the corner of the square.
6. Select 'Adjust Grid', and set the grid size to 200. Observe the token 'drift' inward.
7. Still in 'Adjust Grid', set the grid size to 50. Observe the token 'drift' outward.
8. Edit the token and view the 'Config' tab. Observe that the token has drifted in its layout.

The scaling bug is also apparent if you view the Layout area for any token after changing the grid size; it shrinks or grows with the grid.

Expected behavior I expect the scale and position of token images in the Layout area to be relative to any grid size I select. This is especially important when pasting tokens across maps with different grid sizes.

Screenshots An owl familiar set to the extreme top right corner at different grid sizes, viewed here while map is set to Grid 200:

Same scenario viewed while map is set to Grid 50:

The layout area for the owl familiar after setting its position at Grid 100, viewed here while map is set to Grid 50:

MapTool Info

• Version: 1.5.7
• Install: Upgrade every version since 1.5

Desktop (please complete the following information):

• OS: Windows 10

[Azhrei]

My bet is that the Layout is recorded as an offset in pixels. The traditional way to fix this would be for the user to specify a "window gravity" (as it's called in X Window) and then an offset from that edge in pixels or percentage. Something like nw:+2+2 would be two pixels down and across from the northwest corner of the image, and se:+2+2 would be two pixels up and left from the southeast corner.

(Hm, reference to gravity in the X Window programming manual, but it's pretty terse: https://tronche.com/gui/x/xlib/window/attributes/gravity.html)

[melek]

I ran into this problem again today with copyToken().

Now that #1402 is here (Thanks! Amazing!), it seems that storing the token layout position in pixels is more or less permanent.

Perhaps the X & Y offset for token layout should be recalculated based on the distance per map cell each time a token is created. I think this would be in the following cases (which might all use the same Java methods under the hood, I'm unsure):

• Dragging a rptok onto a map from the Resource Library
• Copy & Pasting a token
• using copyToken() to grab a token from a different map

If I'm understanding right, this would mean that the offset X & Y would need to be stored with a 'Distance Per Cell' value, and that value would have to be checked against the current map for every token created. For tokens that don't yet have a 'Distance Per Cell' value stored with their pixel offsets, it could grab the source map's Distance Per Cell if the token was copied from a map.

That can't be figured for a saved .rptok in the Resource library, but after its been updated it could be re-saved and would have the new value after that.

*edited to fix a wrong word

[Phergus]

Slight correction to last post. It's not the Distance per Cell but the Pixels per Cell value (aka grid size) that needs to be taken into account. Or the offset could just be stored a a percentage of grid size. i.e. Xfactor = (Xoffset/GridSize)

[FullBleed]

Just ran into this problem myself using copyToken() to move something from one map to another.

I tried grabbing the token layout props before moving it and then applying them on the copied token... but therein lies the problem (as @Phergus mentioned, the offset is in pixels and not a percentage.) Will try a workaround by pulling the gridsize off the original map and comparing it to the destination... but that's got its own issues...