More Raw Deal Trouble

[rob]

Sorry for taking so long to get back to you on this. Things have been
really hectic on this end and I've been up to my eyeballs.

Since I'm not familiar with any of the game or rule mechanics for Raw Deal,
your description below regarding your current solution doesn't make sense
to me. Please explain how multiple copies of the card marked as identical
are solving the problem for you. It's possible that there may be a way to
avoid the collapsing issue, but I won't know until I understand the
technique you're using better.

As for the variables approach, what wasn't working for you? If it's a
matter of something not being clear in the docs, perhaps I can clarify
things here (and then get it fixed in the docs).

There are a few approaches to solving the superstar issue that I would
probably try. These are based on your explanation of the rules below, so I
may be missing critical details that render these ideas non-viable. But
here's what I'd try....

First, there is the issue of identifying each superstar and making sure the
user only has one. If all of the superstars have a tag from the group isSS,
then you can simply verify that only one superstar is used by testing that
"distinct:isSS.? = 1". This method handles the case of multiple instances
of the same superstar being allowed. I have no idea if this is the case for
Raw Deal or not, but I mention it because a few games (e.g. LotR and DBZ)
do have this kind of mechanic.

Now for the nasty bit with matching the cards. I assume each card that is
specific to a superstar has a tag to that effect, such as "reqSS.Rock".
What if you instead included a numeric value with the tag name that is
unique to each superstar? This value would be used for both the "isSS" tags
AND the "reqSS" tags. For example, The Rock might be "isSS.Rock42" and all
cards tied to him would be "reqSS.Rock42". Steve Austin might be
"SAustin13", etc. I recommend using a leading zero for single digit numbers
(e.g. "Rock03"). And now you are wondering why the hell I've stuck a number
on the end. :-)

Our first rule above has already established that there is only a single
superstar in the deck. So now our NEXT rule (based on priority assignment)
can identify the numeric code for that one superstar and save it in a
variable. For example, "eval SSid as { val:isSS.? }". If there are multiple
superstars in the deck, this will just grab the value for a random
superstar in the deck. But if there is only one, this will always give us
the value we need. This behavior should be fine, since the higher priority
rule flags the use of multiple superstars.

Now we should be able to define a SINGLE card rule that verifies that ALL
the cards match the superstar. We can do this with a rule like "isSS.? |
count:reqSS.? = 0 | val:reqSS.? = @SSid". The first term ensures that we
ignore superstar cards. The second term treats a card with no reqSS tags as
always valid, thereby handling cards that are generic and usable by all
superstars. The final term verifies that the card's required superstar
matches the superstar currently in the deck. If all three terms fail, then
you know the user has included a card for one superstar with a different
superstar, at which point the validation error is shown.

There is one gotcha to the above solution. This method assumes that all
cards requiring superstars only work with a SINGLE superstar. If some cards
can be used by multiple superstars, this solution won't work. If that's the
case (I have no idea), then let me know and I'll see if I can come up with
an alternate approach for you.

Hope this helps,
Rob

At 05:50 PM 3/15/2004 -0600, you wrote:
>Well, there are over 60 superstars in Raw Deal and each one requires at
>least 2 terms to check.
>
>I've tried using variables and I haven't been very sucessful with the
>project. My current solution is to multiple copies of the card with only
>one superstar tag on the card and then mark them as identical. The upside
>is that it makes the rules much simpler, the downside is that the cards
>collapse into one another unless you are specifically searching for a
>given superstar.
> ----- Original Message -----
> From: Rob Bowes
> To: cardvault@yahoogroups.com
> Sent: Monday, March 15, 2004 4:58 AM
> Subject: Re: [CardVault] More Raw Deal Trouble
>
>
> Try breaking your rule up into pieces, assigning the results of each piece
> to a variable. For example, if you have 200 terms, create 10 variables
> that
> process 20 terms each. Then have your rule verify the 10 variables.
>
> I'm tempted to believe that a rule with more than 100 terms can be written
> differently, eliminating many of the current terms. But that's just a gut
> feeling and completely unfounded. We leave for a tradeshow tomorrow
> morning
> and won't be back until next week. If you want, press me on this issue
> when
> we're back next week and I'll see if I can come up with a more creative
> solution for you to try. In the meantime, the trick mentioned above ought
> to get you operational.
>
> Hope this helps,
> Rob
>
> At 11:49 PM 3/13/2004 -0600, you wrote:
> >My rule was going over 100 terms.
> > ----- Original Message -----
> > From: Colen McAlister
> > To: cardvault@yahoogroups.com
> > Sent: Saturday, March 13, 2004 6:17 PM
> > Subject: Re: [CardVault] More Raw Deal Trouble
> >
> >
> > At 07:21 AM 3/10/2004, you wrote:
> > >Well, I thought I had this licked but it's reared its ugly head
> > >again.
> > >
> > >Raw Deal background: Decks are built around a WWE Superstar and may
> > >contain any number of non-superstar specific cards, but may only
> > >contain their own superstar specific cards. The Rock cannot use a
> > >Steve Austin card, for example.
> > >
> > >Right now Superstar specific cards have a tag from the group reqss.
> > >
> > >Superstar cards have a tag from the group isSS.
> > >
> > >I have tried to steal the Will Only Join rule from the L5R files.
> > >
> > >So I first identify the type of deck being played with a series of
> > >rules along this line:
> > >
> > ><rule id="Is3Min" message="Error: Cannot set Is3Min" priority="1"
> > >scope="deck2">
> > ><![CDATA[
> > >eval Is3Min as { test { card:isSS.3Min > 0, 1, 0}}
> > >]]>
> > ></rule>
> > >
> > >Then check the cards with this rule:
> > >
> > >scope="card"
> > >!reqss.? | (reqss.3Min & ( @Is3Min > 0))
> > >
> > >This works fine except that there are over 70 superstar cards so the
> > >rule over flows and won't parse.
> >
> > The rule 'over flows'? What do you mean?


---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 588-8252
Lone Wolf Development www.wolflair.com





Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/cardvault/

<*> To unsubscribe from this group, send an email to:
cardvault-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Thanks for getting back to me. The problem is coming from some cards that are superstar specific cards but can be used by more than one superstar. For example "The Peeps' Champ" can be used by Christian and the Rock. For the rules I have now, I can only have one superstar assaigned to a card. So in a case like this I would make two instances one with reqSS.Christian and one with reqSS.Rock. This allows the user to select the appropriate one for their superstar, so they don't get a validation flag. However, since the titles are the same, they collapse unless you are particularly sorting for just one or the other. It's a bit of a kludge but I can't think of anything else.

As far as the variables go, I'm not sure what the problem was. The lack of a development tool that would let me see the values of variables keeps me from really knowing what happened. It wasn't worth spending anymore time on since I found a work-around.

Kevin Schafer
----- Original Message -----
From: Rob Bowes
To: cardvault@yahoogroups.com
Sent: Wednesday, March 31, 2004 7:42 PM
Subject: Re: [CardVault] More Raw Deal Trouble


Sorry for taking so long to get back to you on this. Things have been
really hectic on this end and I've been up to my eyeballs.

Since I'm not familiar with any of the game or rule mechanics for Raw Deal,
your description below regarding your current solution doesn't make sense
to me. Please explain how multiple copies of the card marked as identical
are solving the problem for you. It's possible that there may be a way to
avoid the collapsing issue, but I won't know until I understand the
technique you're using better.

As for the variables approach, what wasn't working for you? If it's a
matter of something not being clear in the docs, perhaps I can clarify
things here (and then get it fixed in the docs).

There are a few approaches to solving the superstar issue that I would
probably try. These are based on your explanation of the rules below, so I
may be missing critical details that render these ideas non-viable. But
here's what I'd try....

First, there is the issue of identifying each superstar and making sure the
user only has one. If all of the superstars have a tag from the group isSS,
then you can simply verify that only one superstar is used by testing that
"distinct:isSS.? = 1". This method handles the case of multiple instances
of the same superstar being allowed. I have no idea if this is the case for
Raw Deal or not, but I mention it because a few games (e.g. LotR and DBZ)
do have this kind of mechanic.

Now for the nasty bit with matching the cards. I assume each card that is
specific to a superstar has a tag to that effect, such as "reqSS.Rock".
What if you instead included a numeric value with the tag name that is
unique to each superstar? This value would be used for both the "isSS" tags
AND the "reqSS" tags. For example, The Rock might be "isSS.Rock42" and all
cards tied to him would be "reqSS.Rock42". Steve Austin might be
"SAustin13", etc. I recommend using a leading zero for single digit numbers
(e.g. "Rock03"). And now you are wondering why the hell I've stuck a number
on the end. :-)

Our first rule above has already established that there is only a single
superstar in the deck. So now our NEXT rule (based on priority assignment)
can identify the numeric code for that one superstar and save it in a
variable. For example, "eval SSid as { val:isSS.? }". If there are multiple
superstars in the deck, this will just grab the value for a random
superstar in the deck. But if there is only one, this will always give us
the value we need. This behavior should be fine, since the higher priority
rule flags the use of multiple superstars.

Now we should be able to define a SINGLE card rule that verifies that ALL
the cards match the superstar. We can do this with a rule like "isSS.? |
count:reqSS.? = 0 | val:reqSS.? = @SSid". The first term ensures that we
ignore superstar cards. The second term treats a card with no reqSS tags as
always valid, thereby handling cards that are generic and usable by all
superstars. The final term verifies that the card's required superstar
matches the superstar currently in the deck. If all three terms fail, then
you know the user has included a card for one superstar with a different
superstar, at which point the validation error is shown.

There is one gotcha to the above solution. This method assumes that all
cards requiring superstars only work with a SINGLE superstar. If some cards
can be used by multiple superstars, this solution won't work. If that's the
case (I have no idea), then let me know and I'll see if I can come up with
an alternate approach for you.

Hope this helps,
Rob

At 05:50 PM 3/15/2004 -0600, you wrote:
>Well, there are over 60 superstars in Raw Deal and each one requires at
>least 2 terms to check.
>
>I've tried using variables and I haven't been very sucessful with the
>project. My current solution is to multiple copies of the card with only
>one superstar tag on the card and then mark them as identical. The upside
>is that it makes the rules much simpler, the downside is that the cards
>collapse into one another unless you are specifically searching for a
>given superstar.
> ----- Original Message -----
> From: Rob Bowes
> To: cardvault@yahoogroups.com
> Sent: Monday, March 15, 2004 4:58 AM
> Subject: Re: [CardVault] More Raw Deal Trouble
>
>
> Try breaking your rule up into pieces, assigning the results of each piece
> to a variable. For example, if you have 200 terms, create 10 variables
> that
> process 20 terms each. Then have your rule verify the 10 variables.
>
> I'm tempted to believe that a rule with more than 100 terms can be written
> differently, eliminating many of the current terms. But that's just a gut
> feeling and completely unfounded. We leave for a tradeshow tomorrow
> morning
> and won't be back until next week. If you want, press me on this issue
> when
> we're back next week and I'll see if I can come up with a more creative
> solution for you to try. In the meantime, the trick mentioned above ought
> to get you operational.
>
> Hope this helps,
> Rob
>
> At 11:49 PM 3/13/2004 -0600, you wrote:
> >My rule was going over 100 terms.
> > ----- Original Message -----
> > From: Colen McAlister
> > To: cardvault@yahoogroups.com
> > Sent: Saturday, March 13, 2004 6:17 PM
> > Subject: Re: [CardVault] More Raw Deal Trouble
> >
> >
> > At 07:21 AM 3/10/2004, you wrote:
> > >Well, I thought I had this licked but it's reared its ugly head
> > >again.
> > >
> > >Raw Deal background: Decks are built around a WWE Superstar and may
> > >contain any number of non-superstar specific cards, but may only
> > >contain their own superstar specific cards. The Rock cannot use a
> > >Steve Austin card, for example.
> > >
> > >Right now Superstar specific cards have a tag from the group reqss.
> > >
> > >Superstar cards have a tag from the group isSS.
> > >
> > >I have tried to steal the Will Only Join rule from the L5R files.
> > >
> > >So I first identify the type of deck being played with a series of
> > >rules along this line:
> > >
> > ><rule id="Is3Min" message="Error: Cannot set Is3Min" priority="1"
> > >scope="deck2">
> > ><![CDATA[
> > >eval Is3Min as { test { card:isSS.3Min > 0, 1, 0}}
> > >]]>
> > ></rule>
> > >
> > >Then check the cards with this rule:
> > >
> > >scope="card"
> > >!reqss.? | (reqss.3Min & ( @Is3Min > 0))
> > >
> > >This works fine except that there are over 70 superstar cards so the
> > >rule over flows and won't parse.
> >
> > The rule 'over flows'? What do you mean?


---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 588-8252
Lone Wolf Development www.wolflair.com




------------------------------------------------------------------------------
Yahoo! Groups Links

a.. To visit your group on the web, go to:
http://groups.yahoo.com/group/cardvault/

b.. To unsubscribe from this group, send an email to:
cardvault-unsubscribe@yahoogroups.com

c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



[Non-text portions of this message have been removed]




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/cardvault/

<*> To unsubscribe from this group, send an email to:
cardvault-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[rob]

OK, thanks for clarifying how things are working. It now makes sense to me. :-)

How many of these "special" cards are there? I'm referring to the ones that
can be used by multiple superstars. Depending on the number, handling them
as special cases might be worth considering. Let me know and I'll offer my
ideas based on what the quantity is.

Thanks, Rob

At 07:34 AM 4/1/2004 -0600, you wrote:
>Thanks for getting back to me. The problem is coming from some cards that
>are superstar specific cards but can be used by more than one
>superstar. For example "The Peeps' Champ" can be used by Christian and
>the Rock. For the rules I have now, I can only have one superstar
>assaigned to a card. So in a case like this I would make two instances
>one with reqSS.Christian and one with reqSS.Rock. This allows the user to
>select the appropriate one for their superstar, so they don't get a
>validation flag. However, since the titles are the same, they collapse
>unless you are particularly sorting for just one or the other. It's a bit
>of a kludge but I can't think of anything else.
>
>As far as the variables go, I'm not sure what the problem was. The lack
>of a development tool that would let me see the values of variables keeps
>me from really knowing what happened. It wasn't worth spending anymore
>time on since I found a work-around.
>
>Kevin Schafer
> ----- Original Message -----
> From: Rob Bowes
> To: cardvault@yahoogroups.com
> Sent: Wednesday, March 31, 2004 7:42 PM
> Subject: Re: [CardVault] More Raw Deal Trouble
>
>
> Sorry for taking so long to get back to you on this. Things have been
> really hectic on this end and I've been up to my eyeballs.
>
> Since I'm not familiar with any of the game or rule mechanics for Raw
> Deal,
> your description below regarding your current solution doesn't make sense
> to me. Please explain how multiple copies of the card marked as identical
> are solving the problem for you. It's possible that there may be a way to
> avoid the collapsing issue, but I won't know until I understand the
> technique you're using better.
>
> As for the variables approach, what wasn't working for you? If it's a
> matter of something not being clear in the docs, perhaps I can clarify
> things here (and then get it fixed in the docs).
>
> There are a few approaches to solving the superstar issue that I would
> probably try. These are based on your explanation of the rules below, so I
> may be missing critical details that render these ideas non-viable. But
> here's what I'd try....
>
> First, there is the issue of identifying each superstar and making sure
> the
> user only has one. If all of the superstars have a tag from the group
> isSS,
> then you can simply verify that only one superstar is used by testing that
> "distinct:isSS.? = 1". This method handles the case of multiple instances
> of the same superstar being allowed. I have no idea if this is the case
> for
> Raw Deal or not, but I mention it because a few games (e.g. LotR and DBZ)
> do have this kind of mechanic.
>
> Now for the nasty bit with matching the cards. I assume each card that is
> specific to a superstar has a tag to that effect, such as "reqSS.Rock".
> What if you instead included a numeric value with the tag name that is
> unique to each superstar? This value would be used for both the "isSS"
> tags
> AND the "reqSS" tags. For example, The Rock might be "isSS.Rock42" and all
> cards tied to him would be "reqSS.Rock42". Steve Austin might be
> "SAustin13", etc. I recommend using a leading zero for single digit
> numbers
> (e.g. "Rock03"). And now you are wondering why the hell I've stuck a
> number
> on the end. :-)
>
> Our first rule above has already established that there is only a single
> superstar in the deck. So now our NEXT rule (based on priority assignment)
> can identify the numeric code for that one superstar and save it in a
> variable. For example, "eval SSid as { val:isSS.? }". If there are
> multiple
> superstars in the deck, this will just grab the value for a random
> superstar in the deck. But if there is only one, this will always give us
> the value we need. This behavior should be fine, since the higher priority
> rule flags the use of multiple superstars.
>
> Now we should be able to define a SINGLE card rule that verifies that ALL
> the cards match the superstar. We can do this with a rule like "isSS.? |
> count:reqSS.? = 0 | val:reqSS.? = @SSid". The first term ensures that we
> ignore superstar cards. The second term treats a card with no reqSS
> tags as
> always valid, thereby handling cards that are generic and usable by all
> superstars. The final term verifies that the card's required superstar
> matches the superstar currently in the deck. If all three terms fail, then
> you know the user has included a card for one superstar with a different
> superstar, at which point the validation error is shown.
>
> There is one gotcha to the above solution. This method assumes that all
> cards requiring superstars only work with a SINGLE superstar. If some
> cards
> can be used by multiple superstars, this solution won't work. If that's
> the
> case (I have no idea), then let me know and I'll see if I can come up with
> an alternate approach for you.
>
> Hope this helps,
> Rob
>
> At 05:50 PM 3/15/2004 -0600, you wrote:
> >Well, there are over 60 superstars in Raw Deal and each one requires at
> >least 2 terms to check.
> >
> >I've tried using variables and I haven't been very sucessful with the
> >project. My current solution is to multiple copies of the card with only
> >one superstar tag on the card and then mark them as identical. The
> upside
> >is that it makes the rules much simpler, the downside is that the cards
> >collapse into one another unless you are specifically searching for a
> >given superstar.
> > ----- Original Message -----
> > From: Rob Bowes
> > To: cardvault@yahoogroups.com
> > Sent: Monday, March 15, 2004 4:58 AM
> > Subject: Re: [CardVault] More Raw Deal Trouble
> >
> >
> > Try breaking your rule up into pieces, assigning the results of
> each piece
> > to a variable. For example, if you have 200 terms, create 10 variables
> > that
> > process 20 terms each. Then have your rule verify the 10 variables.
> >
> > I'm tempted to believe that a rule with more than 100 terms can be
> written
> > differently, eliminating many of the current terms. But that's just
> a gut
> > feeling and completely unfounded. We leave for a tradeshow tomorrow
> > morning
> > and won't be back until next week. If you want, press me on this issue
> > when
> > we're back next week and I'll see if I can come up with a more creative
> > solution for you to try. In the meantime, the trick mentioned above
> ought
> > to get you operational.
> >
> > Hope this helps,
> > Rob
> >
> > At 11:49 PM 3/13/2004 -0600, you wrote:
> > >My rule was going over 100 terms.
> > > ----- Original Message -----
> > > From: Colen McAlister
> > > To: cardvault@yahoogroups.com
> > > Sent: Saturday, March 13, 2004 6:17 PM
> > > Subject: Re: [CardVault] More Raw Deal Trouble
> > >
> > >
> > > At 07:21 AM 3/10/2004, you wrote:
> > > >Well, I thought I had this licked but it's reared its ugly head
> > > >again.
> > > >
> > > >Raw Deal background: Decks are built around a WWE Superstar
> and may
> > > >contain any number of non-superstar specific cards, but may only
> > > >contain their own superstar specific cards. The Rock cannot use a
> > > >Steve Austin card, for example.
> > > >
> > > >Right now Superstar specific cards have a tag from the group
> reqss.
> > > >
> > > >Superstar cards have a tag from the group isSS.
> > > >
> > > >I have tried to steal the Will Only Join rule from the L5R files.
> > > >
> > > >So I first identify the type of deck being played with a series of
> > > >rules along this line:
> > > >
> > > ><rule id="Is3Min" message="Error: Cannot set Is3Min" priority="1"
> > > >scope="deck2">
> > > ><![CDATA[
> > > >eval Is3Min as { test { card:isSS.3Min > 0, 1, 0}}
> > > >]]>
> > > ></rule>
> > > >
> > > >Then check the cards with this rule:
> > > >
> > > >scope="card"
> > > >!reqss.? | (reqss.3Min & ( @Is3Min > 0))
> > > >
> > > >This works fine except that there are over 70 superstar cards
> so the
> > > >rule over flows and won't parse.
> > >
> > > The rule 'over flows'? What do you mean?


---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 588-8252
Lone Wolf Development www.wolflair.com





Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/cardvault/

<*> To unsubscribe from this group, send an email to:
cardvault-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

I don't know off hand. I would guess that there are 30 to 40 of them currently with maybe 2-5 new ones in each set released.
----- Original Message -----
From: Rob Bowes
To: cardvault@yahoogroups.com
Sent: Thursday, April 01, 2004 4:38 PM
Subject: Re: [CardVault] More Raw Deal Trouble


OK, thanks for clarifying how things are working. It now makes sense to me. :-)

How many of these "special" cards are there? I'm referring to the ones that
can be used by multiple superstars. Depending on the number, handling them
as special cases might be worth considering. Let me know and I'll offer my
ideas based on what the quantity is.

Thanks, Rob

At 07:34 AM 4/1/2004 -0600, you wrote:
>Thanks for getting back to me. The problem is coming from some cards that
>are superstar specific cards but can be used by more than one
>superstar. For example "The Peeps' Champ" can be used by Christian and
>the Rock. For the rules I have now, I can only have one superstar
>assaigned to a card. So in a case like this I would make two instances
>one with reqSS.Christian and one with reqSS.Rock. This allows the user to
>select the appropriate one for their superstar, so they don't get a
>validation flag. However, since the titles are the same, they collapse
>unless you are particularly sorting for just one or the other. It's a bit
>of a kludge but I can't think of anything else.
>
>As far as the variables go, I'm not sure what the problem was. The lack
>of a development tool that would let me see the values of variables keeps
>me from really knowing what happened. It wasn't worth spending anymore
>time on since I found a work-around.
>
>Kevin Schafer
> ----- Original Message -----
> From: Rob Bowes
> To: cardvault@yahoogroups.com
> Sent: Wednesday, March 31, 2004 7:42 PM
> Subject: Re: [CardVault] More Raw Deal Trouble
>
>
> Sorry for taking so long to get back to you on this. Things have been
> really hectic on this end and I've been up to my eyeballs.
>
> Since I'm not familiar with any of the game or rule mechanics for Raw
> Deal,
> your description below regarding your current solution doesn't make sense
> to me. Please explain how multiple copies of the card marked as identical
> are solving the problem for you. It's possible that there may be a way to
> avoid the collapsing issue, but I won't know until I understand the
> technique you're using better.
>
> As for the variables approach, what wasn't working for you? If it's a
> matter of something not being clear in the docs, perhaps I can clarify
> things here (and then get it fixed in the docs).
>
> There are a few approaches to solving the superstar issue that I would
> probably try. These are based on your explanation of the rules below, so I
> may be missing critical details that render these ideas non-viable. But
> here's what I'd try....
>
> First, there is the issue of identifying each superstar and making sure
> the
> user only has one. If all of the superstars have a tag from the group
> isSS,
> then you can simply verify that only one superstar is used by testing that
> "distinct:isSS.? = 1". This method handles the case of multiple instances
> of the same superstar being allowed. I have no idea if this is the case
> for
> Raw Deal or not, but I mention it because a few games (e.g. LotR and DBZ)
> do have this kind of mechanic.
>
> Now for the nasty bit with matching the cards. I assume each card that is
> specific to a superstar has a tag to that effect, such as "reqSS.Rock".
> What if you instead included a numeric value with the tag name that is
> unique to each superstar? This value would be used for both the "isSS"
> tags
> AND the "reqSS" tags. For example, The Rock might be "isSS.Rock42" and all
> cards tied to him would be "reqSS.Rock42". Steve Austin might be
> "SAustin13", etc. I recommend using a leading zero for single digit
> numbers
> (e.g. "Rock03"). And now you are wondering why the hell I've stuck a
> number
> on the end. :-)
>
> Our first rule above has already established that there is only a single
> superstar in the deck. So now our NEXT rule (based on priority assignment)
> can identify the numeric code for that one superstar and save it in a
> variable. For example, "eval SSid as { val:isSS.? }". If there are
> multiple
> superstars in the deck, this will just grab the value for a random
> superstar in the deck. But if there is only one, this will always give us
> the value we need. This behavior should be fine, since the higher priority
> rule flags the use of multiple superstars.
>
> Now we should be able to define a SINGLE card rule that verifies that ALL
> the cards match the superstar. We can do this with a rule like "isSS.? |
> count:reqSS.? = 0 | val:reqSS.? = @SSid". The first term ensures that we
> ignore superstar cards. The second term treats a card with no reqSS
> tags as
> always valid, thereby handling cards that are generic and usable by all
> superstars. The final term verifies that the card's required superstar
> matches the superstar currently in the deck. If all three terms fail, then
> you know the user has included a card for one superstar with a different
> superstar, at which point the validation error is shown.
>
> There is one gotcha to the above solution. This method assumes that all
> cards requiring superstars only work with a SINGLE superstar. If some
> cards
> can be used by multiple superstars, this solution won't work. If that's
> the
> case (I have no idea), then let me know and I'll see if I can come up with
> an alternate approach for you.
>
> Hope this helps,
> Rob
>
> At 05:50 PM 3/15/2004 -0600, you wrote:
> >Well, there are over 60 superstars in Raw Deal and each one requires at
> >least 2 terms to check.
> >
> >I've tried using variables and I haven't been very sucessful with the
> >project. My current solution is to multiple copies of the card with only
> >one superstar tag on the card and then mark them as identical. The
> upside
> >is that it makes the rules much simpler, the downside is that the cards
> >collapse into one another unless you are specifically searching for a
> >given superstar.
> > ----- Original Message -----
> > From: Rob Bowes
> > To: cardvault@yahoogroups.com
> > Sent: Monday, March 15, 2004 4:58 AM
> > Subject: Re: [CardVault] More Raw Deal Trouble
> >
> >
> > Try breaking your rule up into pieces, assigning the results of
> each piece
> > to a variable. For example, if you have 200 terms, create 10 variables
> > that
> > process 20 terms each. Then have your rule verify the 10 variables.
> >
> > I'm tempted to believe that a rule with more than 100 terms can be
> written
> > differently, eliminating many of the current terms. But that's just
> a gut
> > feeling and completely unfounded. We leave for a tradeshow tomorrow
> > morning
> > and won't be back until next week. If you want, press me on this issue
> > when
> > we're back next week and I'll see if I can come up with a more creative
> > solution for you to try. In the meantime, the trick mentioned above
> ought
> > to get you operational.
> >
> > Hope this helps,
> > Rob
> >
> > At 11:49 PM 3/13/2004 -0600, you wrote:
> > >My rule was going over 100 terms.
> > > ----- Original Message -----
> > > From: Colen McAlister
> > > To: cardvault@yahoogroups.com
> > > Sent: Saturday, March 13, 2004 6:17 PM
> > > Subject: Re: [CardVault] More Raw Deal Trouble
> > >
> > >
> > > At 07:21 AM 3/10/2004, you wrote:
> > > >Well, I thought I had this licked but it's reared its ugly head
> > > >again.
> > > >
> > > >Raw Deal background: Decks are built around a WWE Superstar
> and may
> > > >contain any number of non-superstar specific cards, but may only
> > > >contain their own superstar specific cards. The Rock cannot use a
> > > >Steve Austin card, for example.
> > > >
> > > >Right now Superstar specific cards have a tag from the group
> reqss.
> > > >
> > > >Superstar cards have a tag from the group isSS.
> > > >
> > > >I have tried to steal the Will Only Join rule from the L5R files.
> > > >
> > > >So I first identify the type of deck being played with a series of
> > > >rules along this line:
> > > >
> > > ><rule id="Is3Min" message="Error: Cannot set Is3Min" priority="1"
> > > >scope="deck2">
> > > ><![CDATA[
> > > >eval Is3Min as { test { card:isSS.3Min > 0, 1, 0}}
> > > >]]>
> > > ></rule>
> > > >
> > > >Then check the cards with this rule:
> > > >
> > > >scope="card"
> > > >!reqss.? | (reqss.3Min & ( @Is3Min > 0))
> > > >
> > > >This works fine except that there are over 70 superstar cards
> so the
> > > >rule over flows and won't parse.
> > >
> > > The rule 'over flows'? What do you mean?


---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 588-8252
Lone Wolf Development www.wolflair.com




------------------------------------------------------------------------------
Yahoo! Groups Links

a.. To visit your group on the web, go to:
http://groups.yahoo.com/group/cardvault/

b.. To unsubscribe from this group, send an email to:
cardvault-unsubscribe@yahoogroups.com

c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



[Non-text portions of this message have been removed]




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/cardvault/

<*> To unsubscribe from this group, send an email to:
cardvault-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[rob]

OK, there are more cards that match multiple superstars than I anticipated,
so my original idea won't work. However, you can still make this work
without a lot of rules or effort. This suggestion is a modification to my
original proposal (included below).

If a card can match two different superstars, you can handle it with a
second requirement tag group. For example, a card that requires The Rock OR
Steve Austin would have the tag "reqSS1.Rock42" AND "reqSS2.SAustin13".
Each requirement is assigned to a separate "reqSSx" tag group. Then you can
modify the card rule to look like the following:
isSS.? | count:reqSS1.? = 0 | val:reqSS1.? = @SSid | (count:reqSS2.? <> 0 &
val:reqSS2.? = @SSid)

The new term verifies that either there is no second requirement or the
second requirement matches the superstar, thereby making the inclusion of
the second requirement entirely optional.

Hope this helps,
Rob

At 05:13 PM 4/1/2004 -0600, you wrote:
>I don't know off hand. I would guess that there are 30 to 40 of them
>currently with maybe 2-5 new ones in each set released.
> ----- Original Message -----
> From: Rob Bowes
> To: cardvault@yahoogroups.com
> Sent: Thursday, April 01, 2004 4:38 PM
> Subject: Re: [CardVault] More Raw Deal Trouble
>
>
> OK, thanks for clarifying how things are working. It now makes sense to
> me. :-)
>
> How many of these "special" cards are there? I'm referring to the ones
> that
> can be used by multiple superstars. Depending on the number, handling them
> as special cases might be worth considering. Let me know and I'll offer my
> ideas based on what the quantity is.
>
> Thanks, Rob
>
> At 07:34 AM 4/1/2004 -0600, you wrote:
> >Thanks for getting back to me. The problem is coming from some cards
> that
> >are superstar specific cards but can be used by more than one
> >superstar. For example "The Peeps' Champ" can be used by Christian and
> >the Rock. For the rules I have now, I can only have one superstar
> >assaigned to a card. So in a case like this I would make two instances
> >one with reqSS.Christian and one with reqSS.Rock. This allows the
> user to
> >select the appropriate one for their superstar, so they don't get a
> >validation flag. However, since the titles are the same, they collapse
> >unless you are particularly sorting for just one or the other. It's a
> bit
> >of a kludge but I can't think of anything else.
> >
> >As far as the variables go, I'm not sure what the problem was. The lack
> >of a development tool that would let me see the values of variables keeps
> >me from really knowing what happened. It wasn't worth spending anymore
> >time on since I found a work-around.
> >
> >Kevin Schafer
> > ----- Original Message -----
> > From: Rob Bowes
> > To: cardvault@yahoogroups.com
> > Sent: Wednesday, March 31, 2004 7:42 PM
> > Subject: Re: [CardVault] More Raw Deal Trouble
> >
> >
> > Sorry for taking so long to get back to you on this. Things have been
> > really hectic on this end and I've been up to my eyeballs.
> >
> > Since I'm not familiar with any of the game or rule mechanics for Raw
> > Deal,
> > your description below regarding your current solution doesn't make
> sense
> > to me. Please explain how multiple copies of the card marked as
> identical
> > are solving the problem for you. It's possible that there may be a
> way to
> > avoid the collapsing issue, but I won't know until I understand the
> > technique you're using better.
> >
> > As for the variables approach, what wasn't working for you? If it's a
> > matter of something not being clear in the docs, perhaps I can clarify
> > things here (and then get it fixed in the docs).
> >
> > There are a few approaches to solving the superstar issue that I would
> > probably try. These are based on your explanation of the rules
> below, so I
> > may be missing critical details that render these ideas non-viable. But
> > here's what I'd try....
> >
> > First, there is the issue of identifying each superstar and making
> sure
> > the
> > user only has one. If all of the superstars have a tag from the group
> > isSS,
> > then you can simply verify that only one superstar is used by
> testing that
> > "distinct:isSS.? = 1". This method handles the case of multiple
> instances
> > of the same superstar being allowed. I have no idea if this is the
> case
> > for
> > Raw Deal or not, but I mention it because a few games (e.g. LotR
> and DBZ)
> > do have this kind of mechanic.
> >
> > Now for the nasty bit with matching the cards. I assume each card
> that is
> > specific to a superstar has a tag to that effect, such as "reqSS.Rock".
> > What if you instead included a numeric value with the tag name that is
> > unique to each superstar? This value would be used for both the "isSS"
> > tags
> > AND the "reqSS" tags. For example, The Rock might be "isSS.Rock42"
> and all
> > cards tied to him would be "reqSS.Rock42". Steve Austin might be
> > "SAustin13", etc. I recommend using a leading zero for single digit
> > numbers
> > (e.g. "Rock03"). And now you are wondering why the hell I've stuck a
> > number
> > on the end. :-)
> >
> > Our first rule above has already established that there is only a
> single
> > superstar in the deck. So now our NEXT rule (based on priority
> assignment)
> > can identify the numeric code for that one superstar and save it in a
> > variable. For example, "eval SSid as { val:isSS.? }". If there are
> > multiple
> > superstars in the deck, this will just grab the value for a random
> > superstar in the deck. But if there is only one, this will always
> give us
> > the value we need. This behavior should be fine, since the higher
> priority
> > rule flags the use of multiple superstars.
> >
> > Now we should be able to define a SINGLE card rule that verifies
> that ALL
> > the cards match the superstar. We can do this with a rule like
> "isSS.? |
> > count:reqSS.? = 0 | val:reqSS.? = @SSid". The first term ensures
> that we
> > ignore superstar cards. The second term treats a card with no reqSS
> > tags as
> > always valid, thereby handling cards that are generic and usable by all
> > superstars. The final term verifies that the card's required superstar
> > matches the superstar currently in the deck. If all three terms
> fail, then
> > you know the user has included a card for one superstar with a
> different
> > superstar, at which point the validation error is shown.
> >
> > There is one gotcha to the above solution. This method assumes that all
> > cards requiring superstars only work with a SINGLE superstar. If some
> > cards
> > can be used by multiple superstars, this solution won't work. If
> that's
> > the
> > case (I have no idea), then let me know and I'll see if I can come
> up with
> > an alternate approach for you.
> >
> > Hope this helps,
> > Rob


---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 588-8252
Lone Wolf Development www.wolflair.com





Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/cardvault/

<*> To unsubscribe from this group, send an email to:
cardvault-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/