• Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.

    If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.

    - The Lone Wolf Development Team

validation question

  • Thread starter Thread starter woodywalton at hotmail.co
  • Start date Start date
W

woodywalton at hotmail.co

Guest
All,

Working out some of the last details for validation and was wondering if you
could help with the following:

If you had 8 exclusive unit types (type:type1,type:type2,...) And you wanted
to trigger a validation message if any two different types were selected...

would you have to write (8+7+6+5+4+3+2+1) 29 separate "trat" entries under
the race special attributes, or could they all belong to another mutual
type, and then use a "-legal" or "-istype" expression to make the one
exception and have only 8 "trat" entries.

If so what would the "trat" and "-legal" or "-istype" expression look like?

My thoughts would be something similar to this although with correct syntax:

[trat:type1@1u:alltypes@0u-legal=(if alltypes AND NOT type1)]


Thanks,

Woody




_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get your FREE credit report with a FREE CreditCheck
Monitoring Service trial
http://us.click.yahoo.com/M8mxkD/bQ8CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
 
It's a lot easier than that, fortunately. :-) You can use the "!" syntax
and have merely 8 different "trat" attributes. Define each one by comparing
the presence of type1 to the presence of !type1. If each type is exclusive,
then the presence of anything NOT of that type is illegal. And you really
don't even need the "-istype" filter on this, since the validation message
will only trigger if you have something of typeX to begin with. :-)

Hope this helps,
Rob


At 11:53 AM 8/22/2001 -0500, you wrote:
>All,
>
>Working out some of the last details for validation and was wondering if you
>could help with the following:
>
>If you had 8 exclusive unit types (type:type1,type:type2,...) And you wanted
>to trigger a validation message if any two different types were selected...
>
>would you have to write (8+7+6+5+4+3+2+1) 29 separate "trat" entries under
>the race special attributes, or could they all belong to another mutual
>type, and then use a "-legal" or "-istype" expression to make the one
>exception and have only 8 "trat" entries.
>
>If so what would the "trat" and "-legal" or "-istype" expression look like?
>
>My thoughts would be something similar to this although with correct syntax:
>
>[trat:type1@1u:alltypes@0u-legal=(if alltypes AND NOT type1)]
>
>
>Thanks,
>
>Woody


---------------------------------------------------------------------------
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/M8mxkD/bQ8CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
 
rob -

i've been mulling this, and the problem really arises when you've got
eight X types, and some other number of non-X types. the validation
you suggest will catch all of the non-X types as well as the X types.

It really looks like he's looking for a token mechanism - perhaps a
unique (or limited quantity) item that can only be grabbed
and "imprinted" by one (or two, or whatever) of the exclusive groups.

it'd be very nice if we could have roster types and/or stats - it'd
make this a much simpler proposition.

daniel

--- In armybuilder@y..., Rob Bowes <rob@w...> wrote:
> It's a lot easier than that, fortunately. :-) You can use the "!"
syntax
> and have merely 8 different "trat" attributes. Define each one by
comparing
> the presence of type1 to the presence of !type1. If each type is
exclusive,
> then the presence of anything NOT of that type is illegal. And you
really
> don't even need the "-istype" filter on this, since the validation
message
> will only trigger if you have something of typeX to begin with. :-)
>
> Hope this helps,
> Rob
>
>
> At 11:53 AM 8/22/2001 -0500, you wrote:
> >All,
> >
> >Working out some of the last details for validation and was
wondering if you
> >could help with the following:
> >
> >If you had 8 exclusive unit types (type:type1,type:type2,...) And
you wanted
> >to trigger a validation message if any two different types were
selected...
> >
> >would you have to write (8+7+6+5+4+3+2+1) 29 separate "trat"
entries under
> >the race special attributes, or could they all belong to another
mutual
> >type, and then use a "-legal" or "-istype" expression to make the
one
> >exception and have only 8 "trat" entries.
> >
> >If so what would the "trat" and "-legal" or "-istype" expression
look like?
> >
> >My thoughts would be something similar to this although with
correct syntax:
> >
> >[trat:type1@1u:alltypes@0u-legal=(if alltypes AND NOT type1)]
> >
> >
> >Thanks,
> >
> >Woody
>
>
> --------------------------------------------------------------------
-------
> Rob Bowes (rob@w...) (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/M8mxkD/bQ8CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
 
Pardon me for stating the types were exclusive. They are not. A
unit could potentially have all types. I neglected to mention that
there are many other ancillary types as well.

Example is as follows:

An army may contain various units of types A & B, in addition to
units of one of the following types C, D, E, and F

The types represent clan troop choices. Some clans can choose from
some of the same types, while some have completely different
choices. Units will fall into multiple types so for example:

Unit 1 is of type C and type D
Unit 2 is of type D and type E
Unit 3 is of type C and type F
Unit 4 is of type E and Type F
Unit 5 is of type C only

I want a validation when someone tries to select units that have no
type similarilties between C, D, E & F while at the same time
ignoring A and B altogether.

In the above examples a validation would be triggered if one decided
to select Unit 1, and then tried to select Unit 4(no type in
common); It would not trigger if I selected 1, 3, & 5(type C in
common)

Thanks again!

Woody



--- In armybuilder@y..., "Daniel Rothman" <drothman.dmth94@g...>
wrote:
> rob -
>
> i've been mulling this, and the problem really arises when you've
got
> eight X types, and some other number of non-X types. the
validation
> you suggest will catch all of the non-X types as well as the X
types.
>
> It really looks like he's looking for a token mechanism - perhaps
a
> unique (or limited quantity) item that can only be grabbed
> and "imprinted" by one (or two, or whatever) of the exclusive
groups.
>
> it'd be very nice if we could have roster types and/or stats -
it'd
> make this a much simpler proposition.
>
> daniel
>
> --- In armybuilder@y..., Rob Bowes <rob@w...> wrote:
> > It's a lot easier than that, fortunately. :-) You can use
the "!"
> syntax
> > and have merely 8 different "trat" attributes. Define each one
by
> comparing
> > the presence of type1 to the presence of !type1. If each type is
> exclusive,
> > then the presence of anything NOT of that type is illegal. And
you
> really
> > don't even need the "-istype" filter on this, since the
validation
> message
> > will only trigger if you have something of typeX to begin
with. :-)
> >
> > Hope this helps,
> > Rob
> >
> >
> > At 11:53 AM 8/22/2001 -0500, you wrote:
> > >All,
> > >
> > >Working out some of the last details for validation and was
> wondering if you
> > >could help with the following:
> > >
> > >If you had 8 exclusive unit types (type:type1,type:type2,...)
And
> you wanted
> > >to trigger a validation message if any two different types were
> selected...
> > >
> > >would you have to write (8+7+6+5+4+3+2+1) 29 separate "trat"
> entries under
> > >the race special attributes, or could they all belong to
another
> mutual
> > >type, and then use a "-legal" or "-istype" expression to make
the
> one
> > >exception and have only 8 "trat" entries.
> > >
> > >If so what would the "trat" and "-legal" or "-istype"
expression
> look like?
> > >
> > >My thoughts would be something similar to this although with
> correct syntax:
> > >
> > >[trat:type1@1u:alltypes@0u-legal=(if alltypes AND NOT type1)]
> > >
> > >
> > >Thanks,
> > >
> > >Woody
> >
> >
> > -----------------------------------------------------------------
---
> -------
> > Rob Bowes (rob@w...) (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/M8mxkD/bQ8CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
 
OH! you're looking for transitive support relationships. never mind
all what we said before.

you're looking for the unit external attribute called reqd:type=
(probably)

some less abstract examples would probably help - f'rinstance, you've
probably got some leader-type units, and some follower-type units.
questions like: can follower-type units "permit" other units in (e.g.
may a type-C leader, type C/D follower unit then buy a type-D
follower unit?) are there other conflicts (e.g. type A hates type D,
outside of any other relationships...), etc. etc.

it seems like you're trying to solve a general problem, when you've
got a specific task to accomplish. General mechanisms are good (and
suggesting good ones with possible implementations to Rob is a Good
Thing(TM)), but sometimes twisting the specific problem around helps
avoid difficulties with a general mechanism.

daniel


--- In armybuilder@y..., woodywalton@h... wrote:
> Pardon me for stating the types were exclusive. They are not. A
> unit could potentially have all types. I neglected to mention that
> there are many other ancillary types as well.
>
> Example is as follows:
>
> An army may contain various units of types A & B, in addition to
> units of one of the following types C, D, E, and F
>
> The types represent clan troop choices. Some clans can choose from
> some of the same types, while some have completely different
> choices. Units will fall into multiple types so for example:
>
> Unit 1 is of type C and type D
> Unit 2 is of type D and type E
> Unit 3 is of type C and type F
> Unit 4 is of type E and Type F
> Unit 5 is of type C only
>
> I want a validation when someone tries to select units that have no
> type similarilties between C, D, E & F while at the same time
> ignoring A and B altogether.
>
> In the above examples a validation would be triggered if one
decided
> to select Unit 1, and then tried to select Unit 4(no type in
> common); It would not trigger if I selected 1, 3, & 5(type C in
> common)
>
> Thanks again!
>
> Woody
>
>
>
> --- In armybuilder@y..., "Daniel Rothman" <drothman.dmth94@g...>
> wrote:
> > rob -
> >
> > i've been mulling this, and the problem really arises when you've
> got
> > eight X types, and some other number of non-X types. the
> validation
> > you suggest will catch all of the non-X types as well as the X
> types.
> >
> > It really looks like he's looking for a token mechanism - perhaps
> a
> > unique (or limited quantity) item that can only be grabbed
> > and "imprinted" by one (or two, or whatever) of the exclusive
> groups.
> >
> > it'd be very nice if we could have roster types and/or stats -
> it'd
> > make this a much simpler proposition.
> >
> > daniel
> >
> > --- In armybuilder@y..., Rob Bowes <rob@w...> wrote:
> > > It's a lot easier than that, fortunately. :-) You can use
> the "!"
> > syntax
> > > and have merely 8 different "trat" attributes. Define each one
> by
> > comparing
> > > the presence of type1 to the presence of !type1. If each type
is
> > exclusive,
> > > then the presence of anything NOT of that type is illegal. And
> you
> > really
> > > don't even need the "-istype" filter on this, since the
> validation
> > message
> > > will only trigger if you have something of typeX to begin
> with. :-)
> > >
> > > Hope this helps,
> > > Rob
> > >
> > >
> > > At 11:53 AM 8/22/2001 -0500, you wrote:
> > > >All,
> > > >
> > > >Working out some of the last details for validation and was
> > wondering if you
> > > >could help with the following:
> > > >
> > > >If you had 8 exclusive unit types (type:type1,type:type2,...)
> And
> > you wanted
> > > >to trigger a validation message if any two different types
were
> > selected...
> > > >
> > > >would you have to write (8+7+6+5+4+3+2+1) 29 separate "trat"
> > entries under
> > > >the race special attributes, or could they all belong to
> another
> > mutual
> > > >type, and then use a "-legal" or "-istype" expression to make
> the
> > one
> > > >exception and have only 8 "trat" entries.
> > > >
> > > >If so what would the "trat" and "-legal" or "-istype"
> expression
> > look like?
> > > >
> > > >My thoughts would be something similar to this although with
> > correct syntax:
> > > >
> > > >[trat:type1@1u:alltypes@0u-legal=(if alltypes AND NOT type1)]
> > > >
> > > >
> > > >Thanks,
> > > >
> > > >Woody
> > >
> > >
> > > ----------------------------------------------------------------
-
> ---
> > -------
> > > Rob Bowes (rob@w...) (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/M8mxkD/bQ8CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
 
I guess I am not making myself very clear. There are no
leader/follower relationships, only units of named types.

Clan types may not be mixed, but some unit types may be in more than
one clan. example:

ClanA contains Units 1, 2
ClanB conatins Units 1, 3
ClanC contains Units 4


In Army builder I simply added a type for each clan that the unit
was included in so Unit 2 has the "type:ClanA" and "type:ClanB"
attributes assigned locally. What I want to do is not allow the
selection of units from multiple clans. Keep in mind there are
other units in the race with different types assigned are not part
of this equation and must be ignored.

So if I were to select the units 2&3 I would get an validation
message stating I had chosen units from more than 1 clan, whereas if
I selected 1&2 or 1&3 or 4 alone I would not have.

Thanks for your patience!

Woody



--- In armybuilder@y..., "Daniel Rothman" <drothman.dmth94@g...>
wrote:
> OH! you're looking for transitive support relationships. never
mind
> all what we said before.
>
> you're looking for the unit external attribute called reqd:type=
> (probably)
>
> some less abstract examples would probably help - f'rinstance,
you've
> probably got some leader-type units, and some follower-type units.
> questions like: can follower-type units "permit" other units in
(e.g.
> may a type-C leader, type C/D follower unit then buy a type-D
> follower unit?) are there other conflicts (e.g. type A hates type
D,
> outside of any other relationships...), etc. etc.
>
> it seems like you're trying to solve a general problem, when
you've
> got a specific task to accomplish. General mechanisms are good
(and
> suggesting good ones with possible implementations to Rob is a
Good
> Thing(TM)), but sometimes twisting the specific problem around
helps
> avoid difficulties with a general mechanism.
>
> daniel
>
>
> --- In armybuilder@y..., woodywalton@h... wrote:
> > Pardon me for stating the types were exclusive. They are not.
A
> > unit could potentially have all types. I neglected to mention
that
> > there are many other ancillary types as well.
> >
> > Example is as follows:
> >
> > An army may contain various units of types A & B, in addition to
> > units of one of the following types C, D, E, and F
> >
> > The types represent clan troop choices. Some clans can choose
from
> > some of the same types, while some have completely different
> > choices. Units will fall into multiple types so for example:
> >
> > Unit 1 is of type C and type D
> > Unit 2 is of type D and type E
> > Unit 3 is of type C and type F
> > Unit 4 is of type E and Type F
> > Unit 5 is of type C only
> >
> > I want a validation when someone tries to select units that have
no
> > type similarilties between C, D, E & F while at the same time
> > ignoring A and B altogether.
> >
> > In the above examples a validation would be triggered if one
> decided
> > to select Unit 1, and then tried to select Unit 4(no type in
> > common); It would not trigger if I selected 1, 3, & 5(type C in
> > common)
> >
> > Thanks again!
> >
> > Woody
> >
> >
> >
> > --- In armybuilder@y..., "Daniel Rothman" <drothman.dmth94@g...>
> > wrote:
> > > rob -
> > >
> > > i've been mulling this, and the problem really arises when
you've
> > got
> > > eight X types, and some other number of non-X types. the
> > validation
> > > you suggest will catch all of the non-X types as well as the X
> > types.
> > >
> > > It really looks like he's looking for a token mechanism -
perhaps
> > a
> > > unique (or limited quantity) item that can only be grabbed
> > > and "imprinted" by one (or two, or whatever) of the exclusive
> > groups.
> > >
> > > it'd be very nice if we could have roster types and/or stats -
> > it'd
> > > make this a much simpler proposition.
> > >
> > > daniel
> > >
> > > --- In armybuilder@y..., Rob Bowes <rob@w...> wrote:
> > > > It's a lot easier than that, fortunately. :-) You can use
> > the "!"
> > > syntax
> > > > and have merely 8 different "trat" attributes. Define each
one
> > by
> > > comparing
> > > > the presence of type1 to the presence of !type1. If each
type
> is
> > > exclusive,
> > > > then the presence of anything NOT of that type is illegal.
And
> > you
> > > really
> > > > don't even need the "-istype" filter on this, since the
> > validation
> > > message
> > > > will only trigger if you have something of typeX to begin
> > with. :-)
> > > >
> > > > Hope this helps,
> > > > Rob
> > > >
> > > >
> > > > At 11:53 AM 8/22/2001 -0500, you wrote:
> > > > >All,
> > > > >
> > > > >Working out some of the last details for validation and was
> > > wondering if you
> > > > >could help with the following:
> > > > >
> > > > >If you had 8 exclusive unit types
(type:type1,type:type2,...)
> > And
> > > you wanted
> > > > >to trigger a validation message if any two different types
> were
> > > selected...
> > > > >
> > > > >would you have to write (8+7+6+5+4+3+2+1) 29
separate "trat"
> > > entries under
> > > > >the race special attributes, or could they all belong to
> > another
> > > mutual
> > > > >type, and then use a "-legal" or "-istype" expression to
make
> > the
> > > one
> > > > >exception and have only 8 "trat" entries.
> > > > >
> > > > >If so what would the "trat" and "-legal" or "-istype"
> > expression
> > > look like?
> > > > >
> > > > >My thoughts would be something similar to this although
with
> > > correct syntax:
> > > > >
> > > > >[trat:type1@1u:alltypes@0u-legal=(if alltypes AND NOT
type1)]
> > > > >
> > > > >
> > > > >Thanks,
> > > > >
> > > > >Woody
> > > >
> > > >
> > > > -------------------------------------------------------------
---
> -
> > ---
> > > -------
> > > > Rob Bowes (rob@w...) (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/M8mxkD/bQ8CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
 
Given that none of the types are exclusive and some units are completely
exempt from the relationships, I'm inclined to think that a more "brute
force" solution is necessary. However, the big problem is that units can
belong to multiple types. This makes it impossible to say something like
"type C precludes type D", because it's valid to have a unit that is BOTH
type C AND type D.

Since the "trat" attribute only allows comparisons of single types, the
fact that your units can belong to multiple types in varying combinations
precludes the ability to use "trat". That means that there is no solution
that I can think of for the problem you outline below.

Unless you enlist the help of the user. I recommend tasking the user with
assigning the clan to which each unit should belong, whenever the unit can
have a variable identity. This can be done simply by having an option for
each clan, attaching the proper options to each unit, assigning a
reasonable default clan via the "dflt" attribute, and using "must" to
ensure that the user always selects a clan for every unit where it is
necessary.

Once you do this, then the situation degenerates nicely into a tractable
problem. Units will then always belong to exactly one type, enabling you to
use "trat" to trap conflicting usages. You originally proposed having 29
"trat" attributes to validate all of the different combinations. At this
point, I think you will need to use a brute force solution like this to
properly identify all of the mutually exclusive pairings of clans/types. I
can't come up with an alternate way of doing this for the general case you
outline below.

If you could point me to the book where this problem rears its ugly head, I
would appreciate being able to look at the exact details. I have the first
4 army books, so hopefully it's in one of those. When I'm able to see
exactly the mechanics involved for the game, I can sometimes come up with
creative solutions that don't occur to me for the general case solution
(such as you've presented here). Maybe I'll get lucky. :-)

BTW, the "-legal" qualifier is completely inappropriate here. You cannot
specify types within a "-legal" qualifer. If you use "-legal", the things
you can verify are the same things allowed via a "lglx" attribute (race,
mode, time).

Thanks, Rob


At 09:52 PM 8/22/2001 +0000, you wrote:
>Pardon me for stating the types were exclusive. They are not. A
>unit could potentially have all types. I neglected to mention that
>there are many other ancillary types as well.
>
>Example is as follows:
>
>An army may contain various units of types A & B, in addition to
>units of one of the following types C, D, E, and F
>
>The types represent clan troop choices. Some clans can choose from
>some of the same types, while some have completely different
>choices. Units will fall into multiple types so for example:
>
>Unit 1 is of type C and type D
>Unit 2 is of type D and type E
>Unit 3 is of type C and type F
>Unit 4 is of type E and Type F
>Unit 5 is of type C only
>
>I want a validation when someone tries to select units that have no
>type similarilties between C, D, E & F while at the same time
>ignoring A and B altogether.
>
>In the above examples a validation would be triggered if one decided
>to select Unit 1, and then tried to select Unit 4(no type in
>common); It would not trigger if I selected 1, 3, & 5(type C in
>common)
>
>Thanks again!
>
>Woody


---------------------------------------------------------------------------
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/M8mxkD/bQ8CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
 
Back
Top