• 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

3PP and limiting package dependencies

T

TheIronGolem

Well-known member
In the data package I am developing for a 3PP, there is custom class special that grants a bonus feat, and that feat is from Classic Monsters Revisited (which in HL is part of the "PF Campaign Setting # 1" package).

This feat appears to be the only thing referred to by the 3PP that comes from that source, and I'd hate to create a whole extra dependency just for one feat. Ideally, I'd like to be able to check the feat id, see if it's a valid Thing, and disable the custom special that bootstraps the feat if it isn't. That way the rest of the package could load without errors, and everybody's IP is respected. Is this possible?
 
If the 3pp is not going to be releasing it through LWD you could use the tagisstr["HasFeat.fFEATID"]

otherwise no it can't be done except by LWD.
 
TheIronGolem said:
This feat appears to be the only thing referred to by the 3PP that comes from that source, and I'd hate to create a whole extra dependency just for one feat. Ideally, I'd like to be able to check the feat id, see if it's a valid Thing, and disable the custom special that bootstraps the feat if it isn't. That way the rest of the package could load without errors, and everybody's IP is respected. Is this possible?
Click to expand...
To put simply "no". If the Thing is bootstrapped then HL will require that Thing to exist when it loads. No way around this. This is the main reason why I have different "Packs" for the community. :)

In this case if you are bootstrapping the Feat I would re-create the feat from scratch (do not copy it) and set it with Helper.Helper tag. That will make it unsetectable in the normal Feat tab section. Then your new feat can use a assignstr[] to assign the HasFeat.XXXXXX tag if the actual source (Classic Monsters Revisited) is activated. This way you will attempt to act like the normal feat and you will know the feat Thing exists when setting the HasFeat.? tag.

Its not perfect but it will get you 90% correct.
 
ShadowChemosh said:
In this case if you are bootstrapping the Feat I would re-create the feat from scratch (do not copy it) and set it with Helper.Helper tag. That will make it unsetectable in the normal Feat tab section. Then your new feat can use a assignstr[] to assign the HasFeat.XXXXXX tag if the actual source (Classic Monsters Revisited) is activated. This way you will attempt to act like the normal feat and you will know the feat Thing exists when setting the HasFeat.? tag.
Click to expand...

Clever! And it worked nicely, so I now have a graceful-failure mode. Thanks!

For good measure, I'm also having the class exclude the custom special from its list when the source is not active. That way the user won't see a special they can't actually benefit from.
 
You must log in or register to reply here.
Back
Top