A
armybuilder at egroups.co
Guest
------------------------------------------------------------------------
Missing old school friends? Find them here:
http://click.egroups.com/1/4055/3/_/36190/_/959680893/
------------------------------------------------------------------------
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
------------------------------------------------------------------------
There are 3 messages in this issue.
Topics in this digest:
1. Re: design problem
From: zebuleon@peoplepc.com
2. Re: Re: design problem
From: Rob Bowes <rob@wolflair.com>
3. Re: design problem
From: zebuleon@peoplepc.com
________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Mon, 29 May 2000 20:55:47 -0000
From: zebuleon@peoplepc.com
Subject: Re: design problem
Wouldn't that make the option not available to other members of force
A that are allowed to have it? If yes, is there another way around
it.
Zebuleon
---In armybuilder@egroups.com, Rob Bowes <rob@w...> wrote:
> The "must" attribute is for performing validation. It does NOT have
> anything to do with actually giving a unit an option. This can only
be done
> via linking options to units.
>
> If I understand you're objective, the solution is to attach "opA"
to
the
> unit normally. This will make it appear in both Force A & B. To get
it to
> only appear in Force B, you can use the "legl:race=fb" attribute on
"opA".
> This will make it only available to the unit while in Force B.
>
> Hope this helps,
> Rob
________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Mon, 29 May 2000 14:19:20 -0700
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Re: design problem
Correct. That detail wasn't specified in your example, so I didn't know
that was a constraint.
Given your constraint, the simplest solution is to use "utyp" on OptionA
and assign a specific type to each unit that can have OptionA. In the case
of the unit that can live in both races, you'll need to assign this type
via OptionB that is included automatically. OptionB would have the
following attributes:
hide
type:AllowOptA
legl:race=fb
You'll also need to be sure that the option category assigned to OptionB is
HIGHER priority than the category assigned to OptionA. This ensures that
the type is assigned before the "utyp" checks for it. Lastly, make sure you
use the "-all" qualifier on "utyp".
Thanks, Rob
At 08:55 PM 5/29/00 +0000, you wrote:
>Wouldn't that make the option not available to other members of force
>A that are allowed to have it? If yes, is there another way around
>it.
>
>Zebuleon
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 3
Date: Tue, 30 May 2000 09:47:33 -0000
From: zebuleon@peoplepc.com
Subject: Re: design problem
I tried what you suggested but couldn't seem to get it to work so I
just created a new option and linked it to the augmented units. That
seems to be working just fine.
But I have a new problem along the same lines, but I'm not sure what
I want to happen can without adding a bunch of stuff to the
definition file. Anyway here it is.
I have a unit, unitA, it has the ability to choose what kind of unit
it wants to be via options, we'll use opA, opB and opC. Now these
options do several things,
stat:m+1
unam:="new"
item:+3
spec:newab
These all work fine, its when I get to the item choosing that the
problem comes in. Under item list "newab" there are several items
but not all of them will or can be available to choose. I'm trying to
avoid adding 9 new item categories to the def file.
Lets say itemA and itemB are allowed to "new" but itemB is not
allowed to "new2", now I've tried using 'type:new-grand' with the
option but 'ityp:new' under the item doesn't recognize it. I've
tried
using 'catg:xxx' as well, I've tried adjusting the priority too.
So basicly is there a way to limit what items show up based on what
option the user chooses. Or is there a way to link items to options
while leting them choose among those. 'take:xxx' automatically gives
it to the unit they can't choose it and thats the closet thing, I
believe.
just so you know what else I tried without success was the 'ireg:xx'
it allowed all items because it was the same 'unit' just with a new
option. Other constraints, several units will be able to choose from
these options thus altering their stats accordingly. The units need
to be available in their original form as well.
I think thats is, sorry its so long, but I want to make sure you
understand what I'm trying to do.
Thanks for all you help
Zebuleon
________________________________________________________________________
________________________________________________________________________
Missing old school friends? Find them here:
http://click.egroups.com/1/4055/3/_/36190/_/959680893/
------------------------------------------------------------------------
To unsubscribe from this group, email
armybuilder-unsubscribe@egroups.com
------------------------------------------------------------------------
There are 3 messages in this issue.
Topics in this digest:
1. Re: design problem
From: zebuleon@peoplepc.com
2. Re: Re: design problem
From: Rob Bowes <rob@wolflair.com>
3. Re: design problem
From: zebuleon@peoplepc.com
________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Mon, 29 May 2000 20:55:47 -0000
From: zebuleon@peoplepc.com
Subject: Re: design problem
Wouldn't that make the option not available to other members of force
A that are allowed to have it? If yes, is there another way around
it.
Zebuleon
---In armybuilder@egroups.com, Rob Bowes <rob@w...> wrote:
> The "must" attribute is for performing validation. It does NOT have
> anything to do with actually giving a unit an option. This can only
be done
> via linking options to units.
>
> If I understand you're objective, the solution is to attach "opA"
to
the
> unit normally. This will make it appear in both Force A & B. To get
it to
> only appear in Force B, you can use the "legl:race=fb" attribute on
"opA".
> This will make it only available to the unit while in Force B.
>
> Hope this helps,
> Rob
________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Mon, 29 May 2000 14:19:20 -0700
From: Rob Bowes <rob@wolflair.com>
Subject: Re: Re: design problem
Correct. That detail wasn't specified in your example, so I didn't know
that was a constraint.
Given your constraint, the simplest solution is to use "utyp" on OptionA
and assign a specific type to each unit that can have OptionA. In the case
of the unit that can live in both races, you'll need to assign this type
via OptionB that is included automatically. OptionB would have the
following attributes:
hide
type:AllowOptA
legl:race=fb
You'll also need to be sure that the option category assigned to OptionB is
HIGHER priority than the category assigned to OptionA. This ensures that
the type is assigned before the "utyp" checks for it. Lastly, make sure you
use the "-all" qualifier on "utyp".
Thanks, Rob
At 08:55 PM 5/29/00 +0000, you wrote:
>Wouldn't that make the option not available to other members of force
>A that are allowed to have it? If yes, is there another way around
>it.
>
>Zebuleon
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com
________________________________________________________________________
________________________________________________________________________
Message: 3
Date: Tue, 30 May 2000 09:47:33 -0000
From: zebuleon@peoplepc.com
Subject: Re: design problem
I tried what you suggested but couldn't seem to get it to work so I
just created a new option and linked it to the augmented units. That
seems to be working just fine.
But I have a new problem along the same lines, but I'm not sure what
I want to happen can without adding a bunch of stuff to the
definition file. Anyway here it is.
I have a unit, unitA, it has the ability to choose what kind of unit
it wants to be via options, we'll use opA, opB and opC. Now these
options do several things,
stat:m+1
unam:="new"
item:+3
spec:newab
These all work fine, its when I get to the item choosing that the
problem comes in. Under item list "newab" there are several items
but not all of them will or can be available to choose. I'm trying to
avoid adding 9 new item categories to the def file.
Lets say itemA and itemB are allowed to "new" but itemB is not
allowed to "new2", now I've tried using 'type:new-grand' with the
option but 'ityp:new' under the item doesn't recognize it. I've
tried
using 'catg:xxx' as well, I've tried adjusting the priority too.
So basicly is there a way to limit what items show up based on what
option the user chooses. Or is there a way to link items to options
while leting them choose among those. 'take:xxx' automatically gives
it to the unit they can't choose it and thats the closet thing, I
believe.
just so you know what else I tried without success was the 'ireg:xx'
it allowed all items because it was the same 'unit' just with a new
option. Other constraints, several units will be able to choose from
these options thus altering their stats accordingly. The units need
to be available in their original form as well.
I think thats is, sorry its so long, but I want to make sure you
understand what I'm trying to do.
Thanks for all you help
Zebuleon
________________________________________________________________________
________________________________________________________________________