• 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

Bootstrap/Autoadd Conditionals

JakeMilo

Well-known member
I have recently tinkering with an old project of mine and have a small question.

The game system in question lets you take 2 classes at character creation. When you get these classes you get a couple of abilities from them for free. There is an option, with GM permission, to change these abilities for others from the same class. To allow for this I added them with Autoadd to allow for user changing rather than as a bootstrap.

However, later in the game, you can gain a third/forth/fifth class. These extra classes do not give the free abilities.

I have a system that tags each class with the order in which it was taken (first, second, extra), but is there away to make the autoadds conditional, so they are not applied when the extra class tag is present?

Would the best option to be to create one helper ability (with the autoadds), that is conditionally bootstrapped?

I know the other option is to remove all autoadds and make the user select the class abilities themselves, I prefer setting them up correctly in the first instance, and allowing a later change.
 
Autoadds don't have the same conditional options that bootstraps do.

I would recommend bootstrapping these abilities, but then set up a system where the user can check a box on each bootstrapped ability to remove it, and allow it to be replaced. But use tags to mark the suppression - set up your tags so that no table will show the ability, and so that scripts on the ability won't run, and anything bootstrapped by these abilities will have a component script that travels to their root pick, notices that tag, and assigns the same tag to itself.

(Oh, minor detail - make sure that there's a single table that never hides the abilities - and that that's the only table where you're actually showing the "remove" checkbox - they just turn gray on that table if the box is checked. That way, if the user accidentally checks the box, the ability doesn't immediately vanish, preventing them from un-checking the box).
 
Back
Top