Two options controlling nested units

[abouffard]

Hi all.

I'm new to the forums and have been playing with ABCreator now for a few weeks, trying to add support for the new Diving Eagles FoW book to my AB data files for that game system.

I've made real good progress but am stumped on the best way to go about something. Hope someone can help.

For illustration purposes let me talk in abstracts.

I have a unit (U0), linked to it are two otions (O1 and O2) and two child units (UO1A and UO1B). There is a third unit (UO2) which is linked as a child to UO1A and UO1B.

If O1 is not selected then UO1A appears beneath U0.
If O1 is selected then UO1B appears beneath U0.

If O2 is not selected then UO2 does not appear beneath whichever is visible between UO1A and UO1B.
If O2 is selected then UO2 does appear beneath whichever is visible between UO1A and UO1B.

When I use tags to "signal flare" the above it all works great, I understand how to use the "signal flare" concept Rob alludes to elsewhere, but my problem is now this...

When I leave O1 unselected I see UO1A, when I select O2 then UO2 appears beneath UO1A, just as I want. But if I now select O1 then UO1B appears in place of UO1A but it does not have UO2 beneath it, even though O2 is still selected. I have to un-select O2 and re-select it to get UO2 to appear beneath UO1B. I think I know why this is happening - in my EVAL script for O2 I visit UO's children UO1A and UO1B and fire my "flare" but at that time only one of them is really "active" so I think AB is only "flaring" the "active" one (as dictated by the current state of O1), meaning when I use O1 to "activate" the other unit it doesn't know its supposed to be "flared" by O2.

So what is the easiest way to remedy this? I was trying to write a PreLink script on UO1A and UO1B that would check to see if O2 was selected and then fire their own "flare" to get UO2 to appear but I haven't cracked the code necessary to do that, or even know if that is the correct approach.

Does a better approach involve some further nesting of links to permit these two options, O1 and O2, to work together like this?

Does it just boil down to a priority issue?

Thanks for any advice or tips in advance.

--Andy

[rob]

OK, I *think* I've figured out what you're trying to accomplish. If so, then your assessment is correct that the solution you're using is the victim of timing issues. There is no practical way to have an option or unit that is evaluated AFTER another option effect any changes on the earlier option. That's why things work in one direction but not in the other.

Assuming I understand your objective, there are three ways I can see to implement this. All three approaches assume you still have unit U0, options O1 and O2, and units UO1A and UO1B. The wrinkles are introduced in the handling of UO2.

The first technique assumes that options O1 and O2 are mutually exclusive. If so, then you don't need to do anything special with the UO2 child. Just chain to it from both UO1A and UO1B. Whichever one of them is activated by user selection will have the child unit appear beneath it. No extra work is required. But this method falls apart if you want the UO2 child to exist only once and the user can select BOTH O1 and O2.

The second technique would be to use a Live tag expression to govern UO2 and have it be a child of U0 (the toplevel parent). You are already assigning a tag in both options to indicate whether one of them is selected. You can then attach UO2 directly to U0 and then have the Live tag expression determine whether the tag is defined. If so, the UO2 appears, regardless of whether O1 is selected or O2 is selected.

The third technique involves a lot more work, but it will yield what you want visually. The trick is to NOT have O1 attach UO1A as child (same for O2). Instead you have just the O1 and O2 options, with no children. Each defines a tag that indicates whether it is selected. Then you have a DIFFERENT option (O1A and O2A) that is hidden and uses a Live tag expression to determine whether the reference option (O1 or O2) is actually selected. Each of these options then chains to the proper child beneath it.

If you assign both O1A and O2A evaluation priorities that are AFTER O1 and O2, then both of the user-selectable options will be evaluated first. Now all the necessary tags are processed. Then the hidden options are processed, and the tags are guaranteed to all be defined when the UO2 child is processed for EITHER UO1A or UO1B.

If the mutual exclusion is acceptable, the first technique is the easiest. If not, and you can deal with UO2 being a direct child of U0, then the second option is pretty easy to implement. I do NOT recommend the third technique, but I included it in case you really want things to look perfect. :-)

Hope this helps,
Rob


At 10:22 AM 3/27/2006, you wrote:

Hi all.

I'm new to the forums and have been playing with ABCreator now for a few weeks, trying to add support for the new Diving Eagles FoW book to my AB data files for that game system.

I've made real good progress but am stumped on the best way to go about something. Hope someone can help.

For illustration purposes let me talk in abstracts.

I have a unit (U0), linked to it are two otions (O1 and O2) and two child units (UO1A and UO1B). There is a third unit (UO2) which is linked as a child to UO1A and UO1B.

If O1 is not selected then UO1A appears beneath U0.
If O1 is selected then UO1B appears beneath U0.

If O2 is not selected then UO2 does not appear beneath whichever is visible between UO1A and UO1B.
If O2 is selected then UO2 does appear beneath whichever is visible between UO1A and UO1B.

When I use tags to "signal flare" the above it all works great, I understand how to use the "signal flare" concept Rob alludes to elsewhere, but my problem is now this...

When I leave O1 unselected I see UO1A, when I select O2 then UO2 appears beneath UO1A, just as I want. But if I now select O1 then UO1B appears in place of UO1A but it does not have UO2 beneath it, even though O2 is still selected. I have to un-select O2 and re-select it to get UO2 to appear beneath UO1B. I think I know why this is happening - in my EVAL script for O2 I visit UO's children UO1A and UO1B and fire my "flare" but at that time only one of them is really "active" so I think AB is only "flaring" the "active" one (as dictated by the current state of O1), meaning when I use O1 to "activate" the other unit it doesn't know its supposed to be "flared" by O2.

So what is the easiest way to remedy this? I was trying to write a PreLink script on UO1A and UO1B that would check to see if O2 was selected and then fire their own "flare" to get UO2 to appear but I haven't cracked the code necessary to do that, or even know if that is the correct approach.

Does a better approach involve some further nesting of links to permit these two options, O1 and O2, to work together like this?

Does it just boil down to a priority issue?

Thanks for any advice or tips in advance.

--Andy