Pathfinder RPG Best Practices

Testing

It's up to you to ensure that content you submit meets a minimum level of quality before sending it to us. Here are the basics you need to hit before submitting:

• Description text should match the book, without any extra line breaks or incorrect characters
• Any things should have their appropriate effects when added to the hero. If the thing has multiple different effects under different circumstances (for example, different effects at different character levels), make sure to test every one of those circumstances to ensure it works correctly.
• No things you create should report script errors when added to the hero, even if it's in a situation it wasn't designed for (for example, adding a class-specific feat shouldn't report errors if the class isn't present). If a thing has different effects under different circumstances, make sure none of those circumstances cause errors to reported.
• Statblocks for monsters should match the book, unless Hero Lab is "right" and the book is "wrong". Hero Lab should display special abilities in the same categories as the book does, and should correctly display other stats.

The only way to test most of these is to test each item individually. For a class ability, add the ability, make sure it has the right effects, and if it's level dependent, increase or decrease the class level to make sure it doesn't report any issues. For races, turn on the statblock summary window, and compare the statblock in Hero Lab to what's shown in the book - you'll be able to see any differences immediately.

The Quick Reload shortcut, Ctrl+R should let you test these quickly. To increase the speed at which you can reload the data files, you can disable packages you don't rely on via the Develop menu -> Choose Supplement Packages.

General Issues

What content from an Adventure Path issue should be added?

Add any content which could be used by a player during the course of the AP. This usually means all magic items in the Treasures section, or any feats/traits listed in the first issue of the AP. In most cases, the bestiary section does not need to be entered, unless one of the monsters within can be used as a familiar or animal companion to a PC. Another exception is that some Construct races may have information on the cost to buy them, and in that case the race and the minion object should both be created.

Some APs have sections which contain a deity entry, with special spells and items related to that faith which need entering.

Reusing Content

It is absolutely encouraged that content be reused. In fact we've been making efforts to enable more variable abilities to be a single, moddable special rather than having to create a new version each time. This is especially evident in things like the "Gaze", for which there are many many different versions. Why is it important that you re-use an old ability rather than creating a new one?

Reasons

1. It reduces clutter when folks are using the editor, which means they are less likely to bootstrap the wrong thing.

2. If we need to update something about an ability (such as how it interacts with another ability), we only need to do it once

3. When using pre-requisites that search for that ability, you need only check for one thing.

Generalizing Content

This may lead to some slight wording awkwardness where the re-used ability refers to its original race or class name. While this isn't that big of a deal, it's best to "generalize" the description of the re-used ability, removing references to specific origins. For example:

"As a standard action, Paladins of the Holy Son can blind evil-doers in 100 ft for 1 minute (DC 10 + 1/2 Paladin level + Charisma modifier)."

Could become:

"As a standard action, members of this class can blind evil-doers in 100 ft for 1 minute (DC 10 + 1/2 class level + Charisma modifier)."

Helpful Tools

• The #appenddesc macro modifies the description of a certain thing, to add extra text onto the end. It has the advantage of even showing this modification before a thing is added to the hero, and it applies to all copies of that thing. The fact that it must apply to all copies is a disadvantage as well, as it may hit others to which it doesn't apply. Text added with the macro is placed after the normal description text, but before text from DescAppend (see below).

1. appenddesc[UniqueID,"{b}Modification from ABILITY NAME{/b}: Added Text"]

• A more targetted option is the DescAppend field, which allows a non-unique special to be bootstrapped from several different sources with a custom description each time. This is useful for many racial specials such as Poison, Disease, Gaze, Breath Weapon, or Immunity to Magic, which share a common name and mechanic but can vary wildly in effects.

• In some cases the content you may want to reuse is unavailable because it is normally added to a different table on the hero. This is especially the case when an archetype grants access to a different class' Custom Special Abilities (Rage Powers, Rogue Talents, etc), but they would normally go in a table the archetyped class is already using for its own custom special abilities. In this case, you need to override the candidate expression for one of your class's empty custom special ability tables, to use the new sort of ability.

For example, a Magus is already using his Primary Custom Special Ability table for Magus Arcana. With the Hexcrafter archetype, he gains access to Witch Hexes (which are Primary abilities for the witch), but since they don't draw upon the same pool of selection he can't just lump them into the same table. Thus he overrides his secondary table's candidate expression to use primary witch abilities like so:

linkage[varies].field[cCstS2Expr].text = "(SpecSource.cHelpWit) & !Helper.Secondary & !Helper.Tertiary & !Helper.Quaternary & !Helper.Quintenary"

What should be shown on the Specials Tab?

Examples

Case 1 If the ability has a constant, calculated bonus only then it is not shown on the specials tab or character sheet because its effects are already accounted for.

I.E: This ability gives +2 to Acrobatics.

Sample Abilities: Keen Senses, Armor Training

Case 2 If it has a bonus which applies in certain situations, but doesn't require the character to take an action, then it gets a situational applied to the target ability and is shown on the specials tab/character sheet.

I.E: This ability gives a +2 to Acrobatics to jump

Sample Abilities: Elven Magic, Favored Enemy

Case 3 If the ability has a limited duration and requires some action to begin (even a free action), then it should be shown on the specials tab/character sheet and have an activation on the In-Play tab

I.E: As a swift action, this ability gives +2 to Acrobatics for a number of rounds equal to your dexterity modifier (minimum 1 rd).

Sample Abilities: Smite Evil

Some abilities have multiple elements, each of which may fall into a different case above. For example an ability could grant a +2 bonus to Spellcraft checks (case 1), and could be activated to add your Int modifier to Use Magic Device checks for 1 minute (case 3). As long as the ability has at least 1 part which should be on the Specials tab, show it. Anything shown on the Specials tab should have a summary (see Constructing a Summary for tips).

What should be sourced?

Any thing which the user chooses from a menu and adds to their character should be sourced. Any thing which is not added by the user (usually because it is bootstrapped to something else and brought along with its root), should NOT have a source.

The following types of things are usually sourced

Custom Special Abilities

Custom Racial Abilities

Custom Race traits

Archetypes

Feats

Traits

Classes

Races

Magic Items

The following types of things are usually NOT sourced

Racial Specials

Generic Abilities

Class Abilities

Constructing a Summary

The purpose of a summary is for the user to be able to tell at a glance what a thing does mechanically. It's a hard thing to do, making summaries both small enough to fit in the limited space, yet keeping their information good. Foremost in your mind should be "What elements need to be conveyed?", and "How can they be conveyed most efficiently?"

Common Elements (in order)

Action required ("as a swift action", "over 1 min", "as imm. action")

Limiting Situations ("on a hit", "when crit", "if foe is flat-footed", "when underground")

Ability range/area/targets ("foe in 100 ft", "allies in 30 ft", "100 ft line")

Ability effect ("dazed", "10d6 fire", "gain +2 morale bonus to AC")

Ability duration ("for 1 rd", "until your next turn", "until atonement")

Resisting the ability ("(Will neg)", "ignores DR")

The order above is the preferred order. For example "As a swift action when underground, foe in 30 ft has -2 to AC for 1 rd (Will neg)."

Not all abilities will have all these elements, and some will have far more content than you'd like. One trick is that information in the abilities livename does not need to be in the summary, so if you are short on space you may be able to shift info like duration or damage into there. Usage info ("X/day") and DC is already shown in the livename automatically, so those should almost never be shown in the summary. Also keep in mind that you don't need to follow proper grammer if space is tight, nor should you fear abbreviations as long as your information is still clear. The human brain is remarkably adept at filling in the blanks.

Common Abbreviations

Memorized -> mem

Caster Level -> CL

Weapon -> wep

Critical -> crit

Metamagic -> MM

Round(s) -> rd(s)

Minute -> min

Bonus -> bon (often omitted entirely)

For example, here is a "decompressed" version of the Wild Arcana mythic ability's summary.

As a swift action, use 1 mythic power to cast any arcane spell from your class lists with a +2 bonus to caster level. The spell doesn't need need to be known or memorized.

And here is the shortened form

Use 1 power, cast an arcane spell from your class list at +2 CL (doesn't need to be known/mem).

A Warning

Constant, calculated bonuses should never be mentioned in a summary. That runs the risk of confusing the user and resulting in adding the calculated bonus again. For example, an ability which added 1/2 your class level to Perception checks and the same amount to your Survival in the desert, the Summary would mention the bonus to survival, but not mention the perception bonus.

Situational vs Activation?

In general, if something is always present and active with no action required by you, but only affects you under specific circumstances, use a situational. An example of this is Trap Sense, you don't need to do anything to benefit from it and are always benefitting from it, even though the circumstance in which it matters (when you are being attacked by a trap) is relatively rare.

If something requires an action by you (even a free one), and then affects you for a limited duration thereafter, use an activation. An example of this would be Smite Evil, you activate it and then it gives you a bonus until that foe is defeated.

Creating Races

Races are among the most complex, fiddly things in pathfinder (especially high CR), but also one of the most important to do well. Since they are so complex there is little general procedure that can be outlined, and thorough testing is the most reliable way to get things done.

Racial Variants

If you can avoid it, do not create two versions of the same race. It is better that a racial variant be indicated by the addition of a Racial Custom Special ability than by creating a whole new race which only varies in a few abilities. Racial Custom Specials are capable of replacing and disabling existing racial specials, just like Alternate Racial Traits do, and that combined with eval scripts on the RCS to manipulate the race's fields, plus bootstrapping new abilities will usually get you where you need to go.

How should you decide whether a variant warrants being split off into its own race? There isn't a hard or fast rule, but a good indicator is whether the variant has a full statblock spelled out where it is described. If the variant is simply described in a bit of text about how it differs from the base, then you're better off adding a RCS for it.

Note that we haven't always been the best at enforcing this, but it is the standard nonetheless.

PC Races vs. Monster Races

A "PC Race", for our discussion, is any race which has no racial hit dice and is thus solely defined by its class levels. Halflings and orcs would both be PC races, even though orcs are usually antagonists and unlikely to be played as a PC.

A "Monster Race" is any race with racial hit dice, regardless of the likelyhood of their taking class levels. Giant Ants are mindless and would almost never have class levels; Ropers are at least intelligent and might rarely have class levels; Gnolls are humanoids and are quite likely to advance in class levels, but all three have racial HD and are considered monster races.

Racial Spell-Like Abilities

SLA's appear frequently for monster races, and less so for PC races. There are several things to keep in mind when bootstrapping a SLA.

Marking PC Race Spell-Like Abilities

Any spell like ability bootstrapped to a PC race should have the Helper.RacSpAbil tag added to the bootstrap. PC race SLA and Monster race SLAs have a different format in the official paizo statblock, and are shown in different tables, and this tag is thus necessary for proper formatting.

Other than that, you may want to add further tags to mark them for this specific race (which is usually done either with a Custom or SpecSource tag). This is commonly seen in cases where the PC race only gains the SLA if they meet a certain minimum attribute (such as the Gnome race needing Charisma of at least 11 to use its SLAs). Bootstrap conditions cannot be used to enforce this because attribute values are determined so late. Instead an eval script must detect the attribute, and if necessary seek out the marked SLAs to hide them with a Hide.Spell tag. Marking the target SLA prevents the eval script from accidentally affecting other spell like abilities gained from feats or other sources.

Spell-Like Ability Name

Many spell like abilities have limitations or modifications in how they work, and these should be recorded in the livename field when bootstrapping, within parenthesis after the name. For example, many outsiders have the ability to use greater teleport as a SLA, but only on themselves and 50 lbs of gear, so this spell like ability would be bootstrapped with a livename of "Teleport, Greater (self plus 50 lbs. of objects only)"

Warning The hero lab engine has automatic logic to rearrange the comma in between the spell names when generating a statblock name (to make "teleport, greater" -> "greater teleport"), but this will also catch any comma in the mod text. For this reason, you should try to avoid placing a comma in the parenthesis if you can. If you do not avoid that, you should set the sbName field specially when bootstrapping, which will prevent the automatic logic from running.

Spell-Like Ability DC

Unless specified otherwise, SLAs are assumed to calculate their DC as 10 + Spell Level (Sor/Wiz/Clr version) + Charisma modifier.

What if the DC listed isn't the DC I want for this monster?

• Check the level of the spell you have bootstrapped. Is there a version which is of higher or lower level which will correct the descrepancy? Keep in mind that a SLA's level is assumed to be either the Sor/Wiz or Clr level version of the spell. If the Slow spell you bootstrapped has a DC 1 lower than you expected, perhaps you mistakenly bootstrapped the Summoner's 2nd level version (instead of the 3rd level sorcerer version). DO NOT switch from the assumed version to a wacky other class's spell in order to fix a DC issue.
• Check to see if the monster uses a different mental attribute for its spell like abilities than Charisma. This is probably something which should be stated somewhere in the monster's description, and if it isn't you should check among all its listed SLAs with a DC. This association grows stronger the more abilities that support it, and the wider the difference between the attribute modifiers. If there are 6 different SLAs, and all of them are off by the difference between the Wisdom and Charisma modifier then I would be comfortable making that call. If there is only 1 SLA with a DC shown, even if the difference fit, I would hesitate to make this change. Furthermore, if the DC difference is only 1, then it is more likely that an early version of the monster had a slightly higher Charisma which got adjusted down and the editors forgot to lower the SLA DCs appropriately.

If you need to adjust the associated attribute to something else, you can bootstrap the SLA with a StandardDC tag for the new attribute. For example, StandardDC.aINT will make the DC be calculated by Intelligence rather than Charisma. This is on a bootstrap by bootstrap basis, so doing it in one place will only affect that one SLA.

• If the DC is 2 points low, check to see if the monster has Ability Focus for this SLA. If so, does your current version have that and has it selected the right target?
• Check if the monster has some other racial ability which could be increasing the DC of spells of a certain school or type. Is that functioning or not?
• At this point, you can probably assume it is a mistake on the part of the book's creators, note it down for reporting, and move on.

I do not recommend ever doing so, but you can also add a flat bonus or penalty to a bootstrapped SLA's DC by placing a value in the sDC field when bootstrapping.

Spell-Like Ability CL

In most cases the CL of a SLA will be automatically calculated. For those bootstrapped to a race the assumption is that they will be based on the value of the rSpCastLev field (which can be set specially but defaults to the number of racial HD). There are several tags which can be applied when bootstrapping to change that. All of these must be combined with the Helper.SpellLike tag on all SLAs.

• Helper.ClsCastLev makes the CL of the spell like ability calculated based on total class level rather than the rSpCastLev field on the race. It is used for many of the ARG races that have spell like abilities (such as the Ifrit and the Aasimar).
• Helper.HDCastLev makes the CL of the spell like ability calculated based on total hit dice (both racial and class) rather than the rSpCastLev field on the race. HDCastLev overrides ClsCastLev. It is used for some spell like abilities from feats in the ARG (such as Magical Tail).
• Helper.TrCastLev makes the CL of the spell like ability calculated based on mythic tier. TrCastLev overrides both ClsCastLev and ClsCastLev. It is used for some path abilities from Mythic Adventures (such as Commune with Power).

Testing Created Races

Testing should be carried out in a branch of the pathfinder files free of .user files, to prevent errors on load when someone else opens any prepared stock portfolio.

Step 1: Open a new portfolio and on the configure hero form set the character type to "NPC" and the alliance to "Enemy of Party". If this is a PC race with adventuring class levels, set the ability array to "Heroic NPC (15/14/13/12/10/8)"

Step 2: Go to the Background tab and select the race you wish to test. Give it a quick look to make sure that the italicized text at the top is correct, and that the description for the race is there and correctly formatted.

Step 3: Set up the race to match the statblock. For PC races this usually means setting the attributes, adding class levels and making choices for those classes (such as memorizing spells), as well as adding equipment shown in the statblock and equipping it. If the tactics section of the statblock mentions that a certain spell effect is assumed to be on the hero, add that to the adjustments tab. Do the same for any constant spell like abilities which may be present (if said abilities are likely to affect the statblock). Many monster races have no class levels and eschew equipment, so you may be able to skip this step entirely.

Step 4: Go to "File -> Output Hero Statblock" and then compare the generated statblock to the one shown in the book. Go line by line, item by item for this initial check. Make note of any discrepancies between the two statblocks, such as a racial special being shown on the wrong line (or not at all), differences in naming (for racial specials, SLAs, etc.), attack bonuses not matching, skill totals not matching, and so on.

Step 5: Investigate and fix the issues you found in step 4.

• Skills are a frequent issue between HL and official statblocks. Here are some tips at resolving them:

Look for patterns in the skill ranks spent. Most authors don't sprinkle around skill ranks willy-nilly, either maximizing some skills and putting others at a lower level (usually half), or dividing ranks more or less evenly among all skills (all half, all max, so on). In any of the following steps, if you can bring the ranks closer to a pattern then you're probably going in the right direction.

For monster races, you have a wide latitude in assigning class skills, so if the bonus is low by three and it isn't already a class skill, making it so can resolve things. Similarly, if the monster seems overspent on skill ranks by a multiple of 3, then look for skills which you can make class and drop by 3 ranks to get closer to parity.

For PC races, Hero lab is often more inclusive of skill bonuses and penalties than paizo's statblocks are. For example, paizo statblocks usually assume a character has tools to use any craft skills, even if none are listed in the gear section. The skill total also usually doesn't count the bonus for mwk tools either, even when those ARE listed in the gear section. Hero Lab applies the bonuses to disable device from a rogue's trapfinding ability, while the official statblock does not, and so on. With time and a little practice you'll get a sense for what HL adds that paizo doesn't and learn to filter that out when looking for patterns.

Paizo applies Armor check penalties inconsistently from statblock to statblock. The general assumption seems to be that all characters are lightly encumbered, so if you can store any non-combat gear elsewhere (like on a mount or dropped to the ground) in order to reach light encumbrance, do so. If you can't get to light encumbrance without dropping things like weapons and armor, then make a note of that to report. If you're still having trouble getting the skill ranks to work out, try unequipping any armor and going to light encumbrance. If you can make the skill totals work out that way, then it is likely that paizo forgot to add the ACP when building the statblocks, so re-equip the armor and make a note for Paizo stating the discrepancy.

• Generalized, re-used racial specials often need to be set in a special way so that they create their name and apply their effects in a consistent manner. If you've bootstrapped one and it doesn't seem to be working like expected, try copying the special and looking at the eval scripts on it. Or make a copy of a monster which has the same ability and see how it does the bootstrapping.
• Small attack bonus mismatches seem to be most commonly from development tweaks when paizo is creating a monster or NPC and decide to switch up the attributes but forgetting to adjust the follow on stats. In this case you can assume HL is in the right and make a note for Paizo.
• Natural attacks are also a place where we have some leeway, like with class skills. If you've bootstrapped a natural attack which is normally secondary, but the official statblock shows an attack bonus 5 higher and the full strength bonus to damage, then it is likely that for this monster it is a primary attack and you can bootstrap it with Helper.NatPrimary. It is rarer for a normally primary attack to be secondary for a monster, but you can accomplish that with Helper.NatOverSec. You should only apply that if the monster is not wielding manufactured weapons in combination with their natural attack, as Hero Lab automatically forces natural attacks to secondary when that happens.

Step 6: Repeat step 4 and confirm all issues have either been fixed or properly noted for paizo.

Step 7: Take the time to examine the character as shown in hero lab. For example, check the specials tab and make sure the racial specials of this creature have appropriate summaries. If the race has any activated abilities, test them out on the in-play tab as well. If you discover anything wrong during this step, fix it before moving on to the final step.

Step 8: Now that everything is done, create the stock version of this race. Go to the NPC tab and if this is a Monster race, hit the Default button to populate the ecology entries for the character. Make sure they are in sentence case (if they aren't then adjust them on the race and hit the button again). PC races usually have tactics entries (such as Before Combat, During Combat, or Base Statistics) which you add on the NPC tab, and further description text (the stuff after the statblock) which you should copy onto the Personal tab. Finally, use "Develop -> Prepare Portfolio for Distribution" and save or re-save the portfolio (if you hadn't already).

Creating Magic Items

General Name Issues

Magic items are named in sentence case, with the first letter capitalized and all others (save proper nouns) not. Artifacts tend to be an exception, and you should look at the description text of an artifact to see how it is capitalized there.

Examples

Cloak of protection +1

Boots of striding and springing

Bastard's sting

Baba Yaga's besom

Thundering blade of the house of Sugimatu

Deskari's Tooth

Specific Magic Armor/Weapons

Most specific magic arms have item powers or materials, which should be added through the editor by clicking on the Materials and Weapon or Armor Powers buttons. You can also click on the "Gizmo" button on the upper right, and bootstrap that material or power to the listed entity. In many cases, the bootstrapped picks will take care of most of the coding needed.

Testing Created Magic Items

Once you have hit the test now button or reloaded the system, follow these steps to make sure the item is correct. For simplicity, testing should usually be carried out on a blank character, so that any changes will be immediately obvious.

• Step 1 Go to the appropriate tab and table to add the item and visually inspect it in the selection window. Compare the heading information (like item caster level, aura, price, and so on) to the source and make note of discrepancies to correct.
• Step 2 Scan the description for errors like incorrect structure (linebreaks where there should be none, paragraphs smashed together), typos (often there is a space between f and l, caused by copy paste from pdfs), missing italics of spell/magic item names, missing alternate ability info (as granted by SpInfo and DescInfo tags) and so on.
• Step 3 Verify the item is correctly sourced.
• Step 4 Add the item to the hero and confirm that any eval scripts on the item behave as expected. If it is something which requires being equipped, make sure that its effects are not yet seen. Toggle the equip state on and off and make sure it works in both cases. If the item has effects which are "always on" and so it isn't equipped, you can do the same by adding and deleting the item. If the item must select something else, verify the list of selections behaves as expected as well.
• Step 5 Check alternate tabs. If the item has charges or bootstraps item spells, go to the In-Play or Spells tab to verify that they are set up correctly. Be especially careful of spells, which may have limitations that should be spelled out in the livename.
• Step 6 If the item should be shown on the specials tab, go there and take a look at it's summary. If the summary is too long and gets cut off, try to condense it further so all pertinent info is shown (see Constructing a Summary).

Entering Stock Heroes

Populate the NPC tab

• Make sure the sourcebook name and SKU is set properly for the character. This is the book that this specific NPC is printed in. For example, if the NPC was printed in "Goblins of Golarion" but uses a race from the Bestiary, enter the sourcebook as "Goblins of Golarion", not the Bestiary.
• Add any appropriate tactics, ecology, etc NPC information from the NPC's entry.

Entering Encounter Libraries

These guidelines apply to people who are building Hero Lab encounter libraries, typically for Pathfinder Modules and adventure paths.

There are two deliverables which must be submitted before a project is completed, which should be worked on in parallel.

Deliverable 1 - Create portfolios for every encounter and NPC in the module

Every statblock, or partial statblock, printed in the module / adventure path / whatever must have a portfolio created in Hero Lab. The portfolio filenames are what appear in the Encounter Library, so they should be chosen based on the rules in "step 1" of the "testing encounter libraries" section below.

Portfolio names must be correct before we accept this deliverable - don't submit files with names like "encounter1.por" "encounter2.por" etc, as it makes things harder to QA.

Don't create a portfolio unless there's at least a partial statblock present in the module. A partial statblock will typically show the basic stats of the monster, then refer you to a Bestiary - for those, you can import the monster from the encounter builder, and make any changes as required (for example, you might need to apply a template to it, or swap out weapons).

If an encounter includes multiple copies of an NPC, import that many copies into the portfolio. If you need to make changes (like adding templates) it will probably be easier to make one, apply any changes, then duplicate it from the Portfolio menu instead.

Some NPCs (e.g. Pavo Vos on page 18 of Fangwood Keep) will need a full Hero Lab character created for them. In those cases, create the character. Don't create statblocks for NPCs we don't have enough information about. For example, if the text mentions "Merlin (elf wizard 4) might be hanging around the sanctum", don't create an NPC for him - we can't, because we don't know anything useful about him to create the NPC with.

When building an NPC, you'll need to reverse-engineer the Hero Lab character from the statblock. For example, the character's hit points will come from a combination of class levels, favored class bonuses, and other sources - use average hit points for the class levels (which on NPCs, alternate from one level to the next). Generally favored class bonuses will be used to add additional hit points, but not always.

Make sure all characters you create in all portfolios are set to "NPC" and "enemy of the party" on the configure hero form.

For any NPC in a portfolio (either imported from the encounter builder or created by yourself), check that the statblock output matches what's shown in the "Output Hero Statblock" window (found in the File menu). If anything there is wrong, try to figure out why - is it a mistake you made, or a mistake made by the authors of the encounter?

A convenient way to check whether the statblock is correct is to turn on the "statblock summary info window" for the portfolio - you can find it about 80% of the way down the "hero settings" in the configure hero form. Turn on "show full statblock summary window" and the first info window will be replaced by the character statblock. This allows you to check things without having to go to the File menu every time.

In general, set "base values" before "derived values". For example, set the character's ability scores first, then their skills - if you change ability scores after setting their skills, the skill values will change.

If you make any tweaks to the character after checking the statblock, you need to re-check the statblock for any changes. Remember, if you change an ability score, that can affect skills, ability values, etc.

Set the "buy for free" checkbox to buy the character's gear for free, then set their "starting cash" to be any cash the portfolio indicates they have.

Many NPCs will list "longbow with 20 arrows" for gear - to make that appear correctly on the statblock, add the longbow, add the arrows, then put the arrows "into" the bow using the "gear" button (the little bag) on the arrows.

Remember to set important things like composite longbow strength bonuses, holy symbol details, etc.

If you find differences between Hero Lab's statblock and what's in the book, try to do what the creators "meant", even if that means the character will have validation errors. Examples:

1) if the character has too many feats or skill points, that's fine - just do what the module says. The GM will see any errors when they import the portfolio, and it's up to them what to do about them.

2) If you can't get the skills to match up for an obvious reason, then don't worry about the problem. For example, a common issue is that NPCs have too much gear, so they're encumbered, so their skills in HL are lower than the portfolio says they should be - that's a case where we should leave them at the "correct" values and let the GM decide what to do. Another common issue is the creator might have forgotten that a skill is a class skill, leaving it 3 points off.

Deliverable 2 - Notes

As you work on the module, create a list of any differences between what the module shows, and what Hero Lab shows. For example, if skills are off, note that, and see if you can figure out why it happened - that might lead you to think of a different way to do them so they'll be correct. This file is important because it will be used by whoever is checking your work.

Submission

Submit both pieces of the project to us - portfolios and notes file. Don't submit until the portfolios are complete and checked to make sure they're correct.

Checking Encounter Libraries

Once both deliverables for an encounter library have been submitted (see above), we'll a different person to check the work. If you're checking someone else's encounter libraries, you need to find places they did something wrong.

Compare the statblocks listed in the module with what's in Hero Lab - do the details in the module match what's in HL? If not, consult the notes file you got along with the portfolios and see if the author noticed the problem and provided an explanation. If there is a note about the issue, is it a good one? Can you think of a way to make the statblock match the portfolio better? If there isn't, make a note of it yourself.

In addition to checking the actual portfolios, check everything from steps #1-3 of the "testing encounter libraries" section below. Make a note of any issues.

Once you've looked over everything in the module, make your list and send it to us. We'll pass it on to the original author, who will fix things. They should get you a new version of the module once the problems are fixed - once that's done, verify the issues you noted are fixed, or that you agree with the author on why they shouldn't be fixed. If there are disagreements, contact us and we'll resolve them.

Testing Encounter Libraries

Step 1 - Check Structure & File Names

Examine the layout of the folder. Are the portfolios divided into folders which follow (more or less) the organization of the book, like others in Hero Lab's encounter library?

For example, most AP issues are divided into parts, so the files may have one folder per part, with perhaps sub-folders for different encounter areas. While examining structure, look for typos in the names of portfolios, and verify that they match the standard format:

pXX - Map key (if present) - Encounter Name (CR Y)

XX is the page number, and single digit pages should be preceded by a 0 to bring things to a minimum of 2 digits (so that page 11 sorts after page 09). Y is the challenge rating of this encounter. Some aspects may be omitted (for example, there may be no map key for the encounter), but each portfolio should include at least the page number and Encounter name.

Here's an example from Rise of the Runelords:

Chapter 1 - Burnt Offerings\Part 1 - Festival and Fire\p16 - Goblin Pyros (CR2).por
Chapter 1 - Burnt Offerings\Part 1 - Festival and Fire\p17 - Die, Dog, Die!.por
Chapter 1 - Burnt Offerings\Part 2 - Local Heroes\p19 - The Desecrated Vault (CR ½).por
Chapter 1 - Burnt Offerings\Part 3 - Glass and Wrath\p33 - B1 - Guard Cave (CR 2).por
Chapter 1 - Burnt Offerings\Part 3 - Glass and Wrath\p34 - B4 - Washing Pool (CR 2).por

Note how there are separate folders for parts 1, 2, and 3, which can have multiple portfolios in them, each inside a single "chapter 1" folder. The chapter folder and part 1-3 folders all include the name of the section.

Step 2 - Check Portfolios

Proceed through each portfolio in the PDF / book, noting each encounter and opening the corresponding Portfolio in HL. Make sure that the correct number and types of heroes are present.

Verify that each NPC is set to "enemy of the party" (if applicable) and specified as an NPC on the configure hero form. On the NPC tab, make sure that the creature doesn't show any "default" NPC info for the race - that doesn't apply here, and we don't want it to show up on the statblock, so delete it.

If the encounter shows a statblock, compare the statblock to what's output by Hero Lab (under the File menu) to what is in the book. If you find any differences between the book and what Hero Lab generates, note them down for correction (either by yourself or whatever author you are reviewing this for).

It is important to note that THERE WILL BE THINGS WHERE HL HAS IT RIGHT AND THE BOOK IS WRONG. In such cases, do NOT force HL to use the incorrect information, but do make sure it's noted down. To see some common discrepancies between HL and statblocks, see step 5 under testing created races (especially the section on skill discrepancies) above. If this monster is used in several different encounters elsewhere in the encounter library, make sure any corrections everywhere are made everywhere it's used.

Verify that any NPC who has art in the book has the same Art on the personal tab, because this is what is shown for the creature when selecting it in the encounter library and on the Tactical console. In the event of NPCs with more than one piece of art (for example, a head shot and a full body), favor the full body shot by placing it first on the personal tab.

Be sure to read the book's entry for this encounter carefully. It is possible there might be variations you need to account for (such as sleeping guards not having their armor equipped), or even necessitating an extra version of the encounter (for example, if the adventure mentions another NPC may have retreated here to join up with the current encounter).

Step 3 - Check Appendices

Most APs and some modules include a section on random encounters, which should be represented in Hero Lab in a specific way. Where the encounter describes a variable number of monsters encountered, the portfolio should only include a single representative monster, with a "#1" appended to the name, and the portfolio name should not display the "average CR". The number serves as a reminder that there are probably more than one in the encounter, and prompts the user to use the incrementer to select the true number in the encounter.

If, on the other hand, the encounter is with a specific group of monsters and described in detail, you should append the CR to the portfolio name and add the encounter description to the Personal tab for the monsters.

Many issues also have Bestiaries in the appendix. Not all monsters defined there may have been used during the earlier parts of the adventure, so make sure there is a .stock file created that includes all such races. Test them as with any race (see above), comparing the statblocks between HL and the book.

Of special note is that sourcebook information needs to be specially added on the NPC tab for races defined first in a AP appendix, specifying which issue of the AP they premiered in.

Step 4 - Handle Player Content

Scroll through the AP looking for player content defined in this issue, such as new items and feats or deific obediences. Make sure that they are functioning correctly (as appropriate for testing whatever they are, see the guidance above). (If you're one of our data file authors, make sure to integrate these into the correct place when the content is accepted.)

Step 5 - Prepare Portfolios in Folder

All portfolios should have the "prepare" operation run on them before being checked into Vault. The following options are available:

• Automatically enter subfolders - check this if you need HL to visit all the subfolders of the selected folder to process portfolios in them, too - this will typically be checked for modules and adventure paths
• Log errors to a file - check this and then you can see any errors generated by the process at the end, rather than part-way through.
• Select minimal sources - DO NOT select this. All "normal" sources should be selected by default, so that users of the portfolio can use whichever of them they have.
• Strip missing sources - you usually won't need to check this, but do it if some of the portfolios report "missing source" errors when loaded.
• Turn ON Shrink Images - check this to ensure that the images in the portfolio will be shrunk to the appropriate size.
• Turn OFF Shrink Images - DO NOT select this.

Look through the generated log for any errors which may have occurred and double check those portfolios to fix whatever necessary.

Step 6 - Get Package Sources for Portfolios in Folder (only possible for HL staff)

Use the generated file to create a table to help you search and add the AP's GM source to all the things which are referenced in this issue. First scroll down to the bottom section, and replace the "-" which divides the unique ID from the file name with a TAB character. Then go to Google Docs and create a spreadsheet. Copy and paste that bottom section into the spreadsheet, such that the Unique IDs are in the first column and the files are in the second column (this should automatically happen because of the tab). Select both columns, and rearrange things alphabetically by the file name column.

Open all files in a text editor and search for each unique ID and add the GM source to that. As you add the source, delete the file name and move down the line until everything is correctly sourced.

Step 7 - Package Testing

Mostly not needed anymore thanks to Colen. Suck that, tedium!