Distance measurement abnormalities

[Ken L]

So I was encountering a few strange bugs with my distance measurement formula so I started a fresh campaign on the base PF ruleset and found this strange anomaly.

What exactly is happening here?

https://i.imgur.com/Ss0tyt4.gifv

[LordEntrails]

Yep, I'm sure that's from the core, and I suspect it is some type of rounding or truncating issue. You can see basically the same thing if you draw a circle pointer where the center creature is and then notice what squares are considered "affected" and which aren't. You get the same type of ... disconnect. Would be nice if you found a solution :)

[Ken L]

I was looking it over recent (I VNC), and it seems to be a problem with spaces with a side length that is odd.

A token of 3 unit spaces seems to be the sweet spot, but when you scale up the problem pesists for X,Y greater than the position of the token center point, the lower right of the token.

I suspect there's something funky going on in the 'closest square' logic.

The logic should be pretty simple. Assuming the center positions of two tokens:

(Ax,Ay) (Bx,By)
Get the slope between them, and then use the equation for a line to find the constant (y=mx+b)

Next create a bounded value equation representing the square space around it (left bound, right bound, top bound, bottom bound).

Make a direction matrix from the points to determine which equation to use
(-1,1)|(0,1)|(1,1)
(-1,0)|(0,0)|(1,0)
(-1,-1)|(0,-1)|(1,-1)

Perform a 5th grade level point intercept between the line equation and one of the line equations pending on the result of the direction matrix. Then finally bound the x or y result to a max or min value to ensure the intercept is on the defined equations. For those curious, the bounds are the square's corners.

Once you have the intercept of the square 'space' and the line that connects the two token center points. Use the grid size to find the closest center point within the space and use that rather than using the framework's 'snapToGrid' as that may snap to an intersection rather than a center point of a space pending on the intercept's location.

That's how it should be done. Since I'm working with the onMeasure, I get the framework's result of the 'nearest square' implementation rather than the token center point so I can't really work around it as for large tokens it gives strange coordinates. I may revisit this later, but to compensate for this errata requires a bit of tracing which is a bit much to ask compared to other things I readily have source code to.