[Feature]: Improved control of aura origin offsets when a token with image layout offsets is not snapped to grid.

Baaaaaz commented 2 months ago

Describe the Problem

I have tokens which have:

token image layout properties offset by X and Y to alter the center of image rotation &
a token shape of TOP_DOWN &
snapped to grid = FALSE

If such tokens are not snapped to grid, their auras do not originate from the center of image rotation, see image below which displays the issue using some turret image tokens at 90 degree rotations for different scenarios, using the following aura:

LoS Arc: aura scale beam width=0.2 offset=30 10#ff0000 offset=-30 10#0000ff

The Solution you'd like

Options/settings/functions to better align or control aura origin X/Y offsets (especially when token image layout X/Y offsets !=0) and the token is not snapped to grid, such that the aura origin can match the token image layout X/Y offsets center of rotation at any rotation. e.g. i.e. looks suspiciously like auras relative to token when the token is snapped to grid, but erm it isn't.

Alternatives that you've considered.

Editing each image before bringing into MapTool and adding blank areas so the center of the image becomes the center of rotation (rather than using MapTools token layout offsetX and offsetY settings), however editing this will affect the native size of the image and disrupt an ability to dynamically scale the image relative to other (associated) images.
Not using aura beams for targeting :(

Additional Context

No response

kwvanderlinde commented 2 months ago

This sounds like a bug to me rather than needing a new feature. I.e., the aura origin ought to always match the center set in the token layout, and definitely shouldn't change based on whether the token is snap-to-grid or not.

I can certainly imagine use-cases for more fine-grained control over the how light sources are positioned for tokens, but adding that sort of feature seems like overkill for this case.

Baaaaaz commented 2 months ago

Given how long it may have been present and there may be a need for different behaviour on different map grid types (e.g. grids vs gridless) I did not originally see it as a bug myself. Some extra observations following further testing suggest that I may have conflated two things:

Toggling snap to grid on a token with layout offsets changes the origin of vision and lights, as well as previously identified auras. This then affects which FoW may be revealed, canSeeToken() results, etc. i.e.

When a token is snapped to grid its vision/light/aura origin is at its footprint centre (i.e. same as the token layout centre)

Dragon: TOKEN SETTINGS: 
TokenX, TokenY = 0, 0 
Token Layout = {"scale":1.0,"xOffset":150,"yOffset":0} 
Snap to Grid = 1 
Dragon Sees Elf = [] 
Facing = 
Lights = Torch - 20 
Shape = TOP_DOWN

When a token is not snapped to grid its vision/light/aura origin is the token's image centre (i.e. is offset by the token layout)

Dragon: TOKEN SETTINGS: 
TokenX, TokenY = 0, 0 
Token Layout = {"scale":1.0,"xOffset":150,"yOffset":0} 
Snap to Grid = 0 
Dragon Sees Elf = ["TOP_LEFT", "TOP_RIGHT", "BOTTOM_RIGHT", "CENTER"] 
Facing = 
Lights = Torch - 20 
Shape = TOP_DOWN

If this was a bug and toggling a token's snap to grid was changed so that the origin did not change, which is the correct origin may be map grid type dependent?

Vision/Light/Aura origin for rotated unsnapped TOP_DOWN token is centred on original unrotated token.

For a rotated TOP_DOWN token that has layout offsets, the token image position orbits around the token footprint centre by the rotated layout offsets, as well as the image itself being rotated about its own centre.

However the vision/light/aura origin for this unsnapped token is the position of the original unrotated token regardless of the actual token facing/rotation. I've somewhat exaggerated the layout Y offset in some of my original examples to illustrate this (and yes the turret no longer rotates about its realistic centre of rotation!). e.g.

Furthermore dragging such a token displays the dragged token in one position, the drag path in another position (based on the footprint), and the dragged distance & player name labels in yet another position (based on the unrotated token position). e.g.

Happy to raise a new bug ticket though if this ticket cannot be converted to one, or perhaps a simpler new feature (rather than fine grained control) could be to provide an option to select the origin of the tokens vision/light/aura to be one of:

default (current behaviour and dependent on snap to grid setting)
footprint centre (regardless of snap to grid setting)
token image centre (regardless of snap to grid setting)
rotated image token centre (especially for orbiting TOP_DOWN token images)

Noting also Rev's ideas in https://github.com/RPTools/maptool/pull/4886#issuecomment-2352219884 for different vision/light/rotation points!

RPTools / maptool