Syntax for options in tag expression?

[TMPEditor]

How do I test the state of an option in a tag expression?

Basically, several units have the option of being the General. However, only one unit can be the General per roster. So, what I think I need to do is set the "Enable" condition for the "General" option to check to see if any unit in the roster already has the General option selected.

 

[rob]

At 08:01 PM 2/19/2006, you wrote:

How do I test the state of an option in a tag expression?

You can't test the state of an option directly within a tag expression. The only way to test the state of an option is to have that option assign a tag to the entity that indicates it's been selected. Then you can test whether that tag exists for the entity within the tag expression. It's akin to having one option send up a flare that a different option can look for.

The key detail with this technique is that the option that assigns the tag must be evaluated BEFORE the option that checks for the tag. This is controlled via the priority of the respective tags. The analogy of a flare is quite appropriate here, since it doesn't do any good to look for the flare before it gets fired into the air.

Basically, several units have the option of being the General. However, only one unit can be the General per roster. So, what I think I need to do is set the "Enable" condition for the "General" option to check to see if any unit in the roster already has the General option selected.

One solution for this would be preclude all other units from selected the "General" option as soon as one has been selected. But that is actually a very complex task to coordinate, and it will make you want to tear your hair out. It's all a matter of evaluation timing that has to span the entire roster. I'll be happy to explain if you want the details, but I recommend you just trust me on this until you start becoming fluent with how everything works. Otherwise, the explanation will probably just make your brain hurt.

This is a situation where validation rules are a quick and easy solution. The rule you're trying to enforce is extremely common, so this exact situation is addressed within the "How To" chapter in the topic entitled "Designing a Rule". For more interesting rules that you'll potentially have need for, see the topic entitled "Validation Script Examples".

Hope this helps,
Rob

 

[TMPEditor]

So, if I understand you correctly, it is easier to create a validation rule that makes the army invalid if it has more than one general, rather than to prevent users from designating too many generals?

(Makes sense.)

 

[rob]

At 06:34 PM 2/20/2006, you wrote:

So, if I understand you correctly, it is easier to create a validation rule that makes the army invalid if it has more than one general, rather than to prevent users from designating too many generals?

(Makes sense.)

Correct.

In general, you can either use the "big stick" approach to force a user to comply with the rules OR you can use the "flashing red lights" approach to flag an error to the user after it's been done. In general, we've found it's better to use the "flashing lights" approach via validation rules. While it's not always optimal for tournament play, this allows users to ignore the rules for crazy scenarios in friendly games. On the flip side, though, there are times when compliance with an army construction rule should never be optional (e.g. the unit cannot have more than X weapons). In a situation like this, it's beneficial to the user to keep them from doing something silly.

AB lets you do it either way, although sometimes it's easier to implement one way vs. the other. In the case of global restrictions (like the "one general" limit), it's almost always easier to do with validation rules.

-Rob