Carry Capacity Tables for Bipeds and Quadrupeds...

[HoloGnome]

Attached is a spreadsheet with tables for all sizes of Pathfinder bipeds and quadrupeds. It also includes custom calculation fields for any STR value. It should also serve as a great gaming utility for anyone who wants to look up encumbrance values. If you see any problems with it, let me know and I will correct them.

HoloGnome's Pathfinder Encumbrance Tables for Bipeds and Quadrupeds v1.0.0 (https://docs.google.com/spreadsheets/d/1Vy0KyCNBuTS91BChVCZ8cYYkPpmdJTf3GpQjfkyoZPY/edit?usp=sharing)

[Kelrugem]

Thank you very much :)

[HoloGnome]

Carrying Capacity is still not working properly in v3.3.9. The fix requires changes to math and also requires 2 places of precision, rather than 1. But, that being said, there is still no precision (of any kind) showing up in 3.3.9. Please check the carrying capacity precision requirements for the Pathfinder SRD (2 places) and test code against the spec before releasing. Thx!

[Kelrugem]

Hi :)

Can you test this extension? I tried to fix this, but I didn't check the formulas (on the first sight they look okay; but I am 8 hours over my bed time so I tried to do this fast :D)

I increased the precision to 2 decimals (always rounded down) and I realized that there were some cases where some numbers had two or more successive roundings involved which is likely to produce rounding errors; thence, I made sure that the rounding is done only once at the very end and not also in intermediate steps to avoid rounding errors (which hopefully resolves the wrong numbers you are still seeing) :)

Also beware: The encumbrance code is only for bipeds not for quadrupeds. This means that the multiplier needed for the encumbrance definition-window for quadrupeds is not the same as described here https://www.d20srd.org/srd/carryingCapacity.htm

I mean that the size modifiers of the weight has the ones of bipeds (like small = 3/4 and not = 1 as for quadrupeds). So, when you want to have correct values for quadrupeds then either change the size in the notes tab to Medium and then use the standard modifiers, or keep e.g. small there and then multiply the modifier given in https://www.d20srd.org/srd/carryingCapacity.htm for quadrupeds with the inverted size modifier of bipeds (inverting, to cancel the accounted modifier of bipeds), so the modifier in FG of a small quadruped would be then 4/3 = 1.333333... (when you type such periodic numbers with enough length FG should correctly calculate it). But it may be easier to keep the size of quadrupeds to medium in the notes tab then :) (when you change the size in the notes tab the encumbrance limits get updated but not the other size modifiers :) Effects with SIZE involved may be then wrong of course, then the "adjusted" modifier, "inverted biped modifier" * "quadruped modifier", is surely the better approach)

[Moon Wizard]

This should already be addressed in the Test channel. So, no extension is necessary unless you can't wait for next release.

Regards,
JPG

[Kelrugem]

This should already be addressed in the Test channel. So, no extension is necessary unless you can't wait for next release.

Regards,
JPG

ah, cool, thanks a lot, I didn't think about looking into the test channel first :)

[HoloGnome]

Thanks, Kelrugem. MW - does this mean you have implemented it to support all the items in the SRD and tested it, etc.? Are quadrupeds implemented? Thx.

[Moon Wizard]

I have set it up based on the formula for bipeds. I have no plans to do quadrupeds.

JPG

[Kelrugem]

As outlined above you can already simulate quadrupeds with the existing code :) When you want to keep the correct size in the notes tab (such that the biped modifier is already used in the encumbrance calculation) then use the following modifiers for quadrupeds in the definition/setting window for encumbrance (opening by clicking on its magnifying glass; hopefully I didn't miscalculate myself):




Fine
2


Diminutive
2


Tiny
1.5


Small
4/3 = 1.33333...


Medium
1.5


Large
1.5


Huge
1.5


Gargantuan
1.5


Colossal
1.5




This is basically the outcome of my formula of the adjusted modifier where you have to be aware of that there is already the modifier of bipeds involved (therefore e.g. 1.5 = 24/16 for colossal and so on) :) Therefore I see no need in an implementation for quadrupeds in the code, maybe only for user friendliness because one expects that the modifier number field for the encumbrance has the same numerical meaning/value as in the core rules :)

[Kelrugem]

Just testing my quadruped solution with my extension or test server: Are you sure that your spreadsheet is correct, HoloGnome? As far as I remember the number for the "light" field should be a third of the heavy one and the medium is two-third of the heavy one. But this is not always the case for your tables I looked at (the "heavy" number fits). (Beware that the official tables, where no numbers after the comma are displayed for bipeds, probably just always round down their values such that it looks less than a third and so on. So the official tables themselves are not really precise after the comma and therefore one has to be cautious about deriving formulas just by looking at the tables :) I guess the idea behind it was just the "taking thirds" approach and that's actually what the code does :) )

As far as I can see after a very fast skim: Your spreadsheet has also sometimes successive roundings involved in their formulas such that rounding errors arise; this is due to that your tables refer to the medium size table where the values already got rounded such that they may get rounded again in the new table :) (In general regards rounding: only round at the very end of the calculation to avoid rounding errors, otherwise the formulas have to be adjusted when one wants to round also at intermediate steps. For example rather take the heavy value in the medium table and take thirds again of that)

So, it could also be that your spreadsheet has rounding errors, too, such that you of course never see exactly these values in FG :)

[HoloGnome]

I have set it up based on the formula for bipeds. I have no plans to do quadrupeds.

JPG

If there are no plans to support quadrupeds, then please don't lock and auto-calculate the code for bipeds...or give users an option to just unlock/disable it so that they can have correct info for their animal companions.

[HoloGnome]

Just testing my quadruped solution with my extension or test server: Are you sure that your spreadsheet is correct, HoloGnome?

I don't know - there could be an error. I will check it again.

Thanks for looking at this problem. It sounds like we definitely need a better solution. The open/unlocked/non-calculated version was probably better overall. There are some good points to auto-calculating, but only if its going to be a full/correct implementation.

[HoloGnome]

Just testing my quadruped solution with my extension or test server: Are you sure that your spreadsheet is correct, HoloGnome? As far as I remember the number for the "light" field should be a third of the heavy one and the medium is two-third of the heavy one. But this is not always the case for your tables I looked at (the "heavy" number fits). (Beware that the official tables, where no numbers after the comma are displayed for bipeds, probably just always round down their values such that it looks less than a third and so on. So the official tables themselves are not really precise after the comma and therefore one has to be cautious about deriving formulas just by looking at the tables :) I guess the idea behind it was just the "taking thirds" approach and that's actually what the code does :) )

As far as I can see after a very fast skim: Your spreadsheet has also sometimes successive roundings involved in their formulas such that rounding errors arise; this is due to that your tables refer to the medium size table where the values already got rounded such that they may get rounded again in the new table :) (In general regards rounding: only round at the very end of the calculation to avoid rounding errors, otherwise the formulas have to be adjusted when one wants to round also at intermediate steps. For example rather take the heavy value in the medium table and take thirds again of that)

So, it could also be that your spreadsheet has rounding errors, too, such that you of course never see exactly these values in FG :)

OK -- looking at it now. Here is my sequential checklist as I go through it - maybe that will help pin down what you are seeing:

1. The printed SRD tables are for Medium bipeds.
2. The calculations across the rows in each category depend on the heavy/medium column for bipeds and the heavy/small column for quadrupeds - these are the 1x multiplier cases.
3. Precision vs. SRD: the lightest gear item is a Neck Guard that weighs .25 lbs. (requiring 2 decimal places -- and 1/4 lb. resolution is certainly reasonable). The lightest tech item is a goo tube that weighs .1 lbs. (but only 1 decimal place). There are animal companions that have strange weights like 7 oz., etc. They might require as many as 4 decimal places of precision, but rounding to 2 places is probably OK.

BIPEDS:
3. The spreadsheet exactly matches the SRD for Medium bipeds.
4. Small bipeds are .75 x Medium. The small table exactly matches. The smallest increment will be .25. No rounding issues.
5. Tiny bipeds are .5 x Medium. It looks like Tiny matches. The smallest increment will be .5. No rounding issues.
6. Diminutive bipeds are .25 x Medium. It looks like Dimunitive matches. The smallest increment will be .25. No rounding issues.
7. Fine bipeds are .125 x Medium. OK - so here, it technically requires 3 decimal places and it rounds up. However, the fine table is an endpoint calculation and not used for other math. In case where there is a multiple of .125, the spreadsheet rounds up. So, while there is rounding in this column, it does not propagate.
8. Large -> Colossal bipeds are all whole-number multipliers and look OK. No rounding.

QUADRUPEDS:
9. Small quadruped exactly matches Medium biped, as expected, and serves as the calculation base.
10. Medium quadrupeds are 1.5 x Small. Values are correct. The smallest increment will be .5. No rounding issues.
11. Tiny quadrupeds are .75 x Small. Values are correct (and are the same as a Small biped). No rounding issues.
12. Diminutive quadrupeds are .5 x Small. Values are correct (and are the same as a Tiny biped). No rounding issues.
13. Fine quadrupeds are .25 x Small. Values are correct (and are the same as a Diminutive biped). No rounding issues. (and quadrupeds never get the .125x case as in #7 above)
14. Large -> Colossal quadrupeds are all whole-number multipliers and look OK. No rounding.

So - everything in the spreadsheet looks right and appears to match the SRD, except for the fact that I did not use 3 decimal places for Fine bipeds (but that rounding did not propagate). I understand the desire to try to do relative math - thirds, etc., but it doesn't work for these tables. The only way I could exactly match the SRD was to always reference the base 1x case and use the printed multipliers, with values derived from the heavy column as calculated from strength score.

If you see specific values in the spreadsheet that are wrong or differ from the check I just did, please let me know exactly where the problem is, and I will check again. Thx!

[Kelrugem]

Ah, maybe it is better to give examples to show you the rounding error:

The Gargantuan quadruped with 10 strength has the numbers 396, 792 and 1200 in your table. Should it not be 400, 800, 1200?

And there is rounding involved also for gargantuan quadrupeds :) Namely in taking thirds: You took a small quadruped as reference because they have the multiplier 1. Then, after rounding with no decimals you get there 33, 66, 100 (10 strength always now) :) To calculate the first number of the gargantuan quadruped (396) you multiply it with the gargantuan modifier (12), so 12*33 = 396. But: The 33 has rounding involved, especially you lost the .3333.. of 100/3 = 33.3333.... After multiplying it with 12 the .33333... adds more than 1, so it would matter :) Compare it with the calculation without rounding: 12* 100/3 = 4 * 100 = 400 which is the number I would expect instead of 396 :)

EDIT: Especially the rounding error is 12 * 0.3333.. = 4, therefore the deviation of your number to 400 is exactly 4 = 400 -396 and then the deviation is 8 for the second number due to taking two thirds such that your error adds up twice :)

This is what I meant with "Round at the very end". A mathematician would say "Rounding is not a homomorphism with respect to multiplication", this means that one should not round when one knows one still will multiply it with some number :) (similar with addition; rounding is very nasty with respect to further mathematical operations. Many physicists do a similar mistake when they publish their experimental results where one wants to reduce the error as good as possible and rounding errors increase in general when one doesn't round at the very end)

Just in case: Are there official tables besides the medium biped you refer to? Of course it could be that, from official side, the tables have rounding "errors", too, because they may not expect that players and GMs think about such little things :) It basically depends on whether one should round and multiplicate, I doubt that there is an official statement; I normally prefer "rounding at the end" to get more consistent results (and the code is easier to write :D) :)

EDIT: Similar arguments for other tables, so the rounding errors can happen because the "taking thirds" step and its rounding is done too early in the calculation as in the example above :)

[Kelrugem]

So, saying that there are rounding errors due to having successive roundings was a bit misleading: You get in general already rounding errors when you round at intermediate steps :) Always round at the end, never before (only when one really knows what one is doing)

[HoloGnome]

OK - I see the problem. Ideally, the math should be different, but that is not what the SRD requires.

The small quadruped table = 1x SRD for medium biped. The SRD printed values at 10 STR are: 33, 66 and 100 and that is what is also shown in the spreadsheet. So, while the SRD may include inherent rounding, we have to use what is printed in conjunction with the stated multipliers. The spreadsheet also uses a round function, but it exactly matches the printed SRD.

Therefore, 12x Gargantuan quadruped values are: 33x12=396, 66x12=792, 100x12=1200 and should not be 400, 800 and 1200.

I agree with you about ideally rounding at the end, but that is not per the SRD. It explicitly says what the multiplier is based on the printed values in the table, not other ideal calculations.

Refer to printed SRD values here that involve no other preliminary math: Carrying Capacity Table (https://www.d20pfsrd.com/alignment-description/carrying-capacity/)

So, the only way to adhere to the SRD is to use the printed values as the base starting point to match and then apply the printed multipliers. And, that's what the spreadsheet does, so it is correct, even if it subsequently propagates rounding errors that are inherent in the SRD (which is the expected outcome based on the rules).

edit: attached screenshot for you

[Kelrugem]

OK - I see the problem. Ideally, the math should be different, but that is not what the SRD requires.

The small quadruped table = 1x SRD for medium biped. The SRD printed values at 10 STR are: 33, 66 and 100 and that is what is also shown in the spreadsheet. So, while the SRD may include inherent rounding, we have to use what is printed in conjunction with the stated multipliers. The spreadsheet also uses a round function, but it exactly matches the printed SRD.

Therefore, 12x Gargantuan quadruped values are: 33x12=396, 66x12=792, 100x12=1200 and should not be 400, 800 and 1200.

I agree with you about ideally rounding at the end, but that is not per the SRD. It explicitly says what the multiplier is based on the printed values in the table, not other ideal calculations.

Refer to printed SRD values here that involve no other preliminary math: Carrying Capacity Table (https://www.d20pfsrd.com/alignment-description/carrying-capacity/)

The only way to adhere to the SRD is to use the printed values as the base starting point to match and then apply the multipliers. That's what the spreadsheet does.

Yes, this was my worry then, too, therefore I was wondering about what the official method would be. Personally I prefer the result with "rounding at the end" because it is a bit more consistent from a mathematical point of view. Basically it is just a matter of definition and one has to fix one

What the core rules imply? I am not sure if your interpretation is the fully correct one, personally the rules are not so clear about that (probably because the authors didn't think about such a thing :D). But your interpretation is probably the better one for people who are not so calculation-inclined :) Then a reference table where one multiplies everything with something is easier

For example: Look at the medium biped table at strength 28: The numbers are 400, 800, 1200. Why should the series of numbers be different for a gargantuan quadruped with strength 10? That is the reason why I find that the "rounding at the end" has more consistent results :)
In the same way I could ask "Why should be both the same?", but that's showing the problems of the abstractness of this system :D

My extension uses the "rounding at end" method, maybe Moon Wizard did the same on the test server (I need to look at this or maybe Moon Wizard reads this here :) ). Personally I prefer this, but I understand the "need of RAW" :)
But "rounding at end" at least would also fit a bit more because in the "real world" weight does not get rounded assuming the definition of light and medium is given by taking thirds (okay, ignoring quantum mechanics and Planck scales and whatever other fancy stuff :D), so the results should not come from calculations with rounding at intermediate steps :) So, it could be that the RAI are like in my understanding :) We probably discovered a RAW <-> RAI problem :D

[Kelrugem]

edit: attached screenshot for you

Ah, didn't see the image; I answered too quickly :D

Yes, I understood already how you calculated the values (I referred to the 33*12 :) ) and of course they make sense when one takes the medium table as a reference when this is fixed as a rule :)

In either case: Unlocked fields might be indeed the best approach such that everyone can take the system which one prefers :)

[HoloGnome]

I completely understand, but it's not up to me. :) It's as printed in the SRD and the spreadsheet follows RAW because it has to. That's what is required. It shows X and says to use multiplier Y based on value X.

For alternate calculations without the rounding propagation, you could certainly use a variant system, if that's what you prefer, but that wouldn't match what is stated in the SRD (preferred values). You're already halfway there with the extension. :) Speaking of which...I'll check it when I get a chance. It could certainly include both methods. If there are complete implementations that include biped and quadruped with the additional pop-up modifiers, then locking and auto-calc is less of an issue and it might be a great solution. But, if that doesn't work, then unlocking and no calculation is probably the best answer.

[Kelrugem]

I completely understand, but it's not up to me. :) It's as printed in the SRD and the spreadsheet follows RAW because it has to. That's what is required. It shows X and says to use multiplier Y based on value X.

For alternate calculations without the rounding propagation, you could certainly use a variant system, if that's what you prefer, but that wouldn't match what is stated in the SRD (preferred values). You're already halfway there with the extension. :) Speaking of which...I'll check it when I get a chance. It could certainly include both methods.

Oki :) When I have time again then I can try to write a separate extension (after lookin into the test server) which takes the medium table as a reference with rounding at the place where it is stated as in the rules :) Maybe I can merge both with some toggle/switch :)

[HoloGnome]

That would be great - you are too quick for me. I added some more to my post. :p But...a toggle might be nice. For Pathfinder Society, it would just be the SRD version. The best toggle would be for quadruped/biped. :)

[Kelrugem]

That would be great - you are too quick for me. I added some more to my post. :p But...a toggle might be nice. For Pathfinder Society, it would just be the SRD version. The best toggle would be for quadruped/biped. :)

oops, hehe, now I saw your remaining answer :) Yes, a toggle for quadruped and biped would be nice then, too, then one does not need my table of adjusted modifiers :)