Hero Lab Scripting 401: Bootstrap Conditions
 

This article is part of a collection of editor and scripting articles: http://forums.wolflair.com/showthread.php?t=21688

Bootstrap conditions are used when you want to add a certain thing to the hero, but not all the time - you want to add it only while certain circumstances apply.

When making a bootstrap conditional, first, test this ability without the condition - make sure you've got everything working, and make sure it's adding the bootstrap all the time, and that the bootstrapped thing or things are all showing up correctly.

In the editor, press the "Bootstraps" button at the top right - find the bootstrap you want to make conditional, and press the "Condition..." button.

Like scripts, bootstrap conditions have a phase and priority. So your first step is to look at the conditions that you want to have satisfied - what phase and priority will they be satisfied by? You need your bootstrap condition to come AFTER that. Next, you need to look at the thing you are bootstrapping, that you want to make conditional. Make sure you have "Enable Data File Debugging" turned on in the Develop menu, and then right-click the thing you're bootstrapping. Choose the "Show Debug Tasks for XXXXX" option from the right-click menu, and look at the list of scripts on that thing. Your bootstrap condition must come BEFORE all of those.

If you're not sure what phase & priority to choose, the default I use in Pathfinder & d20 is First/500, and in Shadowrun & Cortex, I default to Initialize/1000. Looking through the Savage Worlds files, a default hasn't really been established yet, so I'd recommend Initialize/1000.

Next, writing the "Tag Expression" for the bootstrap. First, be aware that this is not normal Hero Lab scripting - you're NOT using field[something].value or tagis[XXXX.YYYY], or the other tests you're used to. The place you're probably familiar with tag expressions from is foreaches - the 'where "something"' that's at the end of foreaches - the "something" part is a tag expression.

About the context of these tag expressions - a bootstrap condition is testing the tags and fields on the pick that is doing the bootstrapping. There's a way to test the tags on the hero (I'll get to that later), but those are the only things you can test using bootstrap conditions - the tags on the thing doing the bootstrapping, the fields on the thing doing the bootstrapping, or the tags on the hero.

Here's the wiki page about tag expressions, if you want to read about them in detail: http://hlkitwiki.wolflair.com/index....ag_Expressions

Here are some common examples - hopefully this will cover 85% of the cases:

Is a tag present?
or
(If you just use the simpler version, the <> 0 is implied).

Do we have a certain number of a tag:
In Pathfinder and d20, this is common - "When we reach level 3, we get this feat" - here's the example for a level 3 Ranger's bonus Endurance feat:
Is a field's value at least a certain amount (you can also use <, <=, =, >=, >, or <>):
This one is very common, since a lot of bootstrap conditions will be testing whether or not this ability has been turned on on the In-Play tab. Here's that specific example:
Is a certain tag present on the hero?
or
This one's also common - for example, for a d20/Pathfinder barbarian, "While we're raging" - here's that example:
These can be combined - here's "This can only be used during a rage, and the user turns this particular ability on using the in-play tab":
(If you only tested fieldval:abilActive <> 0, what could happen is that the user goes into a rage, and then turns on this ability - then, they turn off their rage, forgetting to also turn off this ability. If you were only testing fieldval:abilActive <> 0, then the conditional bootstrap would continue to be added, even though the character isn't raging anymore).

Debugging bootstrap conditions:

Timing - this is the most common error in bootstrap conditions. Think about the information you're looking up in your bootstrap condition - look again at how that information is being generated - make certain that your bootstrap condition is being tested AFTER that information is available.

Next, try switching tabs, and then switching back, or, if it's not showing up on one of the summary panels, print preview, and then immediately cancel. By default, tables in Hero Lab don't always update the list of things that should be in that table - it saves time to not update every single table everytime the user changes something. If you find that this is the case - that by switching tabs so that you can't see the table your bootstrap condition should be showing up on, and then switching back, and you haven't changed anything else about your character, please report that to us as a bug - we can find the table and force it to always update.

Specific to Pathfinder, if you are testing the gIsEquip field: Make certain that you are NOT testing this field's value before First/495. If you do, you will get an odd bug - the bootstrap condition will be the opposite of what it should be until you change something else about your character - what happens is that it will be one calculation pass behind. There's actually some special handling happening behind the scenes for the gIsEquip field because equipping weapons works differently on the desktop and tablet versions of Hero Lab.

(reserved in case I think of another follow-up)

(reserved in case I think of a third follow-up)

Mathias,

I love the information you provide in these mini-lectures, they're very helpful. Is there any chance things like this could be part of the hlkitwiki? I really think it would make the authoring kit wiki more useful to have information like these in there for when we're building datafiles from scratch.

Something you may wish to mention or talk about is how 99% of the time tags are checked on the "hero". Not the Pick you are on.

So in example:
hero# is redundant as you can leave it off and it works:
as we are always checking the hero. :(

The default tag check is the container, which is the hero most of the time. But for things which are inside of a different container (like an item power inside a custom magic item entity), then hero# can be useful to transfer to the hero context.

It looks like you may have reversed the order of Group and Tag in the hero# descriptions... the example(hero@Hero.Raging) looks like 'Hero' is a Group while 'Raging' is a tag, but in the initial description you show it as hero#Tag.Group

Or, is Hero a tag and Raging is a group?

Second this, as some one who recently learned the editor by trial and error due to the lack of info, I cannot stress enough how awesome this information is to have, and how much better it would be also posted in a wiki or some location where all this info can be combined into a manual or tutorial.

In this case "hero" is the container (ie character) and "Hero" is the group and "Rage" is the tag. These "Hero" group was made with the idea that they would always go on the "hero" container. :)

From a new persons perspective I am sure that can be a little confusing.