Carry Capacity Tables for Bipeds and Quadrupeds...

[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 )

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

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

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 ). 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

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 ), 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

[Kelrugem]

edit: attached screenshot for you

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

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