• 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 condition context

F

frumple

Well-known member
When testing a tag expression for a bootstrap condition does that tag always need to be on the hero? Is there a way to force the context to look at the thing that is bootstrapping the 2nd thing?

For example, I have a thing (lets call it Thing1) that selects from a group of things with a tag group XXXX.? and pulls the appropriate XXXX.? tag from the selector to it. On Thing1 I am bootstrapping another thing (let's call it Thing2) with the bootstrap condition "XXXX.YYYY" at a timing after the XXXX.? tags are pulled onto Thing1.

However, the only way the bootstrap condition seems to work is if I then push the pulled XXXX tag onto the hero. Is there a way to force the bootstrap condition to look for the XXXX tag on Thing1 instead?
 
If there's a way to do this, I haven't found it. What I sometimes do instead is use an abValue field as a flag, by having a script that checks the pick for whatever tag and then sets the field to 1 if present. The bootstrap condition can then be "fieldval:abValue = 1" or suchlike.

EDIT: Though, now that I think about it, I haven't done that much lately. More often I'll either just go ahead and forward the tag, or make a new one to apply to the hero (depending on whether the original tag would seem out-of-place on the hero). That's probably CPU-cheaper than my numeric-flag hack anyway.
 
Last edited:
Yeah that is what I do sometimes as well. It just seems if we could limit the scope to the thing bootstrapping us it would allow folks to reuse tags without having to worry about accidentally bootstrapping something they do not mean to.
 
Keep in mind its not actually the "hero" being checked it is the container being checked. Most of the time that is the hero but I think its Gizmo's where you end up checking the Gizmo not the hero. Unless you added the hero# part in front of the tag.

Using the fieldval is also what I do to get around checking the Pick instead of the container. :)
 
My guess it is not a simple addition though. Since it is checking the container and picks are not a container. :/
 
You must log in or register to reply here.
Back
Top