Size and reach (CT + map)

[Weissrolf]

- Reach is shown wrong on the map for reach higher than 10 ft. Setting 20 reach via CT displays as 4 diagonals on the map, whereas it should only be 3 diagonals.

- Size settings in the CT is rounded up on the map. 6 ft. size in the CT is rounded up to large (10 ft.) size area on the map, whereas it should still be small (5 ft. area).

[Trenloe]

The reach indicator is always a square, it can't be programmed to remove portions of the square. This is built into the base Fantasy Grounds API. It's provided as a rough guide only.

The code only supports size multiples as indicated in TABLE 9–1: SIZE AND REACH on page 474 of the core rules. There is nothing in the PF2 rules that specifically support sizes outside of this.

[Weissrolf]

The reach indicator is always a square, it can't be programmed to remove portions of the square.
Any chance to get custom pointers with filled squares in PFRPG2 (similar to Classic)? These could then be used for reach as well. For reach higher than 10" it would have to use the circle pointer logic then.


This is built into the base Fantasy Grounds API. It's provided as a rough guide only
It breaks for any reach higher than 10". So currently it's only a guide for small and large creatures, larger than that it's not "rough" but wrong unfortunately.


The code only supports size multiples as indicated in TABLE 9–1: SIZE AND REACH on page 474 of the core rules. There is nothing in the PF2 rules that specifically support sizes outside of this.
Currently the CT allows to enter sizes different to that table and then even rounds them wrong. "A typical bugbear stands 7 feet in height" and is a "Medium" creature, not a large one. So either the CT could only allow multiples of 5" to be entered, round differently (according to the PF1 table would fit) or offer categories of Small, Large, Huge, etc. instead of numbers.

[Trenloe]

Currently the CT allows to enter sizes different to that table and then even rounds them wrong. "A typical bugbear stands 7 feet in height" and is a "Medium" creature, not a large one. So either the CT could only allow multiples of 5" to be entered, round differently (according to the PF1 table would fit) or offer categories of Small, Large, Huge, etc. instead of numbers.
You're trying to apply "real world" measurements to a PF2 system that doesn't go to that level of detail.

The "size" displayed in the Combat tracker is initially calculated from the size trait of the creature record. This field determines the size (one side of a square) that the creature takes up on the map as per the Core Rules table I reference above. As the standard PF2 squares are 5 feet in size, the size number is converted to squares. It isn't a direct indication of the perceived height/width or any other dimension of a creature - it is purely the number of squares the creature takes up on the map. FG's implementation of this only supports 5 foot increments - which completely supports the PF2 RPG system.

[Weissrolf]

But the Combat Tracker does *not* support 5 foot increments, which is what I am writing about all the time. It supports 1 feet increments and then rounds those up in a way contrary to PF2, for lots of sizes at least. So the CT should only offer increments of 5 ft. to begin with, which makes changing the value via CTRL-wheel much easier, too.

[Trenloe]

It supports 1 feet increments and then rounds those up in a way contrary to PF2, for lots of sizes at least.
I don't understand this sentence. It seems to me that you want to override a size, but then expect FG to make a rounding decision based off that size. It's possible to override the numerical size field in the combat tracker (which is initially auto set based off the size trait when the NPC is added to the combat tracker). As you mention, FG will round up to the next 5 foot step when displaying the size overlay on the map. This has nothing to do with being "contrary to PF2 for lots of sizes" because at this point you have made a decision to override the system set size data - the creature size has no impact once you override the value. The FG ruleset then rounds this up to the next 5 foot increment when it displays the "size" overlay on the map.

In terms of changing a number field to only accept 5 foot increments - this is custom coding and I don't intend to spend valuable development time better spent on higher priority work. This is a super minor "thing" that doesn't actually break any PF2 functionality. Plus, maybe there are some people who use the field as is and aren't concerned about the size overlay being rounded up.

If this is a big issue for you then it will have to changed via an extension.

[Weissrolf]

Every Enlarge and Shrink kind of spell does exactly that, override the initial auto based size. PF2 uses 5 ft. bases increments, so I expected the PF2 CT to do the same. It's less of a nuisance for Enlarge, as one CTRL-wheel tick rounds the box up properly. For Shrink you need to either enter the new number manually or decrease at least 5 ticks. Not world-ending, but again unexpected in a system that works on a 5 ft. grid base. Thanks for the quick replies.

[MaxAstro]

A bigger issue I have noticed with size and reach is that a lot of Large monsters have a 10' reach when they shouldn't, and Huge monsters 15' when they shouldn't. I assume people are used to PF1, where Large and Huge monsters got that reach automatically, but in PF2 reach is always determined by the attack entries. So for example, just picking a few monsters alphabetically early in the bestiary, the blue shark, camel, and crocodile are all set to have 10' reach but should only have 5' reach.

[ShadeRaven]

Yeah. That's because there aren't actually Space and Reach fields in PF2, which there was in PF1. So a size is sort of the default for everything.

[Trenloe]

A bigger issue I have noticed with size and reach is that a lot of Large monsters have a 10' reach when they shouldn't, and Huge monsters 15' when they shouldn't. I assume people are used to PF1, where Large and Huge monsters got that reach automatically, but in PF2 reach is always determined by the attack entries. So for example, just picking a few monsters alphabetically early in the bestiary, the blue shark, camel, and crocodile are all set to have 10' reach but should only have 5' reach.
The reach indicator is designed to only gives an indication of the "generic" reach of a creature when placed on the map. As mentioned above, this is based off the “Table 9-1 Size and Reach” on page 474 of the core rules, which uses the creature size. It has no mechanical effect on the game. As you mention, the true reach of any attack is listed in individual attack entries.

[MaxAstro]

Would it be possible, when parsing creature entries, to have a process that checks the attacks for the text "reach 10" or "reach 15" or whatever, sets the reach to the highest found number, and sets it to 5 otherwise? I've definitely messed up a number of times and given a creature an incorrect reach because I trusted the default values and shouldn't have. I've learned to check, now, but I imagine newer GMs get confused.

[Trenloe]

Would it be possible, when parsing creature entries, to have a process that checks the attacks for the text "reach 10" or "reach 15" or whatever, sets the reach to the highest found number, and sets it to 5 otherwise? I've definitely messed up a number of times and given a creature an incorrect reach because I trusted the default values and shouldn't have. I've learned to check, now, but I imagine newer GMs get confused.
It would be possible to do something like that - I can add it to my development list (but I won't be working on something like this for a while). This also won't address diagonals in reach greater than 10 feet.

[ShadeRaven]

I also want to caution that.. without looking over all the data I have gone through getting the Bestiaries ready... there might be creatures with differing reaches within their melee attacks.

Example: Dragons. I do believe they have different reaches between their jaws, claws, tails and horns. Animated Armor comes to mind, too, where they have a reach weapon, but their base attacks would be as a normal medium creature.

It might not be so simple as just finding a reach field within the melee attack strings. It's really a question of what do we want to accomplish. If it's to get a default reach, it would really be better to have a reach field that uses the details from the Size and Reach table Trenloe pointed out and then rely on just noticing those attacks which fall outside of that range.