| Author |
Message |
Patrick S. Duff (Pduff)
| | Posted on Thursday, May 17, 2001 - 3:42 am: | |
I want the moving piece to swap positions with any piece which has the "connected_Friend?" position-flag set.
I'm very close to having this working:
(moves
(
...[execute code to set position-flags]
...a1
...(if (position-flag? connected_Friend?)
......(if (not marked?)
.........cascade
.........from
.........back
.........to
.........(go from)
.........add
...)..)
...(while (on-board? next)
......next
......(if (position-flag? connected_Friend?)
.........(if (not marked?)
............cascade
............from
............back
............to
............(go from)
............add
)..)..)..)
)
Suppose the moving Pawn is at e8, and it can swap places with the Rook at b8, the Knight at c8, the Bishop at d8, the Queen at f8, or the King at g8.
I expected the following five move choices (the two calls to "(not marked?)" prevent the Pawn at e8 from swapping places with itself):
Pawn e8 x b8 Rook b8 x e8
Pawn e8 x c8 Knight c8 x e8
Pawn e8 x d8 Bishop d8 x e8
Pawn e8 x f8 Queen f8 x e8
Pawn e8 x g8 King g8 x e8
Instead, I get the following five move choices:
Pawn e8 x b8 Rook b8 x e8
Pawn e8 x b8 Rook b8 x e8 Knight c8 x e8
Pawn e8 x b8 Rook b8 x e8 Knight c8 x e8 Bishop d8 x e8
Pawn e8 x b8 Rook b8 x e8 Knight c8 x e8 Bishop d8 x e8 Queen f8 x e8
Pawn e8 x b8 Rook b8 x e8 Knight c8 x e8 Bishop d8 x e8 Queen f8 x e8 King g8 x e8
What am I doing wrong here? Why isn't the "add" writing out the move and clearing everything so the next time "cascade" is executed it will start a new move choice?
Help, please! |
Jeff Mallett (Jeffm)
| | Posted on Thursday, May 17, 2001 - 1:36 pm: | |
>Why isn't the "add" writing out the move and
>clearing everything so the next time "cascade"
>is executed it will start a new move choice?
Because "cascade" wasn't designed like this. Instead, "cascade" was designed so that you could create a number of moves with similar sequences without having to recreate the sequences from scratch each time.
The cascade list is cleared after the entire move block. For documentation on this, and when things are cleared in general, please see "The Internals of Movement:When Move Data is Reset" in the Zillions Language Reference. |
Patrick S. Duff (Pduff)
| | Posted on Friday, May 18, 2001 - 12:06 am: | |
I've read that exact section in the help file about a dozen times over the last couple of years, and it still trips me up. You're right, I now see where it says that the cascade list is cleared at the beginning of the entire move block.
But it also says that the position-flags are cleared at the beginning of the entire move block.
This presents me with a problem. I don't see how to swap two pieces without a cascade, and I don't see how to generate all of the possible swap moves without losing the position-flags.
I could do it if you allowed something like the following:
(moves
...[execute code to set position-flags]
...a1
...[move-generation-block]
...(while (on-board? next)
......next
......[move-generation-block]
)..)
Because then I could write the [move-generation-block] to test the current position to see if the moving piece can swap with the piece on that position.
It's sort of like a (drops ...), except the piece isn't dropped from the off-board store, it is moved from somewhere else on the board.
I've been puzzling over this for three days now. I can generate one swap move easily, I just can't figure out how to generate all five (as in my example in the message which started this thread). It shouldn't be so hard to do something simple like swapping two pieces! I keep thinking I must be missing something obvious, but so far the solution has eluded me.
This is yet another case where persistent position-flags would save the day. I keep encountering situations where I don't want the position-flags to get cleared at the beginning of the move-generation block. I'm thinking about creating a parallel board filled with pieces which I never move. Then I could emulate persistent position-flags by having an extra player which
goes in the "up" direction from every position on the game board and puts a true or false attribute-value on each piece on the parallel board. During the next player's move-generation blocks, I could then use the piece-attributes on the mirror board as if they were persistent position-flags. Before I go to this extreme, do you have any other ideas?
[Something just occured to me! If I do the mirror board, instead of just boolean piece-attributes, I can code information in the piece-type I put on each position. This would mean I could implement an n-valued logic instead of just binary!]
You made piece-attributes persistent, and position-flags temporary, but why did you stop there? I would have implemented piece-attributes, position-attributes, piece-flags, and position-flags. Then the attributes would have persistent values, and the flags would have temporary values. Wouldn't that be more flexible? Please consider this a suggestion for the next release!!! |
Peter Aronson (Peteraronson)
| | Posted on Friday, May 18, 2001 - 7:15 pm: | |
Is it actually necessary to swap the pieces? Could you use change-type instead, so instead of swapping the Pawn for a Rook, turn the Pawn into a Rook, and a Rook into a Pawn? The change-type command clears nicely after every add. True, you'd have to include a bunch of logic to determine the piece you're "swapping" with, but it should work. |
|