• 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

Live tag expression based on presence of unit in roster

robartes

Member
Hi,

I'm currently trying to shoehorn some Warhammer Ancient Battles lists in to AB3.1, and I'm bumping my had against something that is probably quite easy.

I'm putting in an army list where the army general is either a specific army general character, or can be an 'upgraded' lesser character. However, there can of course be only one army general in the list, so if the 'real' general is in there, the other character cannot be upgraded.

So far so good. Testing for this with rules is quite simple in a merge context rules (it is after all a simple 'there can be only one' requirement), but I would like to take this one step further: if the army general himself is selected, I would like the option on the lesser character to not even appear.

I figured I could do this with a Live tag expression on the 'army general' option for the lesser character, but I can't figure out how to check for the presence of the 'real' general in the list. I thought, based on the documentation, that I could do something with accrued unitid tags, but that does not seem to work.

So my question is -- is it possible to check the presence of a unit in the roster in a Live tag expression? Or am I barking up the wrong tree here and is there a better way of doing this?
 
I think a global "General Included" tag will get you out of trouble. You need to have a tag group designated as global, then create a tag in that group called, say "general". Assign that tag to the specific General model, and make sure the option on the lesser characters also assigns this same tag, then set a live expression on the lesser upgrade options to prevent them showing up when the global tag is set.

Pretty sure the "Leader" mechanism in the Necromunda files works this way - you can take a Leader model, or upgrade one of your Gang Members. Check the Necro files out - they're very simple at the moment :-)

And if they don't work that way, they work some other way which will work for you anyway!
 
You're on the right track. The trick is to use a "global" tag on the army general unit. Accrued tags are accrued AFTER the roster is fully evaluated, so they don't exist when a link tests its Live tagexpr. Their purpose is for validation, roster stats, etc. However, global tags are different. When a global tag is add to the roster, it should be recognized by everything. This means that an option to designate a unit as "general" would be able to detect the tag within a Live tagexpr.

However, I don't think this is a "good idea". The reason is that this does NOT stop the user from adding a lesser character, assigning the "general" option, and then adding a true general to the roster. In addition, this does not stop a user from adding two lesser characters and assigning both the "general" option, nor adding two true generals to the roster. So the end result, while well-intentioned, is really just going to plug one condition out of many.

I just got up on my soapbox about precluding the user from doing things within a separate thread, so I won't repeat myself. Suffice to say, I believe that providing validation is always the optimal solution in situations like this, and I urge you to at least consider what I posted in the other thread. The benefit of being a data file author, though, is that you are free to disagree with me and do things your own way. :-)

-Rob

At 03:26 PM 12/7/2005, you wrote:

Hi,

I'm currently trying to shoehorn some Warhammer Ancient Battles lists in to AB3.1, and I'm bumping my had against something that is probably quite easy.

I'm putting in an army list where the army general is either a specific army general character, or can be an 'upgraded' lesser character. However, there can of course be only one army general in the list, so if the 'real' general is in there, the other character cannot be upgraded.

So far so good. Testing for this with rules is quite simple in a merge context rules (it is after all a simple 'there can be only one' requirement), but I would like to take this one step further: if the army general himself is selected, I would like the option on the lesser character to not even appear.

I figured I could do this with a Live tag expression on the 'army general' option for the lesser character, but I can't figure out how to check for the presence of the 'real' general in the list. I thought, based on the documentation, that I could do something with accrued unitid tags, but that does not seem to work.

So my question is -- is it possible to check the presence of a unit in the roster in a Live tag expression? Or am I barking up the wrong tree here and is there a better way of doing this?
 
rob said:
However, I don't think this is a "good idea". The reason is that this does NOT stop the user from adding a lesser character, assigning the "general" option, and then adding a true general to the roster. In addition, this does not stop a user from adding two lesser characters and assigning both the "general" option, nor adding two true generals to the roster. So the end result, while well-intentioned, is really just going to plug one condition out of many.

I'm inclined to agree with you.

I've successfully used Russel's suggestion of using a global tag to signal the presence of the general, which works, but when I tried to apply this to something else (there can only be one 'stubborn' unit), I ran into trouble: the stubborn option sets a global tag, and has a live expression based on the presence of the tag - this is an interesting variation on the classic chicken and egg problem: the moment you select the option, the global tag is present, and the option is no longer valid, and the list becomes invalid.

This goes to illustrate your point that playing games like this just plugs one condition of many, and can introduce other headaches as well.

So, I agree that this is a job for validation, and not a case where we have to prevent the user from doing something in the first place.

Thanks both for your input!
 
Back
Top