Version 12 Deep Dive - Grid API

[trail belfry]

Version 12 Deep Dive - Grid API

[mental lily]

Alternate grid movement modes, fantastic!

[hybrid ridge]

I figure that included are going to be utills for translating a distance from and to grid units

[frank remnant]

While you're poking around in grid stuff, it would be really nice if a reference to the token (if one is being dragged) was passed into the measuredistances method

[inland vigil]

Would or could an isometric grid be included? I know it’s more than just “squashed diamonds.” As long as it’s being revised/expanded.

[frank remnant]

Also, now would be a good time to drop even vs odd options for hex grids. The only thing exposing that distinction does is confuse users.

[silk fern]

I agree that having a reference to the token when measuring distances is useful.

[quiet ferry]

@ember pine

[ember pine]

Thank you! To give you an idea I'm very interested in developing procedural hex world generation. I thought I'd start from the very basics with getting to grips with the hex grid system as it currently stands - but I think I'm right in saying that the grid is only aesthetic at the moment and just controls the snapping position of tokens?

[vapid knot]

I just hope this makes it easier to find positions of adjacent hex cells for better interaction with them for everything.

[hollow jackal]

Will measured templates have access to the diagonal measurement technologies, even if it's not on by default to save dndpeople from square circles?

[hollow jackal]

Oh, oh, do the measurement facilities measure between different elevations? That would be great if we could offload that to core as well.

[vapid knot]

Partial problem there is that core has no idea about token height (in terms of elevation, not x/y) and if that means anything. Tho I guess something is better than nothing.

[hollow jackal]

I'm willing to bet no ttrpg rules specify

we treat everyone as cubes

1-2-1 becomes 1-2-2-2 for "diagonal diagonals"

[vapid knot]

From PF1, here's one

(10 ft. by 15 ft.; 5 feet high)

[hollow jackal]

Is that a creature?

[vapid knot]

Vehicle. Space is so rarely mentioned in creatures that I don't know what to look for.

Some of these are for combat.

[hollow jackal]

2e vehicles also have a third dimension for ... some reason

And since it's actually printed, we use that for measurement. But Amiri? She's 5 feet tall, 5 feet wide

[vapid knot]

Most creatures are cubes because that's their central movement area with attack reach and such covering the range of their limbs, so they actually are Constantly far out of their actual token space.

I'm pretty sure there were some flat monsters but I can't find them.

I bet scifi and modern games have more examples of weird shapes.

[radiant chasm]

We have canvas.dimensions.distancePixels (Scene#dimensions.distancePixels, added in V11): the factor to convert distance units to pixels.

[radiant chasm]

@silk fern The token is now set when the measuring begins instead of when the move command is given: https://github.com/foundryvtt/foundryvtt/issues/10213

[radiant chasm]

No plans for isometric support at the moment. If we add it, I imagine that it wouldn't be another grid type but an option to choose the camera perspective (top down or isometric): any type of grid could be view from the isometric perspective.

[radiant chasm]

There is BaseGrid#getNeighbors pre-V12, which is deprecated now in V12 in favor of BaseGrid#getAdjacentOffsets, and HexagonalGrid#getAdjacentCubes (https://github.com/foundryvtt/foundryvtt/issues/10071).

[radiant chasm]

No changes to the shapes of templates at the moment. I assume there are users that prefer to use round circle template even when they should be squares because the diagonal rule is equidistant. And in hex grids the circle template would technically need to be a hexagon, which some users would probably dislike. Perhaps we should add the option to choose between Euclidean template shapes and shapes that match the grid type (and diagonal rule).

[vapid knot]

Useful for some systems.

[radiant chasm]

No support for measuring between different elevations. The grid is 2D.

[frank remnant]

Never got a response the first time around so I'll ask again:
Seeing as there's a big grid api change in v12, would staff consider removing/deprecating the odd vs even distinction from the UI on hex grids and just settle on one or the other? I don't think exposing that internal detail to users adds any value, but it definitely causes confusion. We fairly often get people stuck in analysis paralysis in the lancer support channel asking whether to use even or odd hexes. It also increases the complexity of module code that uses grid offsets since the parity needs to be accounted for. (For this reason, I almost exclusively use cubic coordinates in my calculations.)

[radiant chasm]

We have considered it but it's not that simple unfortunately. Reason is that in 0 padding scenes you cannot shift the grid without pushing parts of the background image out of the canvas bounds. We would have to replace the Background Offset with a Grid Offset, but we need to continue to support legacy support for Background Offset because Background Offset cannot be migrated to Grid Offset as it would change the relationship of pixel coordinates with grid coordinates in this scene and therefore be potentially breaking.

[frank remnant]

Are major versions not the place for breaking changes?

Like, I respect that this isn't an easy problem to solve, but this distinction being exposed has been a pretty big pain point from a support and development perspective and I don't think it's completely intractible