Pointer numbers being rounded up results in wrong size display

[Weissrolf]

This is not a 25 ft. emanation, but a 20 ft. emanation:

https://i.imgur.com/FhNkBrU.png

This should read 5 ft. not 10 ft.:

https://i.imgur.com/Bl0niFS.png

Simple solution, round down instead of up.

[Weissrolf]

I suspect that this is intentional instead of being a bug? If so, could someone explain the reason for the current design?

[Griogre]

If that is 5E you need to put AOE's on vertices not the center of a square.

[Weissrolf]

In Pathfinder 2 there are AoE spells put on vertices and there are auras/emanations put on the center of a character/square. The latter are done by using an "in-between" size of pointers. And these in-between sizes are rounded up, but need to be rounded down.

[Jiminimonka]

Its counting the distance from the centre of the token.

[Weissrolf]

Except that it is not. It rounds up. I suggest to instead round down, because then the measurement becomes much more useful.

[Jiminimonka]

Except that it is not. It rounds up. I suggest to instead round down, because then the measurement becomes much more useful.

That a fact? Looks to me like its measured from the centre of the circle (the centre of the token) - disregarding the grid using a ruler on the screen.

[Kelrugem]

That a fact? Looks to me like its measured from the centre of the circle (the centre of the token) - disregarding the grid using a ruler on the screen.

Look at the second screenshot: When it measures from the center, then it would be 7.5' and not 10' :) It rounds up to the next multiple of 5' and Weissrolf suggests to round it down to the next multiple of 5' which would be 5' in that case :) (for the 25' example it would be then 20' instead)

Makes also more sense to me what Weissrolf suggests (EDIT: Except there is a reason for this which I do not know yet :) ), because of how reach normally works and that the common rule is often to round down, and then it would be in alignment with the line tool (because the line tool rounds already down I believe, I didn't test though) :)

[LordEntrails]

Pointers do not change behavior based upon ruleset interpretations or rules. Size the pointer to whatever size if appropriate for your use case and then move it to the vertex or center of the square as appropriate.

[Weissrolf]

Both DND and Pathfinder measure from a vertex or from the edges of a the chars square. The former is measured correctly by FG, the latter is not and concerns mostly auras. This only concerns small/medium chars, but it would be nice to at least get correct numbers for those sizes.

Having FG round down instead of round up is all we need for that to work out.

[seycyrus]

We had this problem in the Gurps ruleset (which uses the superior Hex grid :) ).

I had thought it was resolved, but things still seem to be a bit off for me.

[Moon Wizard]

It rounds up by design. Otherwise, players constantly try to fudge an extra half block in their AoE/targeting/etc. It happened in my game years ago. You'd get just the opposite problem for fireball placement for remote AoE.

The issue is that you're applying your logic to include the token's area as not being included. (i.e. emanation vs. area) That is a completely different scenario that would have to adapt to token sizes (i.e. emanation from Medium token is different than emanation from Large token), and not something we plan to support via pointers in near future.

Just draw the token to the true midpoint distance for Medium tokens; and it shows you the squares encompassed as partially covered.

Regards,
JPG

[Kelrugem]

It rounds up by design. Otherwise, players constantly try to fudge an extra half block in their AoE/targeting/etc.

aaah, thanks, about that I did not think :) But indeed, that could happen (especially unintentionally, though unintentionally it can now then be too small by a half block, but psychologically one could argue that that is less likely because we try to make things rather big than small)

[Weissrolf]

So because some of players like to cheat everyone else has to live with wrong numbers? Yes, I mentioned already that this currently only help with small/medium tokens, but that's the majority of tokens.

I don't agree with that assessment, but it does not appear to be debatable, so my players have to live with it.

[Moon Wizard]

It is not wrong numbers; they are correct for AoE. Pointers were designed to represent AoE effects; not auras.

Auras require being attached to tokens and the accompanying token information, and there is no specific support for auras other than the basic underlays used by some rulesets for size/reach. The underlay API is available to create square regions for any ruleset or extension.

Regards,
JPG

[Weissrolf]

You already explained that the "rounding up" part is because you experienced cheating players. The current implementation does not represent AoE effect more correct than a rounding down implementation would, both are off by 2.5" when centered on a square/token. So yes, the numbers are wrong, just that the round-down kind of wrong would help all DND/PF players to quickly create small/medium auras with correct numbers.

This is not in the interest of SW, so we players will have to live with it. Now that this is clarified I can tell my players to hopefully not be confused by the round-up numbers. Maybe using player-controlled tokens to replace pointers will be easier in the future.

[Moon Wizard]

If you draw a circle pointer with a 4 square radius (center to center), then it shows 20' radius.
If you draw a circle pointer with a 4.5 square radius (center to edge), then it shows 25' radius.

This is designed behavior, because this is how the 5E game system works. A player doesn't get an extra half square of movement or an extra half square of AoE, just because we decided to round down. The way that the measurement works is that all squares are always rounded up to the nearest whole number for all things (targeting, movement, AoE, etc.).

I am closing this thread, because this is expected and designed behavior that has been in place for 10+ years.

Regards,
JPG