Each ruleset auto-defines a specific "ruleset.xxx" tag. The same basic
principle holds for races, except that the core race auto-defines a
"roster.xxx" tag. If you want have something be dependent on a particular
race being selected as the core race for a roster, the tag expression needs
to be based on the "roster.xxx" tag for that race. This means that if you
create a Witch Hunter roster (of any kind), the global tag "roster.witch"
will be defined, corresponding to the "race.witch" tag for the race. [NOTE!
The use of "witch" is for example purposes here, as the actual tag will be
whatever you define.]
Using the approach you've taken, if you want to have units be restricted to
only appear for Witch Hunter roster, they should have "roster.witch" in
their "member" tagexpr. If you want to restrict units to only appear for
certain rulesets, then you need to include the appropriate tag templates
for those rulesets in the "member" tagexpr. All AB does is compare the
"member" tagexpr against the global tags that are currently defined for the
active roster, including both the "roster" tag and any "ruleset" tags.
Remember also that the "ruleset" tags may change based on user-selection of
rulesets.
The visible units are determined the exact same way for both allies and the
core units for a race. The only extra test for allies is whether the allied
race appears in the selectable list for a given roster. Units are treated
exactly the same for both. The problem you are encountering is that the
rulesets your units are dependent upon are not always being defined, so
that the units you want aren't always appearing. You can find out what
global tags are defined by just asking AB to show them to you (assuming you
have debugging support enabled).
What you need to devise is two basic things:
1. The set of rulesets and tags that will be used to control what can/can't
be used in each context.
2. The set of member tagexprs to properly control visibility based on the
defined ruleset tags.
The tags mechanism is incredibly flexible, so I can't think of a situation
where you would be "forced" into any type of restriction. You simply need
to map out the set of tags and tagexprs that you need, at which point
you'll be able to do just about anything you want.
Hope this helps,
Rob
At 01:51 AM 5/31/2005 -0400, you wrote:
>OK, the solution that I did was to change the pointer in the extension
>file from roster.ohw (WH roster) - and refer it to a ruleset instead,
>either ruleset.oh_allyIG or ruleset.oh_allySM. I also placed in the main
>army roster selection screen check boxes to add either type, or none. This
>solved the problem in seeing them if you don't want to see them - just
>select them in or out as you wish.
>
>However, i was wondering the exact reason I don't see them if I play
>another parent race which can take WH allies? Does the ally selection
>point to a specific roster, ruleset, or ignore all rulesets entirely - or
>can it be pointed to a specific ruleset (instead of a roster).
>
>Because, the second part of what I was trying to achieve was to be able to
>split up the Witch hunters selection into a generic WH army (all units) or
>a tighter Sister of Battle ONLY force (using ruleset.SoB). In the main
>army selection screen I have tick boxes to make the selection, and it all
>seems to work the way I want - however, if I choose IG or SM and decide to
>take WH as allies, I can never get one of the elements to show, only the
>SoB elements seem to come through (or WH elements, depending on how I make
>the rulesets within the WH file show/hide themselves).
>
>Would I have to be forced to make the army selection global (by taking off
>the roster.ohw in the context legality) and force everyone else to make
>that decision, especially if they can't even take WH allies? Or within the
>allies tab in the 40K def file can it point to a ruleset instead of a roster?
>
>Thanks for any help.
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (408) 927-9880
Lone Wolf Development
www.wolflair.com