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

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. 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 any remaining issues are properly noted 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 by using "Develop -> Prepare Portfolio for Distribution" and saving 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.

Pathfinder RPG Best Practices

Contents