PDA

View Full Version : CR and XP?



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

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

Varsuuk
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?

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

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

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