• Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.

    If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.

    - The Lone Wolf Development Team

Bootstrapping Question

Eilserves

Well-known member
I've tried to search the forums, so apologies if I've somehow missed this answered somewhere. I'm working on adding some items to a class, and it's using abilities from other classes. I can bootstap the abilities in, which works fine, except the ClSpecWhen makes it show up at a hard level, regardless of when it's picked. Is there a way to add a conditional or anything that will override this and make the item show up at the level it's selected instead of the level flagged in ClSpecWhen, or make ClSpecWhen be the level it was picked at?

For example, genericability1 is bootstrapped with ClSpecWhen 1, however it's not selected until 5th level. How do I make it show up on the class tab as being at 5th level instead of 1st?
 
For example, genericability1 is bootstrapped with ClSpecWhen 1, however it's not selected until 5th level. How do I make it show up on the class tab as being at 5th level instead of 1st?

You should be able to open the bootstrap tab - click on "Tags" for the ability you want to change and set ClSpecWhen to the level you want the power available at.
 
You should be able to open the bootstrap tab - click on "Tags" for the ability you want to change and set ClSpecWhen to the level you want the power available at.

That's what I'm doing, but doesn't address what I'm trying to achieve. Using my example earlier, let's say genericability1 can be picked as a secondary special ability at 1, 3, 5, 7, 9, etc. Character A doesn't pick it at level 1, but hold off until level 5. Character B, however, picks it at level 3. I'd like to be able to make it show up at level 5 on A and at 3 on B, rather than the level in the ClSpecWhen. Does that make sense?
 
From your posts I am inferring that you've made Custom Specials that bootstrap Class Specials, so your players can determine which of those abilities they get and when. Is that correct?
 
OK. The thing about Custom Specials (and most player-added picks such as feats) is that Hero Lab doesn't track the level at which they're selected. It knows that you get X picks at level Y, but it doesn't know that you took THIS pick at THAT level. Essentially HL only tracks the "final" state of the character in most ways.

That makes it pretty tricky, perhaps prohibitively so, for you to assign an appropriate ClSpecWhen tag to the bootstrapped ability.

Now while HL doesn't track the level at which a given custom special is taken, it does track the order in which they were added to the character, through the xIndex field. So something you could do would be to try to infer from xIndex what level the ability was taken, according to whatever schedule the class uses. Like, if the xIndex is 1 then this is the second choice, which is made at level 5, so you'd tag it with ClSpecWhen.5 (straw numbers for sake of an example). However, players may fail to add the abilities in the order they're supposed to be taken, which could give you an inaccurate picture. It'll also fall apart completely if they ever gain choices from another source, like the "Extra X" feats that are common in Pathfinder.

Bottom line: if it isn't mechanically important when an ability was taken, I'd go with just using ClSpecWhen.1 and live with the inaccuracy. If it is, maybe try using the "choose activation amount" option and use it as a "taken at level X" indicator.
 
Last edited:
Thanks TIG. It's honestly just aesthetics. Mechanically it has no impact, so I can live with it. :)

I get the impression you intended this to be a custom special that multiple classes can choose. You may want to look at how certain abilities that already do this are handled in hero lab. I think some of class abilities taken as custom do indeed reach across for multiple classes.

Easiest workaround is to have each class that gets Generic Ability 1 as a choice is to make different copies for each class. That way if a Fighter can choose it at 1st level but a Rogue has to wait until 5th to pick it you can set up an Expr-Req on the ability itself that looks at the class level of the class. There is a macro for it in pathfinder #classlevel[Class] >= x, where x is the minimum level needed to pick the ability. Check the documentation for the editor in the help file for information on the macros. You can also just find a custom ability that has a level requirement and look at a New(Copy) of it in the editor and learn what the macro combo is.
 
No, it's one class, and the abilities pretty much come from one class as well, to be honest. I've been working on adding in some of the material missing from the Talented Monk in the community pack that ShadowChemosh has put out, as I'm playing one in a campaign and abilities were not yet there. ;) Once I got started with adding the stuff specifically I needed for my character, I just sort of kept going. But as the various "normal Monk Abilities" are talents or edges in this variation, and can be selected at levels other than when a "standard" Monk gets them, it creates the visual disconnect I was trying to fix. Putting in level requirements isn't the issue, it's just, again, a visual display thing that I was trying to fix. I could go the more complex route of making new copies of everything but, why re-invent the wheel if it is literally the same ability? :)
 
If your making user chosen abilities, they go under custom abilities.

If your making class features that get bootstrapped to the class, they go under Class Feature. The thing is, you have to go into the class to bootstrap Class Features. Now you could make a copy of the class/archetype and bootstrap the items to that, if they are not meant to be chosen by the user.

Based on what you said, they are intended as custom abilities. You just create them as normal monk custom abilities and set the level requirements in an expr-req using the macro. That's how its done. For a 5th level monk ability the Expr-req text should be something like: Monk 5th level required. It's literally just adding these two lines in the Expr-req to enforce the level requirement.
 
Last edited:
Apologies, if I haven't relayed how these abilities work clearly, if you're not familiar with the class.

At 1st Level, the class gets 3 edges and 2 talents.
At 2nd, they get 3 more Edge, 2 more Talents.
Etc. These numbers change at different levels, but this should at least present the idea.

Edges are core abilities like, Fast Movement, Flurry of Blows, the Monk AC Bonus, etc, that stay in more of the archetypes (though do get removed at times).

Talents are other abilities that are "core" but are more frequently swapped out by Archetypes, such as Stunning Fist, which is replaced by Perfect Strike for the Weapon Adept, for example.

Regular monk gets Stunning Fist at 1st level. Talented Monk can opt for Stunning Fist at any level that they get a Talent at, 1st, 2nd, 3rd, etc.

So Exp-req to lock Stunning First at minimum level doesn't address what is trying to be done. Some abilities, such as the Sipping Demon from Hungry Ghost, do have a minimum level and I have that working. But if the character selects it at a different, higher level, I was wanting the display on the "Monk (Talented)" tab to show what level it was chosen at, not the minimum level it is available at. Does that make sense?

Anyway, at this point the answer seems to be make a whole new ability rather than bootstrapping if I want the level to actually show, which eventually I might do, but again it seems like re-inventing the wheel to code up an entire new ability that is the exact same as an existing one.

All this might be moot anyway whenever the newer version of the files gets released. I had originally started adding abilities for my own benefit, but have given the work I've done so far to ShadowChemosh to possibly save him some effort on updating.
 
Edges and Talents are basically custom abilities for the class, one would use Custom Ability table 1 and the other uses the second custom ability table. So for Stunning Fist, you'd make a copy of that ability as a custom ability, rig it to go through the Talent table, and leave off the Expr-req if that ability can be taken at any level. Basically your making the abilities as custom abilities and rigging them to go through one of two tables, which have their own arrays for determining how many of each you gain per level.

You just need to make custom abilities. You can create copies of the abilities from the Class Features tab in the editor, but your going to have to copy everything from the original to your new copy, including any eval scripts they have. If the level requirements for abilities are still enforced, you need an expr-req. That's all there is to it.
 
Anyway, at this point the answer seems to be make a whole new ability rather than bootstrapping if I want the level to actually show, which eventually I might do, but again it seems like re-inventing the wheel to code up an entire new ability that is the exact same as an existing one.
Exactly this as its was a waste of time to convert a Class Ability into a Custom Ability for no real gain. Especially when that means Maintenance falls into the hand of the community again which is bad. By bootstrapping LW class specials I am actually leaving "future" features/fixes/maintenance into the hands of LW instead of the community. One less thing to do is totally worth the downside of everything showing at level 1. :)

This is the side of things no one likes to hear or talk about. But TIME is very precious for those doing the community work. This means we sacrifice some "nice" stuff for a faster method of implementation. We either do this or the alternative is NO community files. :(
 
Back
Top