Conditional Bootstrap

[zarlor]

Mathias asked that I create a separate thread for this, so here it is. Primarily we've had many requests for handling a conditional bootstrap of things (usually Skills, Edges or Hindrances, but sometimes for items, although that brings up a whole other issue with items that are permanently set on characters, if I remember correctly.)

For reference here are several threads where the issue comes up:
http://forums.wolflair.com/showthread.php?t=36904
http://forums.wolflair.com/showthread.php?t=42993
http://forums.wolflair.com/showthread.php?t=44293
http://forums.wolflair.com/showthread.php?t=47389

Pretty much all of those refer to a case where we are providing a pick list for the player to choose something and then we'd like to bootstrap that thing to the sheet (although in a few cases it might be a check to see if the thing is there and if it is to just increase it rather than bootstrap it.) The problem has been that none of us have ever figured out a way to actually do that. I think it's mentioned on the Wiki, but it doesn't give an example of how to do it.

The answer we've always given has been to create multiples of that thing, one for each of the possible picks, and just do it that way. It clutters up the Edges/Hindrances lists, so it's not as neat as we'd really like it, but so far that's the only way most any of us have figured out how to do it.

Any ideas?

 

[The One]

I'm new to the editor, only started to experiment with what is and isn't possible, so can only talk about general terms at the moment but hoping it inspires one of the more experienced creators.

Assuming we can present a list of choices as a drop down, can it add more than one thing based on that choice? My thought would be to add all the possibilities, and then apply a "Hide all but this" as part of a script later in the sequence

 

[Mathias]

I prefer not to use bootstrap conditions for any of the examples you've given. The purpose of bootstrap conditions is to add X to a character once (or while) condition Y is satisfied. Some of the examples where I would use them are "Once you reach level 3 Ranger, you get the Endurance feat" -that's a permanent, easily testable set of circumstances with a fixed result. Or, "While raging, you are immune to the shaken and frightened conditons" (in pathfinder, there are several pre-defined immunity to condition X picks that can be bootstrapped). In that case, you've also got a pre-defined set of circumstances, also with a fixed result - In Pathfinder/d20, "while raging" is a simple tag test.

First, for the cases where it's "pick an item from a list, and add that for free to your character". The major problem here is new supplements/house rules. If you're adding this using bootstrap conditions, then if a new supplement comes out that adds more things that qualify, you have to go back and edit the original to add the new options. If someone wants to houserule things - "in my campaign, item Z also qualifies as a selection", then the user has to edit the original. The problem with me saying that I don't like doing it this way is that Savage Worlds doesn't have an ideal tool for adding those things - in Pathfinder, we've added something called a configurable - when bootstrapped, a new tab appears on the character, that has several generic tables added to it - you can set up the tables on that configurable so that they'll offer the list of selections you want for this particular case, and set up the number of selections that are available for that table. Savage Worlds doesn't have that, so I'm saying that this isn't the best way to do it, but the proper tool to do it isn't available to you.

Here's the way I would implement these: First, add a script that increases the count of the appropriate category by 1, or however many free things you're getting. Then, you let the user add their choice of abilities. Then, you add an eval rule to the ability that is granting the free selection that will complain until the user adds something that qualifies. (Actually, usually the eval rule can do double duty - it increases the count of abilities available and tests that the correct thing has been added).

The other situation you've pointed me to, Gumbytie's werewolf issue, I'll answer in that thread - in that case, I think tags can be used to solve the problem - both options are always there, and they're disabled with tags at certain times. I think if I were using that, and using a printed character sheet away from my computer, I'd prefer to see the text of the things that might be added, so that if it came up during play, I wouldn't have to open a rulebook. If they were added with bootstrap conditions, you'd need to print the character while that condition was active in order to have the text of those abilities on your printout.

 

[Mathias]

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.php5?title=Leveraging_Tags_Via_Tag_Expressions

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

Is a tag present?

[I]Group[/I].[I]Tag[/I]

or

[I]Group[/I].[I]Tag[/I] <> 0

(If you just use the simpler version, the <> 0 is implied).

Do we have a certain number of a tag:

count:[I]Group[/I].[I]Tag[/I] >= #

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:

count:Classes.Ranger >= 3

Is a field's value at least a certain amount (you can also use <, <=, =, >=, >, or <>):

fieldval:[I]Field[/I] >= #

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:

fieldval:abilActive <> 0

Is a certain tag present on the hero?

hero#[I]Tag[/I].[I]Group[/I]

or

hero#[I]Tag[/I].[I]Group[/I] <> 0

This one's also common - for example, for a d20/Pathfinder barbarian, "While we're raging" - here's that example:

hero#Hero.Raging

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":

hero#Hero.Raging & (fieldval:abilActive <> 0)

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

 

[Mathias]

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.

 

[Mathias]

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

 

[Mathias]

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

 

[zarlor]

Ok, so it sounds like what we've been talking about on this forum is not at all what you guys would call a "conditional bootstrap". Your definition seems to be to recognize a bootstrap only when a certain condition is met, whereas what we had been using was to conditionally add a bootstrap based on an initial selection. So for us it's a question of meeting the condition only once and then bootstrapping that thing we want in permanently.

On supplements and house rules being an issue for, let's call it pick-list bootstraps to keep the definitions separate, I don't think that's much of an issue at all. House rules are always an issue no matter what, and that's always been handled by having a House Rules data file for anyone who wants to just modify an official file, essentially. I've yet to see a supplement that would fit this criteria, but for those few cases where there are supplements I tend to include them simply as new sources within the same base data file so you modifying the base one anyway, So far that's just never been an issue that I've seen.

As for the solution of adding a count (say an Edge that will be adding a free skill, for example), then just having the player add any old skill they like until they put in the right one... that's a bit messy, really. I think we're better off doing the "add one Edge for every variation" than going that route. It gives a lot better guidance to the player to find exactly what they are looking for. Of course our problem has been that especially for an Edge that might have 8 different options available it becomes really messy seeing all of those on Edges list.

So I think the original request, at least as far as I'm concerned, still stands. I would very much like to see an option to bootstrap something while using a pick-list for the selection of what we are going to add. That, to my mind, is not only the cleanest method it's also the method every single data file author who seems to post here automatically looks for and assumes should be there. So to my mind it's not just a way to provide a cleaner look for the player, but it's also a usability issue for data file authors who all seem to look to do things that way, but simply can't at this time.

 

[Mathias]

Actually, look at what I've talked about for testing tags and fields - based on the selection list you're offering to the user, can you use a script to assign a specific tag or set a specific field value depending on which selection was chosen? Then, you bootstrap all of those items, and on each one, add a condition looking for the correct field value or tag.

As I said, I don't like that route, but it's an option.

 

[Darq]

Agreed. Respectfully, the House rules issue will be true no matter what method is used. The interface's ability to allow the user a selection is a good one, seems a shame not to be able to use it for all things.

So instead of calling it conditional bootstrapping, how about bootstrap selection. I believe the ability to add association to a thing programmatically would be very useful in many situations.

 

[Darq]

Ok so I can conditionally add a custom tag - say "tagOOfBE" depending on a user selection.
Then I bootstrap all possible Racial edges to the race and I can make the edge "Big Eyes" only show up if tag "tafOOFBE" is attached to the race?

 

[zarlor]

If I'm reading him right, I think that's the gist of it. I may give it a try with a few files if I have time tomorrow and see what I can do there/ A lot of work for those of us making the files, but it should make some things a little cleaner on the player side of things. I would only note that if I'm reading this right there is an assumption only that the selections here are Unique, so it should work fine for something like a unique Edge that allows the selection of, say, a skill. But for something like a Mutation or Coup in the Deadlands/Hell On Earth settings I get the feeling that some extra tweaking would need to be done... maybe, I'd have to try it, I think.

 

[Mathias]

Actually, there's an assumption that the selections are "Add Once". If they're unique, and they're conditionally bootstrapped, then the user can't add a copy through normal means - it's already on the character, so they can't add another, even though the copy that's already on the character is non-live.

 

[Darq]

If I'm reading him right, I think that's the gist of it. I may give it a try with a few files if I have time tomorrow and see what I can do there/ A lot of work for those of us making the files, but it should make some things a little cleaner on the player side of things. I would only note that if I'm reading this right there is an assumption only that the selections here are Unique, so it should work fine for something like a unique Edge that allows the selection of, say, a skill. But for something like a Mutation or Coup in the Deadlands/Hell On Earth settings I get the feeling that some extra tweaking would need to be done... maybe, I'd have to try it, I think.

If you wouldn't mind sharing some examples if / when you figure this out it would be appreciated. I'm still trying to keep my head above water here, but I keep heading toward the deep end.

 

[zarlor]

If you wouldn't mind sharing some examples if / when you figure this out it would be appreciated. I'm still trying to keep my head above water here, but I keep heading toward the deep end.

I know the feeling all too well! I'll definitely add any examples I can work out to the Common Code Examples thread here, for sure.

And thanks Mathias for the assist, as always. I still say it would help to have a more direct method, but I definitely appreciate that you've given us a few more options than what we've already been trying to work with.

 

[Darq]

Hi Zarlor - Did you figure this thing out? I am getting to the end of my gross data entry and want to start figuring out the special cases. The first I will try is there is a race (Horc) who gets to pick either the edge Slimy or the edge Sticky.

 

[zarlor]

I haven't had a chance to sit down with Hero Lab to work on anything in a few weeks. So I can't say I worked on any of this at all. Sorry.

 

[Darq]

No Worries Thanks for the reply!

 

[zarlor]

Actually, look at what I've talked about for testing tags and fields - based on the selection list you're offering to the user, can you use a script to assign a specific tag or set a specific field value depending on which selection was chosen? Then, you bootstrap all of those items, and on each one, add a condition looking for the correct field value or tag.

As I said, I don't like that route, but it's an option.

Actually all you said was:

Here's the way I would implement these: First, add a script that increases the count of the appropriate category by 1, or however many free things you're getting. Then, you let the user add their choice of abilities. Then, you add an eval rule to the ability that is granting the free selection that will complain until the user adds something that qualifies. (Actually, usually the eval rule can do double duty - it increases the count of abilities available and tests that the correct thing has been added).

So you didn't like that route, but that's how you would do it? But if you don't like that route then is it still a good thing for us to request a method whereby we could, within the context of a script, get some kind of command for, I don't know, #bootstrap.thing, if you will? I know a huge amount of developer time there is focused on Realm Works, but maybe once that gets released and the initial hump of fixes/features for it are out the door maybe that could be something you guys could look into for us. It just seems to make more sense to many of us, I think, rather than just bootstrapping something and then conditionally blocking it from showing.

Oh, and Darq, I'm hoping to work through a bit more of this during this week since it may also be helpful on trying to update my Necropolis file to Necropolis 2350.

 

[Mathias]

But if you don't like that route then is it still a good thing for us to request a method whereby we could, within the context of a script, get some kind of command for, I don't know, #bootstrap.thing, if you will? I know a huge amount of developer time there is focused on Realm Works, but maybe once that gets released and the initial hump of fixes/features for it are out the door maybe that could be something you guys could look into for us. It just seems to make more sense to many of us, I think, rather than just bootstrapping something and then conditionally blocking it from showing.

There is no way that a script can ever be used to bootstrap something. Hero Lab must generate a list of all scripts that exist before the phase & priority sequence can be started, so something that runs its own scripts must already be present before the phase & priority sequence starts.

What bootstrap conditions do is to put the item in place, and then make it non-live, meaning that none of its scripts are run after it goes non-live - those scripts still exist in the list of scripts to run, but they're flagged as non-live.

I consider bootstrap conditions a major hassle and headache - the fact that Test Now! doesn't handle them properly makes them time-consuming to test once one has been created, and I find them complicated to set up - that's why I don't recommend using them too widely. The other major problem with them is that they're hard to extend if a new book adds new options for them, because you have to edit the existing item to add new bootstraps.