Explain abilities handling?
 

Russell,

Can you kinda explain your method of handling the IAbilities?

I am seeing:

common.dat OPTIONs o_ability which uses
common.dat OPTIONs o_abil_itm which looks at
common.dat ITEMs iabilities which includes a retyping of all the different abilities already in common.dat OPTIONs, and also includes a CONTINGENT to the related ability.

common.dat ITEMs iabilities also has the tag warlord.def group.HELPER.abil included which also has all of the abilities listed again inside of that.

So, all of the abilities are listed like 3-4 times.

So, although I can kinda follow the path, I am not understanding how it works, with all of the redundancy. Hoping you can help me to understand your methods better.

First of all, I'll explan why it's so complicated an messy :-)

Have a look at a printed roster... If you look at a model with only one DT, you see all of the abilities listed underneath their stats. Now have a look at one with multiple DT's. Those extra DT's are actually different units attached to the main unit as children, and there's also a child item called abilities. The child item has all of the ability option names underneath it.

In order to prevent the abilities printing out directly under the stats of a model with multiple DT's (ie - underneath the first DT), I had to do some messy stuffing around.

The easiest way to understand how it works is to start up AB, make sure you've got debugging turned on and then use a floating info window to look at the active links for a couple of different "units" - look at the main entry, then look at the DT entries and the abilities item to see which option links become active for each one.

There's method in the madness :-)

Russell.

I am still mucking my way thru this.. I am understanding some things a little better. But, still not sure the difference between HELPER and INHERIT.

Inherit is for the most part understandable simply from its name, being that it helps to assign abilities to units that gain some SA via having an item or some such that bestows a change on the unit...

But, what is HELPER? Apologies but the floating window has not helped me to figure out what its for.

actually the floating windows are making my confusion worse.

Cause tings will not be showing up. For example, I opened up Crusaders Duke Gerard... which you put in there...

And His accrued tag and link summary.. everything shows up... And also all of his abilities show up in the roster view under his last track, just like you described. So, everything seems good.

But, then I open up Overlords Matisse, whom I put in later. Using teh floating windows, only one of his several abilities shows up in either window. Yet, in the roster view, all of his abilities are right there. So, I am fairly confused now as to what causes things to show up where. I thought I atleast partly understood thigns, but my understanding is getting more and more blury.

Looking in more, some abilities you have included in helper and others not...? why or why not?

In COMMON.dat under OPTIONS... Some use LIVE, EVAL, and VISIBLE, other just VISIBLE, and some just EVAL and VISIABLE... again why or why not? What is the determining factor to figure out which way you chose to input something?

Just trying to understand the logic...

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 :D
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.

Are you gonna be coming to ReaperCon in May? Would love to try and work with you in person, not that I dont appreciate your responses here. Just one of those, make it work so much faster kinda deals..

:-) I live in Australia and wasn't planning on a trip to the US this year, so.... No, no ReaperCon for me!

I'm regularly online in Live! Messenger, if you use that IM service PM me your id.