This is a classic example of what Colen and I envisioned, and it is therefore one of the key reasons we setup the "squads" mechanism within AB.
Since everything has to be evaluated by a computer, everything has to be processed via some sort of linear process. That process is the "Evaluation Sequence" that is detailed within the Kit docs. The problem with a linear process is that, at any point in the process, you can only test what has already been processed. This means that a link can only test the conditions that have been processed already. That consists of the links with an earlier priority.
If you can arrange the evaluation process sufficiently to guarantee that all counting of models is completed before the Live tagexpr on the link is checked, you can achieve the desired goal. Unfortunately, this means that the convenience mechanisms built into AB for tallying things cannot be used (e.g. accumulated stats, roster stats, etc.). The reason is that they are all processed AFTER all the links have been evaluated, and you need something that is handled on-the-fly.
Assuming you can ensure the evaluation order can process all children before the link gets tested, you can solve this with a private unit stat on the top-level unit. Each child unit will need to add its model count to that unit stat, and the top-level unit must add its count in its PreLinks script. Then you can write a Live tagexpr that can test against the value of the corresponding unit stat.
This technique WILL work for having the child unit retrieve the unit stat from its parent unit. The only requirement is that the count needs to be fully totalled BEFORE the conditional link is evaluated.
Another technique would be to simply use validation and report an error if a vehicle is taken for a unit that has too many models in it. If you did this, all of the bookkeeping would be unneeded, and the final rule would be easy to write.
Where the current approach falls down in a big way (IMHO) is in the inconsistency. A vehicle can be added from various different units within the tree, which creates confusion for the user. For one unit, the vehicle is found on child X, for another on child Y, and for a third its on the parent. This also creates lots of extra work for the authors, as has already been discussed.
If the squads mechanism were utilized, everything gets simplified. The vehicle is added via a "detached" link, thereby adding the vehicle as another top-level entity within the squad. This makes it possible to allow the vehicle to be added from all the units within the tree if you wanted, making things easy and obvious for the user. Then a simple squad scope rule is written to ensure that the vehicle can hold all the models in the unit. Yes, this DOES allow a user to add multiple vehicles to the squad, but that can be verified within the squad rule by an extra 1-2 lines of code.
So the obvious question becomes why is this technique better for the user. If the user is allowed to do stupid things, only to be given an error, how can that be better than precluding the user from doing that stupid thing. My contention is that there are a zillion house rules out there. Many of those rules are only for a special scenario that a group of games has concocted for themselves. And most of those rules tighten or relax the "official" rules for the game. If AB compels the user to comply with the rules, then AB is unusable for those situations. If AB just flags an error, the user is free to ignore the error when it's not applicable to the scenario being played. That's why our intent with AB3 was to shift the focus more towards validation than precluding the user from doing something.
If an author is intent to force the user to comply with a set of rules, then that can usually be accomplished in V3. However, it will often entail a bit more work. Performing validation tests is easy, and it provides the user with maximum flexibility while still making sure the user has a valid army.
Anyways, that's my take on the subject. I would love to see the 40K data files shift to using "squads" as outlined above. With AB3, many of the old ways from AB2 are no longer the best way of solving things. In AB2, you had no choice, but AB3 gives you lots of new options.
Hope this helps,
Rob
At 10:20 AM 12/6/2005, you wrote:
I'm looking for an easier way to calculate the total number of models in a tree in such a way that it can be used in a Live script.
Each transport vehicle holds a certain number of troops, and the link needs to be disabled if the tree of units it too big. The problem is that in some instances the transport is purchased from the top unit in the tree, and in other cases by children units.
For example, a Space Marine Captain. He can purchase a Drop Pod (which holds ten). The Captain can also purchase a Command Squad numbering up to ten Marines. The Command Squad can in turn purchase a Rhino (which holds ten), or a Razorback (which holds 6). To further complicate things, a Chaplain or Librarian may be attached to the Command Squad. This ends up with a possible tree size of 12.
I made a statcalc that computes the number I need, but I guess statcalcs aren't available in Live scripts.
Any thoughts on the best way to accomplish this?
