Data Class Two FAQ

From PCGen Wiki
Jump to: navigation, search

This is another Lesson follow up by one of our new LST coders.

Hi, Andrew,


  • Some follow-up questions to Class #2:
  • Upper/Lower Case - Some things are in all upper case and some are in upper/lower. “OUTPUTNAME:Fluffy Bunny, [NAME]” has a mix. Is there a rule of thumb about when to use all upper and when to merely capitalize words?
    • ANSWER = Yes, UPPER CASE is ALWAYS used for the following - ALL TAGS. HARDCODED variable Names (CL, TL, HD). Mix Case is used for the the fluff text, Proper Names. Our Policy is each new Word in a Spell Name or Class Name, or Feat Name all start with a Capital Letter for neatness, the Exceptions are 'of, and, the' Unless it's the Beginning of the Name "The Great Bambino" vs. "Bambino the Great". For Variable Names we prefer each word is Capitalized to make reading it easier, example "TheGreatBambinoDieSize" is much easier to read then "thegreatbambinodiesize". A confusing example is the ABILITY tag, so I'll show that one - "ABILITY:Category|AUTOMATIC|Ability Name" So the second part is the real name of the actual Ability Category we are calling.



  • Delimiters - In your first example, some tags use pipe characters as delimeters, some use commas, some use periods, and some use a mixture. Is there a rule of thumb?
    • ANSWER = Sorry, the standards are being standardized as we speak to this day. It's taken a bit to get here. The current rule of thumb is to REFERENCE the Docs, as those have the Exact Format you should use for each and every tag.



  • Possible Typo In HITDICEADVANCEMENT Example - I think you meant it to read
  • HITDICEADVANCEMENT:10,20,30
  • Not
  • HITDICEADVANCEMENT:10,20,20
    • ANSWER = No, I actually meant 10,20,20. Let's see what the docs say:
  • Tag Name: HITDICEADVANCEMENT:x,x
  • Variables Used (x): Number (Hit Dice)
  • What it does:
    • The last number in the comma delimited list is the highest HD the creature can advance to, through HD advancement. Unlimited HD advancement is indicated by using an asterisk (*) in place of the final number.
    • All the numbers preceding the last number each indicate the highest number of HD the creature can have before before its size increases by one category.
  • This means my max HD attainable is going to be 20 HD for the creature. My creature will increase two sizes and then max out it's HD. 1 through 9 HD it is the original size, 10 through 19 HD it's one size larger, at 20 HD it's now two sizes larger and maxed.



  • AUTO vs. ABILITY - When does one use AUTO to automatically grant something vs. using ABILITY? (I thought Feats were now just special types of abilities.)
    • ANSWER = True, Feats are another ability, but I also mentioned we treat feats differently. I always use AUTO:FEAT to grant a Feat UNLESS I need the functions only ABILITY can offer, being the PRExxx support mainly.


  • Splitting Definition From Calculation - Why are variables generally set up in a two-step process, such as
  • DEFINE:BunnyMutantTimes|0
  • BONUS:VAR|BunnyMutantTimes|BunnyMutantLvl/3
  • Instead of
  • DEFINE:BunnyMutantTimes|BunnyMutantLvl/3
    • ANSWER = You may DEFINE a Variable by that method, however, we prefer the standard two-step process for the reason of simplicity. Let me ask you this... Say you are trying to cancel out 'BunnyMuntantTimes' which was 'BunnyMutantLvl/3' how would you do that when it's DEFINE is saying it's whatever value 'BunnyMutantLvl/3'? Would your counter 'BONUS:VAR|BunnyMutantTimes|-BunnyMutantLvl/3' work? It's a nasty case example as two things are potentially possibly. Hence the reason we do the two step. If the Variable is a Default of 0, you can counter anything being granted to it. If the Default is greater or lower than 0, then you're entering headache territory. Does this mean we don't do DEFINE other than 0? No, we use that for Variables that are normally set... PoisonDC is a good example 'DEFINE:PoisonDC|10+(HD/2)+CON it's pretty static.


  • Substitution Markers - Do they have to substitute for a variable name or can one put the calculation directly inline
  • CATEGORY=Special Ability|My Ability.MOD
  • DESC:%1/day nifty thing happens|My Variable
  • DEFINE:MyVariable|0
  • BONUS:VAR|MyVariable|42
  • versus
  • CATEGORY=Special Ability|My Ability.MOD
  • DESC:%1/day nifty thing happens|42
    • ANSWER = You can directly place the number. You can even do formula calculations like 10+CON right there, However, if you do that, let me ask you this, with your existing '42/day nifty things happen' what if I get an ability that adds +1 to that to become 43/day, how would you do that in your above example? Hence, the Variable Name is more versatile, since all I need to do is "BONUS:VAR|MyVariable|1". Also, in your above example you used a SPACE in the Variable Name, that's on the No-No don't do that list. I assume it's a typo as your DEFINE and BONUS:VAR use it correctly.



  • Possible Typo - Was there really supposed to be a colon in front of BunnyMutantDie in its bonus tag?
  • CATEGORY=Special Ability|Mutant Abilities ~ Dire Bunny.MOD
  • DESC:%1/day, the Bunny may cause it's eyes to glow red and cause %3d%4 in %2 targeted opponents|BunnyMutantTimes|BunnyMuntantTargets|BunnyMutantDie|BunnyMutantDieSize|PREVARGTEQ:BunnyMutantLvl,12
  • DEFINE:BunnyMutantDie|0
  • DEFINE:BunnyMutantDieSize|6
  • BONUS:VAR|:BunnyMutantDie|(BunnyMutantLvl,15)
    • ANSWER = No, that is a TYPO, I figure only one out of how many words, I'm doing pretty good.


  • ABILITYCATEGORY Vs. TYPE - You wrote, “Now, you'll see I placed the TYPE:MutationGrowth, that means any Ability with CATEGORY:Special Ability and TYPE:MutationGrowth will populate my ABILITYPOOL.” But in your example, ABILITYCATEGORY is also equal to MutationGrowth. So why do we need the TYPE also?
    • ANSWER = ABILITYCATEGORY does NOT equal the TYPE. That's the Name of the Ability Pool. Without the TYPE or ABILITYLIST you're Ability Pool will remain empty.
    • ABILITYCATEGORY:No Mutants <> TYPE:MutationGrowth
    • That will pull in any Ability with the TYPE 'MutationGrowth', that's important to understand, you can have multiple ability pools that bring in the same abilities.


  • SpecialQuality - What does the “SpecialQuality” in TYPE:MutationGrowth.SpecialQuality do?
    • ANSWER = It's a Special Tag for the Output Sheets, it will place that ability in the OS Block 'Special Quality'. "SpecialAttack" will do the same for the OS Block 'Special Attacks'.



  • ###Block vs. #Block - When do you use one vs. three hash marks? Does one start and one end a block?
    • ANSWER = As far as PCGen is concerned, there is no difference. Same with PrettyLST, the difference is for the Monkey that comes behind and does maintenance. It's a visually appealing deal basically. My standard, is Triple Hash '###' is for a Major Block or Section, and the Single hash '#' is for a sub section in that.



  • ABILITY Tag - Would you please talk through what the three fields of ABILITY:Special Ability|AUTOMATIC|All Automatic Proficiencies accomplish and what are valid inputs to each?
    • Variables Used (x): Text (Ability category)
    • Variables Used (y): Text (Ability nature)
    • Variables Used (z): Text (Ability name or key)
    • Variables Used (z): TYPE=Text (Ability type)
    • Variables Used (z): .CLEAR
    • Variables Used (z): .CLEAR.Text (Ability name or key)
    • Okay, so we have 'ABILITY:' that's the tag, the next part is 'x' which is the 'Ability Category' our choice is whatever Ability Categories we've created in the Ability Category file, as well as those defined in the GameMode MiscInfo.lst file.
    • Next we have 'y' which is the Ability Nature, broken down the Natures are 'AUTOMATIC', 'VIRTUAL' and 'NORMAL', of those three 'NORMAL' will actually deduct a Pool Point.
    • Finally we have 'z' which is where we select the Ability direct by name, or we can select a group by TYPE. You can actually have a mixture of both TYPE=z and Ability Names.


Many thanks,

Allen