| Author |
Message |
Paul Bonham (Kaduflyer)
New member
Username: Kaduflyer
Post Number: 1
Registered: 9-2014
| | Posted on Saturday, September 13, 2014 - 7:54 am: | |
I came across this issue trying to create a custom piece:
If you edit chess.zrf and add this line to the Knight piece in regular chess:
(attribute never-moved? true)
Then edit the line near the top of the file that defines leap2. Change it from this:
(define leap1 ($1 (verify not-friend?) add) )
to this:
(define leap1 ($1 (verify not-friend?) (verify never-moved?) add) )
no Knight can ever move in chess! That's because even though you set the attribute to true, the Zillions runtime somehow overrides that and sets it to false. Even if you later do a
(set-attribute never-moved? true)
it still remains false.
I haven't found any way to solve this, yet the chess King and Rook don't have this problem, they already have a never-moved? attribute and it does get set to true initially.
This is a major bug unless there's something silly I don't know about. |
Alfred Pfeiffer (Apf)
New member
Username: Apf
Post Number: 17
Registered: 7-2000
| | Posted on Saturday, September 13, 2014 - 3:50 pm: | |
Hello Paul,
think for the move generation that you have a cursor that points to a location of the board. At the begin it points to the square of the piece that should move. After the $1 direction this cursor points to an other square (a possible goal), no longer to the piece you will move. The tests (verify ...) always apply to the field where the cursor points to (not to the piece!). Therefore: if you will check the status of the piece you wish to move then do this before you change the cursor position with the $1. For example:
(define leap1n ((verify never-moved?) $1 (verify not-friend?) add)) |
|