more wish list

rob -

all right - time to tug on superman's cape, etc., etc.

I want to violate the cardinal rule of local-only information. Just a
bit.

Please, please, please, in "itst", can I have an extension to the
boolean expression that permits "itstistype=fo?)" ? I know it's
computationally expensive. I know istype only ever triggers
validation messages anywhere else in the system. I know it breaks the
locality principal. But _damn_ would it be useful.

Alternative 1: I've mentioned this to you before Rob, but can we
treat the roster as the parent of all the individual units, and allow
the roster to have type, and top-level units to reference/test those
types, and items in top-level units to treat the roster as the
grandparent? I could then build the functionality I need with an
extended itst by rippling types up and down through the roster.

Alternative 2: Similar to Alternative 1, but a bit cleaner on the
data file writing side, but nastier on the implementation side, would
be to update the (itst/zutp/utyp/olgl) family of tests with
a "rosterType=", and update the (type, ztyp, etc.) family of type
twiddlers to permit mods on rosterType. Functionally the same as 1,
and _almost_ isomorphic to the original proposal, but probably a long-
run better bet.

The specific circumstance I'm looking at is the War Gods of Aegyptus
(WGA) system, which involves a lot of instances of units "giving"
items to other units... Under current AB, you can't suppress the
units off the item list dynamically - they're always there, all of
them. Regardless of whether or not the "supporting" unit type is
available. The best I've achieved is to get all the appropriate
validation messages right. The _desired_ behavior is to suppress
those items off the list _until_ the supporting unit is present. Any
of the three above proposals would permit me to accomplish this.

I'm including my current iteration of the WGA files to show what's
going on - the difficulty primarily arises around "enchanted items",
particularly the "Amulets" group.

thanks,
daniel


------------------------ Yahoo! Groups Sponsor ---------------------~-->
FREE COLLEGE MONEY
CLICK HERE to search
600,000 scholarships!
http://us.click.yahoo.com/47cccB/4m7...SFAA/IMSolB/TM
---------------------------------------------------------------------~->

[rob]

At 09:04 PM 9/6/2001 +0000, you wrote:
>I want to violate the cardinal rule of local-only information. Just a
>bit.

Help! Help! I'm being violated!! :-)

Ok, it's been a VERY rough past week. So sue me. :-)

>Please, please, please, in "itst", can I have an extension to the
>boolean expression that permits "itstistype=fo?)" ? I know it's
>computationally expensive. I know istype only ever triggers
>validation messages anywhere else in the system. I know it breaks the
>locality principal. But _damn_ would it be useful.

Not possible. The reason is circularity of evaluation. The "istype"
qualifier is provided on validation rules because validations occur AFTER
all units in the roster have been processed. Consider the following
scenario. With all of the dependency tests possible in AB (e.g. "usta",
"utyp", "uexp", etc.), it is EASY to generate an infinite cycle of
dependencies once you allow items to have global dependencies via "istype".

>Alternative 1: I've mentioned this to you before Rob, but can we
>treat the roster as the parent of all the individual units, and allow
>the roster to have type, and top-level units to reference/test those
>types, and items in top-level units to treat the roster as the
>grandparent? I could then build the functionality I need with an
>extended itst by rippling types up and down through the roster.

This is already on the todo list. I've even designed how it would work in a
very clean and general way that could be used for lots of different
purposes. I just haven't had the time to implement it yet. Maybe in 2002
I'll get it implemented.

>Alternative 2: Similar to Alternative 1, but a bit cleaner on the
>data file writing side, but nastier on the implementation side, would
>be to update the (itst/zutp/utyp/olgl) family of tests with
>a "rosterType=", and update the (type, ztyp, etc.) family of type
>twiddlers to permit mods on rosterType. Functionally the same as 1,
>and _almost_ isomorphic to the original proposal, but probably a long-
>run better bet.

Hmmm. Actually, THIS is what I've already got designed and waiting for
implementation. After re-reading your Alternative#1, my brain automatically
went to the clean, general solution - as opposed to a hack. I agree that #1
would be a very limited hack. That's why #2 is what I've got a solution
already mapped out for.

BTW, before you ask, having "roster-level" types CAN be structured and
controlled separately from unit-level types. Consequently, I believe it IS
possible to avoid the cyclic dependencies via use of roster-level types as
a separate concept from unit-level types. :-)

Thanks, Rob

---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get your FREE credit report with a FREE CreditCheck
Monitoring Service trial
http://us.click.yahoo.com/MDsVHB/bQ8...SFAA/IMSolB/TM
---------------------------------------------------------------------~->