| Author |
Message |
Patrick S. Duff (Pduff)
| | Posted on Friday, January 19, 2001 - 11:15 pm: | |
Just like I can now use (move-type) inside a move definition, I'd like to be able to use (piece-type) inside a piece definition.
Then instead of saying something like:
(or (piece? Hole1)(piece? Hole2) ... (piece? Hole99))
I could define all of these pieces as type Hole, then just do
(piece? Hole)
There are several other places in the ZRF language where piece-types would be useful too. |
Jeff Mallett (Jeffm)
| | Posted on Saturday, January 20, 2001 - 9:14 am: | |
You're saying you want to differentiate one set of pieces from the rest of the pieces by their "holiness". This sounds like a piece attribute. I'd use:
(piece ... (attribute Hole true) ...)
as a template for defining Hole1, Hole2, etc. Instead of
(piece? Hole)
to test whether it's a hole, I'd use the attribute, i.e.:
Hole
This should be a more general solution as a piece can have many attributes (be a part of many different sets.) |
Karl Scherer (Karl)
| | Posted on Tuesday, January 23, 2001 - 7:04 am: | |
Dear Jeff Mallett,
I found that categorizing a set of pieces by an attribute only works in the positive,
not in the negated case:
If Hole is a piece-attribute,
I can say
(verify Hole),
but I cannot say
(if not-Hole ...)
Zillions reacts to this with an error.
I am not even sure whether
(if Hole...)
works.
Jeff, please correct me if this is not true
or what I have coded wrong here.
Thanks, Karl |
Jeff Mallett (Jeffm)
| | Posted on Tuesday, January 23, 2001 - 11:28 am: | |
There are special Zillions keywords such as not-empty?, not-attacked?, etc. that were defined for convenience. However, for testing your own properties you need to use the "not" keyword as follows:
(verify (not Hole)) |
Karl Scherer (Karl)
| | Posted on Thursday, January 25, 2001 - 6:19 pm: | |
Thanks, Jeff.
OK, one further question concerning
piece-attributes which might be of general interest (I have never bothered testing this):
When a piece is changed from one piece-type to another (via "change-type"), does it retain the piece-attributes of the old piece or does it have newly initialized piece-attributes as given in the piece-definition of the piece-type it is being changed into?
(I could not find any answer to this in the help texts.) |
Jeff Mallett (Jeffm)
| | Posted on Monday, January 29, 2001 - 12:23 am: | |
Interesting point. If you are doing a change-type and the new piece-type has different piece-attributes than the old piece-type, you should initialize them yourself with set-attributes. Zillions won't initialize the new piece-attributes (as it would if it were a brand new piece).
It happens that the way it is implemented in Zillions 1.x is that each piece in reality carries the piece-attributes of all the piece-types, so you could access the old or new attributes. The change-type doesn't touch the piece-attributes. Therefore if the "lasers-fired?" attribute was true for your Bishop it will still be true after the Bishop is turned into a Rook. (I can't guarantee that a Zillions 2 will still behave this way though.) |
|