Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 13,207
|
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? Code:
Group.Tag Code:
Group.Tag <> 0 Do we have a certain number of a tag: Code:
count:Group.Tag >= # Code:
count:Classes.Ranger >= 3 Code:
fieldval:Field >= # Code:
fieldval:abilActive <> 0 Code:
hero#Tag.Group Code:
hero#Tag.Group <> 0 Code:
hero#Hero.Raging Code:
hero#Hero.Raging & (fieldval:abilActive <> 0) |
#1 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 13,207
|
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. Last edited by Mathias; December 9th, 2013 at 10:06 AM. |
#2 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 13,207
|
(reserved in case I think of another follow-up)
|
#3 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 13,207
|
(reserved in case I think of a third follow-up)
|
#4 |
Senior Member
Volunteer Data File Contributor
Join Date: Jan 2011
Location: Nowhere, Virginia
Posts: 3,633
|
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. RavenX Pronouns: She/Her Please do not PM me to inquire about datafiles I coded "for personal use" such as Exalted, World of Darkness, AD&D, or Warhammer 40K Roleplaying. I appreciate your interest, but I do not own the Intellectual Property rights to these game systems. Nor do I have permission from any of the Publishers to distribute the data files. As such, I cannot distribute the work I have done with community on these files. They are "for personal use" only. Thank you. I am far too busy these days to answer emails. If you message me here there is no guarantee I will get back to you at all. |
#5 |
Senior Member
Volunteer Data File Contributor
Join Date: Jan 2010
Location: Chicago, IL (USA)
Posts: 10,729
|
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: Code:
hero#Hero.Raging Code:
Hero.Raging Hero Lab Resources: Pathfinder - d20pfsrd and Pathfinder Pack Setup 3.5 D&D (d20) - Community Server Setup 5E D&D - Community Server Setup Hero Lab Help - Hero Lab FAQ, Editor Tutorials and Videos, Editor & Scripting Resources. Created by the community for the community - Realm Works kickstarter backer (Alpha Wolf) and Beta tester.- d20 HL package volunteer editor. |
#6 |
Senior Member
Join Date: Oct 2011
Posts: 6,793
|
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.
|
#7 |
Junior Member
Join Date: May 2012
Posts: 22
|
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? |
#8 |
Senior Member
Join Date: Sep 2012
Location: Ottawa, Canada
Posts: 781
|
Quote:
|
|
#9 |
Senior Member
Volunteer Data File Contributor
Join Date: Jan 2010
Location: Chicago, IL (USA)
Posts: 10,729
|
Quote:
From a new persons perspective I am sure that can be a little confusing. Hero Lab Resources: Pathfinder - d20pfsrd and Pathfinder Pack Setup 3.5 D&D (d20) - Community Server Setup 5E D&D - Community Server Setup Hero Lab Help - Hero Lab FAQ, Editor Tutorials and Videos, Editor & Scripting Resources. Created by the community for the community - Realm Works kickstarter backer (Alpha Wolf) and Beta tester.- d20 HL package volunteer editor. |
|
#10 |
Thread Tools | |
Display Modes | |
|
|