View Single Post
Senior Member
Volunteer Data File Author
Join Date: Mar 2005
Location: Australia
Posts: 254

Old February 24th, 2007, 06:40 PM
I'll go through an example, I think that's the only way to explain

Start with Duke Gerard.
He has his various ab_xxx ability options linked to his main unit object (cr14068).
He also has the o_ability option directly linked. This option adds the iabilities item as a child entity to cr14068.
The iabilities item should include a link for all of the possible ab_xxx ability options - contingent on the same option in the parent, but with a priority of 65. This means the child entity which shows in the roster as "Abilities" will have all of the ability options from the main entity as valid links - ie. all of the abillities will show up in the child entity.
But now we have to hide all of the abilities in the main entity. This is why the VISIBLE tag expression (should) appear on all ab_xxx ability options.
The expression should be "!(roster.output & helper.has_dt & entity.unit)". In other words, it's only hidden on units (not items as the "Abilities" entity is an item) and only if the unit has the helper.has_dt tag (which is assigned in the o_ability options EVAL script).

So any options that don't meet the above rules are probably wrong and need fixing

Now, the helper tag group is for something completely different and not related to the above logic
Some options imply other options (eg. "Undead" implies you also have "Fearless"). This is where the EVAL and LIVE scripts come in and why some options appear in the helper Tag Group.
Lets look at the Undead option specifically.
Undead includes the ab_fearless option as a link, so when ab_undead is linked, the unit will also get ab_fearless.
ab_undead also includes an EVAL script which adds the inherit.fearless tag.
So when ab_fearless is processed, it's EVAL script also adds the helper.fearless tag and then if the inherit.fearless tag is assigned, changes the name so it appears italicised, then assigns the inherit.fearless tag to all children (so that the effect will flow into the iabilities Item if we're dealing with a unit with DT's).
ab_fearless also includes a LIVE tag expression "!helper.fearless" so that if the entity has helper.fearless assigned, the ab_fearless option isn't valid. This may seem confusing since ab_fearless is what assigns the helper.fearless tag, but it prevents an ability option from appearing twice in the list.

So the answer to your original question is:
All options should have the VISIBLE tag expression and should be linked to the iabilities ITEM in common.dat
Options that grant other options need to have an EVAL script that assigns "inherit" tag's for the options they grant.
Options that can be inherited from other options need to be included in the "inherit" tag group and need EVAL scripts like the one for ab_fearless.
Options that could possibly end up assigned to an entity twice need to appear in the helper tag group and have a LIVE tag expression.

I'm sorry this has taken so long for me to get to, but I hope it explains it appropriately.
Let me know if it's still confusing.

Russell is offline   #6 Reply With Quote