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/
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/