-
December 15th, 2019, 12:12 #11FG Wish List - https://fgapp.idea.informer.com/
License: Ultimate [Unlicensed/Free Trial FG users can play in my games]
-
December 15th, 2019, 12:16 #12Originally Posted by Kelrugem
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.FG Wish List - https://fgapp.idea.informer.com/
License: Ultimate [Unlicensed/Free Trial FG users can play in my games]
-
December 15th, 2019, 13:10 #13
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!FG Wish List - https://fgapp.idea.informer.com/
License: Ultimate [Unlicensed/Free Trial FG users can play in my games]
-
December 15th, 2019, 16:04 #14
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 aboveLast edited by Kelrugem; December 15th, 2019 at 17:47.
My extensions for 3.5e and Pathfinder
Bug reports please here
-
December 15th, 2019, 16:22 #15
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)
My extensions for 3.5e and Pathfinder
Bug reports please here
-
December 15th, 2019, 17:47 #16
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 youLast edited by HoloGnome; December 15th, 2019 at 17:53.
FG Wish List - https://fgapp.idea.informer.com/
License: Ultimate [Unlicensed/Free Trial FG users can play in my games]
-
December 15th, 2019, 17:54 #17
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 problemLast edited by Kelrugem; December 15th, 2019 at 18:20.
My extensions for 3.5e and Pathfinder
Bug reports please here
-
December 15th, 2019, 18:11 #18
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 prefersLast edited by Kelrugem; December 15th, 2019 at 18:22.
My extensions for 3.5e and Pathfinder
Bug reports please here
-
December 15th, 2019, 18:30 #19
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.Last edited by HoloGnome; December 15th, 2019 at 18:33.
FG Wish List - https://fgapp.idea.informer.com/
License: Ultimate [Unlicensed/Free Trial FG users can play in my games]
-
December 15th, 2019, 18:34 #20My extensions for 3.5e and Pathfinder
Bug reports please here
Thread Information
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks