View Full Version : CR and XP?

June 22nd, 2016, 02:33
While setting up a ChallengeRating helper class to validate valid CR values on input. As shown in the tables the XP value for a creature is a function of that.

Is the individual NPC's XP *always* intended to be a function of CR? (I don't mean adjusted encounter ratings or the like, I mean the MM CR values...)
If so, then I would prefer to not even look at the inputted XP value with npc.txt since it only opens up an opportunity for a typo or other user-error.

Along the same vein, I already did something like this for the Ability Scores line where I only read the scores not the mods and simply output in the XML the "proper" mod +/- values. Now, as I type this, I wonder if people ever adjust these to NOT reflect the normal (Score / 2) - 5 calculation. Or (hopefully) if one wants an NPC to have STR of 14 BUT with a Mod of +4 because of some special-to-the-npc "thing", that they would instead just give the NPC some ability/trait/etc that confers the +x to Ability feature instead... but I suspect simply modifying the Mod in parens is much easier for FG to work with.

If this is something anyone does or we think might be done... maybe I will change my code to simply output a warning note when the calculation doesn't match the input to make sure you meant it that way.

June 22nd, 2016, 03:13
I just use the auto function built into FG and live with whatever results it gives.

If it is off a bit then I don't really care, the players might take a little longer to level or might level a bit faster but one less thing to worry about is worth it.

As for ability modifiers, I have seen some in Fifth Edition Foes that didn't follow the calculation but left them as they were when parsing it as I figured the author had reasons. If I ever needed something out of the norm I would just make changes to the NPC sheet as needed since it would be a rare thing.

June 22nd, 2016, 06:01
I checked, oddly enough, it seems that although there appears to be both <modifiers>, a string element and <bonus>, a number element when created by PARSE and dragging from MM respectively - changing the value in the xml for the mob/bonus does not change what is displayed in the GUI.

So it seems it also already calculates the values. Therefore, if I understood this - it means the modifier/bonus element is effectively ignored (maybe once was used and now deprecated) and I should move along... ;) I figure ill generate and point out diff so if someone thinks they are changing it, they will get a heads up it is ignored.

PS - Anyone know what, if anything, matters when choose modifier vs bonus element names?

June 22nd, 2016, 10:20
Indeed, par5e does ignore the modifier in the .txt file and actually calculates what the ability modifier should be - unless you place a number in the modifier box without a + or a - when it has a hissy fit and doesn't calculate properly.

There is no reason under the rules why a character would have anything other than the correct modifier. If there are modifiers that are different then I suspect that is an error. XP is always a based on CR.

June 22nd, 2016, 14:06
Great, that gives me and excuse to stick with my original code ignoring the calculated fields.

Originally, I would just do a lookup of he Challenge string to ensure it was a defund value and retrieve the corresponding XP value at XML generating time later. Same with Scores.

My parser when I tried actually using the Mod input, accepted +2,-2,2,+0, but not -0 (simply because it doth offend me)

so, I'll output "bonus" for the mod tag since it is numeric like"score" unlike parse's "modifier" tag which is string.

June 22nd, 2016, 21:31
Interestingly enough when cross checking Par5e vs my parser output, I noticed another number vs string element type change in NPC output.

Upon checking, I realized it was because I chose Cmp this time instead of Ref. Now, I wonder - I've never seen a filled in <source> field so I cannot speak to. the data type that should go in there.

But it does make me wonder if each time this occurs it is an indication of a field that is unused by modern FG app? maybe the difference exists because it once was type x then was changed to y but since it is not looked at in general or under one of those 2 sections, it isn't updated? Just tossing out a wild guess...not a clue.