Issuses with child units.
 

Right now, I'm having two issues with child units I'd like to get clearered up. They are last stumbling block to make everything 100% correct on the WAB files, which will be a big deal since WAB hasn't had anything resembling a fully functioning set of files since ABv3 came out.

#1 - I have issues getting a parent unit and a child unit to have thier points go into different pools. Using no postlink stuff, The child would accrue, but would also be added to the parent pool. Using @base, @unit, and @item the best I can get done is to have the points from the child not added to any pool at all! Any solutions to this problem?

#2 - I'm looking for exactly how to make counts of just the child models (which can sometimes be recursive) to a unit and just the parent models at the top level. Any ideas?

Raymond

P.S. As a final note, is there any chance of getting links used as remainders to fully functional (i.e. can have subordinate links, can have scripts, ect) This is a major headache, and I'm not sure of any technical reason why it needs to be done like this.

There are technical issues with remainders, for a bit of insight, see this thread:

http://support.wolflair.com/index.ph...ewtopic&t=6423

Issuses with child units.
 

I'm going to need more specifics regarding question #1. If this is an issue associated with the use of allies, the problem can potentially be addressed via one of the various techniques outlined in the docs for allocating allies in different directions. There is also the "childally" setting that is configured within the definition file to consider. That's all I can give you without a more detailed explanation of exactly what you are trying to accomplish and how things are setup.

I'm also not clear on question #2. Are you saying you don't want recursive child counts tallied? Or something else? Please provide a more thorough explanation of the setup and the structure involved, including as much detail as possible. I'll see what I can come up with for suggestions.

The prospect of remainders being able to support complex operations is pretty slim. There are some very significant technical ramifications to remainders that impose the current limits. We've attempted to identify these issues within the docs, both in the specification of the "remainder" link field and in the "Tips" chapter within the topic on "Using Remainder Links". The most critical aspect is that remainder links have to be processed outside of the normal evaluation flow for links (due to their nature), which makes it impossible for them to reliably perform interesting things via scripts. Perhaps if you outlined what you are specifically trying to accomplish, we can offer a suggestion for how to achieve it without the limitations of the remainder link.

-Rob

At 07:13 AM 8/19/2006, you wrote:

#1 - Here's a good example. There are two profiles I have for a race: characters and special. Both accumulate points and are % based. A character has the option to ride an elephant. When the link is selected, I want the points for the character only (not the elephant) to go to the Characters pool and the elephant to go to the Special pool. Just putting the tags on units and making the elephant a linked option puts the right points to the Special total, but the combined points go to the Characters total. Using the script I was suggested here before:

if (entity.option[ecEle].selection=1) then
@base = @base - 140
@item = @item + 140
endif

gives me the proper Characters total, but no points go to the Special pool. How do I get it so that the points are properly split while still forcing the elephant to be attached to the character and only allowing the link to be selected once?

#2 I have a unit A that can choose to add a child linked unit B. I want the count of figure in A and the count of figures in B. In some cases, B can have more B's linked to it, in which case I want the count of all subsequently linked B's. I haven't been able to get this to work at all before.

The remainder thing is not a huge deal since I've already done a work around. It was just a suggestion, but if it's not possible due to a technical issue, that's fine.

-Raymond

Issuses with child units.
 

Fortunately, #1 is actually quite easy to solve. :-) The trick is to use your own custom accrual script in the profile. The script below is NOT how to solve this.

For the "rare" profile, you already have a Quality tagexpr to identify only the "rare" units. And I'm sure your Final script takes the automatically tallied cost of the profile and divides it by the total size to yield the percentage. All you need to add is an "Accrue" script that tallies up exactly what you need and ignores the rest. Doing that requires just a single line of code, with the Accrue script looking as follows:

*** @accrue = cost[total] - cost[unit]

The above script simply subtracts out the cost of all child units from the amount being tallied. As long as your Qualify tagexpr includes ALL units with the "rare" compgroup, including child units, this will yield the proper total of "rare" units throughout the roster.

The only other change needed is in the Final script. Instead of using the "cost" target reference for calculating the percentage, you need to change that to "custom". This will pull the value calculated by your Accrue script and use it in the calculation.

If you do the above, you don't need to do anything special to accommodate the "Special" compgroup units. Just tally them with all the default handling (and get rid of the script you are currently using to juggle the cost). Everything ought to work smoothly.

For #2, I still don't have all the pieces I need to give you a concrete answer. :-( Where do you want to access the values from? I assume you want unit A to get its own model count. However, do you want unit A to be able to access the total number of models in all the unit B children? Or do you want to access that value from within the top unit B? Or both? Are you intending to access these counts during script evaluation? Or for use in validation rules? Or do you need them tallied for use in profiles? All of these factors impact the optimal way to solve #2, so please give me the details and I'll do my best to get you a viable solution.

Hope this helps,
Rob


At 06:05 AM 8/20/2006, you wrote: