Rules Lawyers - CR question

Expand Messages
• Hi all, I m testing converting our internal CR system into using Floats as opposed to Integers (so we internally represent fractional CRs properly). I have an
Message 1 of 17 , Mar 18, 2008
Hi all,

I'm testing converting our internal CR system into using Floats as
opposed to Integers (so we internally represent fractional CRs properly).

I have an example where our logic currently calculates CR for a 4th
level fighter as:

4 Levels of Fighter = 4
Race Gnome = 0.5

Total CR = 4.5

Is this a correct calculation according to the rules?

K
• ... I don t know that I ve ever seen any explicit rules for that big a difference. Have you tried wizard s site? ... 4 + 4 = 6 4 + 2 = 5 4 + 1 is somewhere
Message 2 of 17 , Mar 18, 2008
> I have an example where our logic currently calculates CR for a 4th
> level fighter as:
>
> 4 Levels of Fighter = 4
> Race Gnome = 0.5
>
> Total CR = 4.5

I don't know that I've ever seen any explicit rules for that big a difference. Have you tried wizard's site?

> Is this a correct calculation according to the rules?

4 + 4 = 6
4 + 2 = 5
4 + 1 is somewhere between 4 and 5

so 4 + .5 would probably be a negligible amount.

• ... I don t have the rules in front of me but my recollection was that the fraction is dropped once the creature gets levels which grant a straight integer.
Message 3 of 17 , Mar 18, 2008
Martijn Verburg wrote:
> Hi all,
>
> I'm testing converting our internal CR system into using Floats as
> opposed to Integers (so we internally represent fractional CRs properly).
>
> I have an example where our logic currently calculates CR for a 4th
> level fighter as:
>
> 4 Levels of Fighter = 4
> Race Gnome = 0.5
>
> Total CR = 4.5
>
> Is this a correct calculation according to the rules?
>
> K
>

I don't have the rules in front of me but my recollection was that the
fraction is dropped once the creature gets levels which grant a straight
integer.

NPC levels grant CR at Level-1 so a level 1 Gnome Warrior is CR:.5 but a
level 2 Gnome Warrior is CR:1

--
~ Eddy Anthony (MoSaT)
~ Chair Second, PCGen Board of Directors
~ Data Content Second, Doc Chimp, OS Tamarin
• ... Hash: SHA1 ... I ve always been under the impression that any time there is a decimal place, or some left over the number is rounded down. In this case,
Message 4 of 17 , Mar 18, 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Verburg wrote:
| I have an example where our logic currently calculates CR for a 4th
| level fighter as:
|
| 4 Levels of Fighter = 4
| Race Gnome = 0.5
|
| Total CR = 4.5
|
| Is this a correct calculation according to the rules?

I've always been under the impression that any time there is a decimal
place, or "some left over" the number is rounded down. In this case,
the Gnome would be a CR4. I take the fractions into consideration only
on the base creature. Any time I level one up, I ignore the fraction.

I can't cite rule from the book off the top of my head but that's how I
handle it. After all, CR assignment is more an art form than a science. :)

- --
Andy Moore
The Wandering Dru GnuPG Key: 9235A5B9
http://www.druswanderings.net

Get nifty TCLUG merchandise at the TCLUG Store!
http://www.cafeshops.com/tclug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFH3+MV9Z9ikpI1pbkRAuEuAKCf8lvX3qx7GSZBbN2QaEVwzy0N3gCfcPPT
MyX7HIyxgfi5SZdQbCJerSM=
=c3FR
-----END PGP SIGNATURE-----
• ... OK, at the moment this is the definition that I ll go for. CR added by Race is the 2nd to last addition to CR (the MISC CR bonus is last) So if I detect
Message 5 of 17 , Mar 18, 2008
> I don't have the rules in front of me but my recollection was that
> the fraction is dropped once the creature gets levels which grant a
> straight integer.
>
> NPC levels grant CR at Level-1 so a level 1 Gnome Warrior is CR:.5
> but a level 2 Gnome Warrior is CR:1

OK, at the moment this is the definition that I'll go for. CR added
by Race is the 2nd to last addition to CR (the MISC CR bonus is last)

So if I detect that the CR is already above 0 (from character levels,
templates, HD etc) then I know not to add the racial CR (_if_ it is
less than 1)

K
• ... I think this is the formula for converting the CR s of multiple creatures into the EL of an encounter. I think Kar was looking for determining the CR of a
Message 6 of 17 , Mar 18, 2008
> 4 + 4 = 6
> 4 + 2 = 5
> 4 + 1 is somewhere between 4 and 5
>
> so 4 + .5 would probably be a negligible amount.

I think this is the formula for converting the CR's of multiple
creatures into the EL of an encounter. I think Kar was looking for
determining the CR of a single creature by adding race, classes,
templates, and other miscellaneous modifiers.

Cheers,

Sir George Anonymous
• ... properly). You re aware that 1 1/3 - 2/3 is not 2/3, as there are special rules for CRs under 1, right? This is not a trivial change, IMHO. TP.
Message 7 of 17 , Mar 18, 2008
--- In pcgen@yahoogroups.com, "Martijn Verburg" <martijnverburg@...>
wrote:
>
> Hi all,
>
> I'm testing converting our internal CR system into using Floats as
> opposed to Integers (so we internally represent fractional CRs
properly).

You're aware that 1 1/3 - 2/3 is not 2/3, as there are special rules
for CRs under 1, right? This is not a trivial change, IMHO.

TP.
• Hi Tom/All, ... I don t think the case you mentioned above was ever catered for as far as can tell. I m not sure how a creature could have a CR of 1 1/3? Is
Message 8 of 17 , Mar 19, 2008
Hi Tom/All,

> You're aware that 1 1/3 - 2/3 is not 2/3, as there are special rules
> for CRs under 1, right? This is not a trivial change, IMHO.
>
> TP.

I don't think the case you mentioned above was ever catered for as far
as can tell. I'm not sure how a creature could have a CR of 1 1/3?
Is there an example of this somewhere?

As an aside, in the old code any 1/x CR was treated as a -x CR
internally (so it could be stored as an int), which was then
subsequently converted back to a 1/x CR for display purposes.

CR was also stored an manipulated in an inconsistent way across the
code base, sometimes float other times int (as mentioned above), not
sure if that was deliberate.

I've completed the conversion on my sandbox and everything appears to
be working OK. Unit tests pass (after I added some code for display
purposes) and the bug raised by the user is also fixed (< CR1
creatures now give XP in GMGen).

Does anyone know what other tests I can perform in PCGen to make sure
I haven't broken anything?

K
• ... Also check the dialog window created by clicking the Add Combatant button on the Initiative tab. Joe
Message 9 of 17 , Mar 19, 2008
> Does anyone know what other tests I can perform in PCGen to make sure
> I haven't broken anything?
>
> K

Also check the dialog window created by clicking the "Add Combatant"
button on the Initiative tab.

Joe
• ... Yeah just caught that now, it was only allowing Integer input, I ve allowed it to have Float input now. K
Message 10 of 17 , Mar 19, 2008
--- In pcgen@yahoogroups.com, "joefrazierjr" <jfrazierjr@...> wrote:
>
>
> > Does anyone know what other tests I can perform in PCGen to make sure
> > I haven't broken anything?
> >
> > K
>
> Also check the dialog window created by clicking the "Add Combatant"
> button on the Initiative tab.
>
> Joe

Yeah just caught that now, it was only allowing Integer input, I've
allowed it to have Float input now.

K
• ... Yea, that s really what I was hitting on. But what s the appropriate change? The existing code may be wrong, but if you take a CR stored as -3 internally
Message 11 of 17 , Mar 19, 2008
--- In pcgen@yahoogroups.com, "Martijn Verburg" <martijnverburg@...>
wrote:
> As an aside, in the old code any 1/x CR was treated as a -x CR
> internally (so it could be stored as an int), which was then
> subsequently converted back to a 1/x CR for display purposes.

Yea, that's really what I was hitting on. But what's the appropriate
change?

The existing code may be wrong, but if you take a CR stored as -3
internally and add CR of 2, you end up with a CR of -1, which is 1/1 =
1. Even more strange is the -3 internally and add a CR of 3 and you
end up with CR of 0. Clearly something in the math is very weird.
Are templates closely related to race making assumptions based on
that? Can/should we change this without deprecating CR and replacing
it with a different token? Perhaps the code today is just wrong and
you're fixing it without breaking anything (that would be nice), and
thus we don't need to worry about current behavior, but I'm just
curious how that's being handled and if it's an issue (and how do we
know if it's an issue in homebrews)?

> Does anyone know what other tests I can perform in PCGen to make sure
> I haven't broken anything?

Take the case where it would have been 0 in the existing 5.13.11
code... and see if it works properly (whatever that means) ;)

TP.
• Hi Tom, ... Yeah it didn t work out at all. That said the situation never actually cropped up in our data sets. The fractional CRs we have are all 0 CR
Message 12 of 17 , Mar 19, 2008
Hi Tom,

> > As an aside, in the old code any 1/x CR was treated as a -x CR
> > internally (so it could be stored as an int), which was then
> > subsequently converted back to a 1/x CR for display purposes.
>
> Yea, that's really what I was hitting on. But what's the
> appropriate change?
>
> The existing code may be wrong, but if you take a CR stored as -3
> internally and add CR of 2, you end up with a CR of -1, which is
> 1/1 = 1. Even more strange is the -3 internally and add a CR of 3
> and you end up with CR of 0. Clearly something in the math is very
> weird.

Yeah it didn't work out at all. That said the situation never
actually cropped up in our data sets. The fractional CRs we have are
all 0 > CR < 1 and all come from the Race (which is added last in the
logic and is ignored if the running total CR from classes, templates
etc is >= 1).

> Are templates closely related to race making assumptions based on
> that?

Nope, the code for adding CR via a template was totally separate and
assumed (and only catered for) that CRs were whole numbers, so the
issue never came up.

> Can/should we change this without deprecating CR and
> replacing it with a different token? Perhaps the code today is
> just wrong and you're fixing it without breaking anything (that
> would be nice), and thus we don't need to worry about current
> behavior, but I'm just curious how that's being handled and if it's
> an issue (and how do we know if it's an issue in homebrews)?

I'm almost 100% sure that I've fixed it internally with regards to
supporting all of our existing functionality. I tested pretty heavily
using a combination of GMGen, LST Editors, Output Sheets and existing
Unit tests to read in, manipulate and then spit out CRs. Mind you I
need that Math library in order for this to be compatible with
existing homebrews (writing out in 1/x format). It behaves seamlessly
with all of my old datasets, but of course more test cases are welcome!

> > Does anyone know what other tests I can perform in PCGen to make
> > sure I haven't broken anything?
>
> Take the case where it would have been 0 in the existing 5.13.11
> code... and see if it works properly (whatever that means) ;)

Yep that test makes sense. It works correctly (I need to maybe fix
one cosmetic fix in the Lst Editor where the default value is
displayed as 0.0 as opposed to 0).

K
• ... Ah, ok. I m away from the code, so I can t see that :) ... Yea, if the above case can t happen, then you re probably okay. TP.
Message 13 of 17 , Mar 19, 2008
--- In pcgen@yahoogroups.com, "Martijn Verburg" <martijnverburg@...>
wrote:
> Yeah it didn't work out at all. That said the situation never
> actually cropped up in our data sets. The fractional CRs we have are
> all 0 > CR < 1 and all come from the Race (which is added last in the
> logic and is ignored if the running total CR from classes, templates
> etc is >= 1).

Ah, ok. I'm away from the code, so I can't see that :)

> I'm almost 100% sure that I've fixed it internally with regards to
> supporting all of our existing functionality.

Yea, if the above case can't happen, then you're probably okay.

TP.
• ... It s not done that way anyway. The Gnome in the MM is, IIRC, a gnome warrior. Warrior1 is CR 1/2. A Gnome Ftr4 is CR4. Keith -- Keith Davies
Message 14 of 17 , Mar 20, 2008
On Tue, Mar 18, 2008 at 03:38:10PM +0000, Brad Stiles wrote:
> > I have an example where our logic currently calculates CR for a 4th
> > level fighter as:
> >
> > 4 Levels of Fighter = 4
> > Race Gnome = 0.5
> >
> > Total CR = 4.5
>
> I don't know that I've ever seen any explicit rules for that big a difference. Have you tried wizard's site?
>
> > Is this a correct calculation according to the rules?
>
> 4 + 4 = 6
> 4 + 2 = 5
> 4 + 1 is somewhere between 4 and 5
>
> so 4 + .5 would probably be a negligible amount.

It's not done that way anyway. The Gnome in the MM is, IIRC, a gnome
warrior. Warrior1 is CR 1/2.

A Gnome Ftr4 is CR4.

Keith
--
Keith Davies I married the moonshiner's daughter
keith.davies@... How could I go wrong?
keith.davies@... The moonshiner's daughter
http://www.kjdavies.org/ Put some corn in the water
And makes me liquor all night long
-- Hayseed Dixie, _Moonshiner's Daughter_
• ... \$cr = 1, CR = \$cr \$cr CR 1/2 -2 = CR 1/3 -3 = CR 1/4 -4 = CR 1/5 -5 = CR 1/6 I d rather do this than try to represent
Message 15 of 17 , Mar 20, 2008
On Wed, Mar 19, 2008 at 05:19:15PM -0000, Tom Parker wrote:
> --- In pcgen@yahoogroups.com, "Martijn Verburg" <martijnverburg@...>
> wrote:
> > As an aside, in the old code any 1/x CR was treated as a -x CR
> > internally (so it could be stored as an int), which was then
> > subsequently converted back to a 1/x CR for display purposes.
>
> Yea, that's really what I was hitting on. But what's the appropriate
> change?
>
> The existing code may be wrong, but if you take a CR stored as -3
> internally and add CR of 2, you end up with a CR of -1, which is 1/1 =
> 1. Even more strange is the -3 internally and add a CR of 3 and you
> end up with CR of 0. Clearly something in the math is very weird.

\$cr >= 1, CR = \$cr
\$cr < 0, CR = 1/(1+|\$cr|)

So,
-1 => CR 1/2
-2 => CR 1/3
-3 => CR 1/4
-4 => CR 1/5
-5 => CR 1/6

I'd rather do this than try to represent these fractions as floating
point.

Keith
--
Keith Davies I married the moonshiner's daughter
keith.davies@... How could I go wrong?
keith.davies@... The moonshiner's daughter
http://www.kjdavies.org/ Put some corn in the water
And makes me liquor all night long
-- Hayseed Dixie, _Moonshiner's Daughter_
• ... Correct, I ve now coded it so it effectively works that way - K
Message 16 of 17 , Mar 22, 2008
> It's not done that way anyway. The Gnome in the MM is, IIRC, a gnome
> warrior. Warrior1 is CR 1/2.
>
> A Gnome Ftr4 is CR4.

Correct, I've now coded it so it effectively works that way - K
• ... The original code was actually working like this: -2 = CR 1/2 -3 = CR 1/3 -4 = CR 1/4 -5 = CR 1/5 -6 = CR 1/6 However it caused major issues in
Message 17 of 17 , Mar 22, 2008
> \$cr >= 1, CR = \$cr
> \$cr < 0, CR = 1/(1+|\$cr|)
>
> So,
> -1 => CR 1/2
> -2 => CR 1/3
> -3 => CR 1/4
> -4 => CR 1/5
> -5 => CR 1/6
>
> I'd rather do this than try to represent these fractions as floating
> point.

The original code was actually working like this:

-2 => CR 1/2
-3 => CR 1/3
-4 => CR 1/4
-5 => CR 1/5
-6 => CR 1/6

However it caused major issues in calculating XP in GMGen. I've
fixed it so that it's represented as floating point numbers
internally and then the nice 1/x fraction when displayed.

K
Your message has been successfully submitted and would be delivered to recipients shortly.