5E - Token Height Indicator

[bmos]

I just experienced something odd:
completely new campaign, 5E, no other extension running
added four characters to the CT, opened a random map [with LoS presets], tried to drag the characters from the CT to the map using the green helmet symbol. During the drag, as expected, a greenish square was shown, but when I released the mouse button, the characters stubbornly refused to enter the map....

Using v3.9? This was just discussed and fixed.

[Weissrolf]

I think my example (screenshot) should measure as 5 ft, not 10 ft, as this is still the first diagonal. I understand there are different options, so I will try them out in PF2.

[Kelrugem]

I think my example (screenshot) should measure as 5 ft, not 10 ft, as this is still the first diagonal. I understand there are different options, so I will try them out in PF2.

That strongly depends on how you approximate the diagonal multiplier. The usual diagonal in 2D has a multiplier given by the square root of 2 (in the Euclidean metric). Many rulesets approximate that by either 1 or 1.5, and then round down to the next multiple of the grid increment

However, in 3D you do not just have one diagonal in a square grid. The screenshot you show is about a "double-diagonal" whose diagonal multiplier is the square root of 3 (in the Euclidean metric), not of 2. You may approximate it in the same way as the square root of 2, but one may argue that one wants to avoid that. GKEnialb's approximation gives an approximation of 2 for the square root of 3

That actually "makes sense" if you approximate square roots by the continued fraction expansion: https://en.wikipedia.org/wiki/Method...tion_expansion
There is some table a bit downwards of that article, and the first order approximations of the square root of 2 and 3 are 1.5 and 2, respectively, with respect to that approximation

If that fits whatever the rulesets say is of course something different; sadly, ruleset developers (I mean Paizo etc.) do rarely explain things mathematically, if they even think mathematical for such things. Often 3D stuff is done very vague in my opinion. If you like the explanation with the continued fraction expansion, then it may be easier to accept such calculations

(Though I assume that it is intended that GKEnialb's extension works like this; I may be wrong, I did not test it on my own. I just only looked at your screenshot)

Does it show a range of 5ft. If the flying and standing tokens are directly next to each other? (because then it would be again a square root of 2, just "one diagonal")

[Weissrolf]

Yes, orthogonal sides show 5 ft. only the 3D diagonal shows 10 ft. PF2 rules state: "As with ground-based movement, moving diagonally up or down in 3-D space requires counting every other diagonal as 10 feet."

Going another step diagonally and up increases the calculation to 20 ft. while it should be 15 ft, it's the second diagonal step.

[Kelrugem]

Yes, orthogonal sides show 5 ft. only the 3D diagonal shows 10 ft. PF2 rules state: "As with ground-based movement, moving diagonally up or down in 3-D space requires counting every other diagonal as 10 feet."

depends now whether they want that one accounts the corresponding diagonal move in the 2D plane Because the diagonal of your screenshot also has a diagonal move in the projection into the 2d plane (hence, the square root of 3 talk above). But Paizo may not have thought about that you have two different diagonal movements in 3d, so, difficult to say if there are no examples in the PF2 rules clarifying that (are they?)

[bmos]

I think my example (screenshot) should measure as 5 ft, not 10 ft, as this is still the first diagonal. I understand there are different options, so I will try them out in PF2.

As Kelrugem says, there is some level of uncertainty in how the rules are written.
Right now it appears to have been calculated as 5ft diagonal + 5ft altitude.
Moving further away then becomes 15ft diagonal + 5ft altitude.

Have you considered using raw distance?

[Weissrolf]

They are neighboring squares, that is 5 ft. and people can hit each other over the head. Sometimes answers are that simple.

[Kelrugem]

They are neighboring squares, that is 5 ft. and people can hit each other over the head. Sometimes answers are that simple.

Also depends A flying target is often more difficult to hit, even if adjacent; in the case of your screenshot only the feet and legs may be similar to hit as non-flying targets, while the remaining body becomes more difficult to hit, reducing the probability for a successful attack With respect to Euclidean measures the distance from centre to centre is certainly bigger than if the target would not fly

[kevininrussia]

I think changing:

	if getDistanceDiagMult or Interface.getDistanceDiagMult then

to

	if getDistanceDiagMult or (Interface and Interface.getDistanceDiagMult) then

should keep this from occuring, but this is almost certainly an extension compatibility issue

I changed line 30 as you suggested. Will report back after next game if the error happens.
Thanks!

[Weissrolf]

For sake of the game system adjacent squares are 5 ft. apart from each other, in PF2 even the second diagonal is considered 10 ft for the sake of (only) weapon reach. Physics and anatomy are ignored.

It also makes no sense to split a diagonal 3D distance into a 2D diagonal + altitude while drawing orthogonal 3D diagonal distances directly. And at least in PF2 the first 3D diagonal is 5 ft. regardless of direction, just like in 2D. I quoted the CRB rule earlier (page 478).

I will take a look at the code and try to fix it for our PF2 group. It's a useful addon in any case.