maptool icon indicating copy to clipboard operation
maptool copied to clipboard

[Feature]: A new take on grid sights, lights, and auras

Open kwvanderlinde opened this issue 1 year ago • 3 comments

Describe the Problem

The grid shape is no stranger to problems due to its nature as a shape. E.g., grid lights can't be freely translated or scaled like other lights, or they stop being aligned with the grid. They are also more specialized than they need to be since they are actually approximations of circles and we don't get grid versions of the other shapes.

The Solution you'd like

Remove grid as a shape. Instead we will have a grid keyword that indicates the sight, light, or aura should always be grid-aligned, and which is useable with any shape. Today's grid shape will be the equivalent of tomorrow's circle grid.

The way the keyword works will be a bit different than today's grid. Imagine a light that needs to be drawn. At first we will treat the grid light the same as non-grid lights: get the area, apply multipliers, constrain by VBL. Once that is done, we consider the grid nature: any cells touched by the light's area will be considered part of the gridded light area. Add those cells up and we have the gridded shape to use for rendering.

Alternatives that you've considered.

A tweak on the requested feature would be configuring the portion of a cell that needs to be covered by the original area before it counts as being part of the gridded area. E.g., grid=50 to say half the cell needs to be covered.

An alternative to reworking grid is to ditch it altogether and have a different tool to visualize gridded / mechanical extents. But then sights, lights, and auras would just have their "ideal" form, with grid considerations coming from elsewhere.

Additional Context

A few existing bug reports for grids that should be addressed with this feature:

  • #2508
  • #2957
  • #1515

kwvanderlinde avatar Dec 31 '23 00:12 kwvanderlinde

disagree to some extent. Grid shapes should not be snapped to grid themselves. Most of the time they will be as people with a grid fixation will have tokens StG, but if they leave their StG security blanket, the effect should follow the token.

bubblobill avatar Dec 31 '23 05:12 bubblobill

disagree to some extent. Grid shapes should not be snapped to grid themselves. Most of the time they will be as people with a grid fixation will have tokens StG, but if they leave their StG security blanket, the effect should follow the token.

I disagree with your disagreement :slightly_smiling_face:

Why should they follow? Why use a grid light if you don't care about the grid itself? Per the help text, the purpose of grid is

if you want to see exactly which grid cells are affected by a Light/Aura

Also keep in mind that STG tokens do not all align with the grid in the same way. E.g., on a square grid, a Medium (1x1) STG token is centered at a cell center, while a Large (2x2) STG token is centered at a cell corner. In both these cases, a grid shape should be aligned to the grid. And for a plain circle grid light, both cases should be symmetric.

But that can't be reconciled with freely moving grid shapes for non-STG tokens. Doing so would either:

  1. Force the Medium case off-grid by half a cell;
  2. Force the Large case off-grid by half a cell; or
  3. Make one or the other cases arbitrarily lobsided in one direction.

Well, okay, we could just not reconcile STG and non-STG behaviour and have lights behave completely differently in each case, but that's just a confusing mess.

kwvanderlinde avatar Dec 31 '23 06:12 kwvanderlinde

If grid lights are touched there should be some way to customize when e cell should be included like:

  • light covers any part of the cell
  • light covers some percentage of the cell
  • light covers center of the cell. This probably doesn't have to be per light but some campaign setting.

thelsing avatar Jan 02 '24 18:01 thelsing