Comments/Ratings for a Single Item

Here is a piece of code which works for another pair of drops (plus a third
one on a phony square). The macro drops a pair of halfling long-leapers on
b1 and g1, or b8 and g8, by clicking on g1 or g8, after veryfing that
shooters, coordinators, advancers or withdrawers haven't been dropped by
either player(only one pair of halflings will be dropped -- the same type
for each player, but the first player chooses where -- and which kind --
to drop), and that the two squares to receive the halfling long leapers
are empty . (It also drops a third one on DroppedLongLeapers, to prevent
the drop of shooters, coordinators, advancers or withdrawers.)

(define drop-halfling-long-leapers-on-g (
	(verify (and (neutral? WhiteKingMoved) (neutral? BlackKingMoved)))
	(verify (empty? DroppedShooters))
	(verify (empty? DroppedCoordinators))
	(verify (empty? DroppedAdvancers))
	(verify (empty? DroppedWithdrawers))
	(if (am-white) b1 else b8)
	(verify empty?)
	(if (am-white) g1 else g8)
	(verify empty?)
	cascade
	(if (am-white) b1 else b8)
	cascade
	DroppedLongLeapers
	add
))

The procedure is called in the drops part of the piece. So something like

(if (am-white) 'this square' else 'that square'
(verify empty?)
cascade
(if am-white) 'that square' else 'this square'
(verify empty?)
change-owner
add


should work, at least if the rotational or reflectional squares are known
-and empty?

'I'd like to set up a game where white chooses a piece to use and drops
  it on his first rank.  This causes an identical blue piece to appear 
  blue's first rank on the rotationally (or perhaps reflectionally)
  on symmetrical square...'

I propose to define an additional direction (here called 'mirror') that
links the squares from the first row to its symmetrical field. Example:

  (board
    (Board-Definitions)
    (links mirror (a1 h8)(b1 g8)(c1 f8)(d1 e8)(e1 d8)(f1 c8)(g1 b8)(h1
a8))
  )

Then in the setup phase you should be able to determine 'easily' by use
of
this additional direction, where related pieces are to be placed.

For different variants of symmetry use different lists for 'mirror'.

No, I don't think you can do that.

There is a way to do what you want.
 
Create a set of dummy positions for each player which will be the amount
of pieces which have this particular attribute.
 
Place on each of these positions dummy pieces.  Let's call them
'Token'.
 
When a piece has its attribute specifically changed, capture one of that
player's Tokens.
 
Have the loss-condition set to 'pieces-remaining 0 Tokens'.
 
If you need to toggle this condition, instead of capturing the Token,
change it to a piece called 'null'.

To be able to drop pieces on both sides of the playing field:

Start with filling all the set-up positions of Black with dummy pieces
called 'null'.  Be sure these belong to the appropriate player, Black
nulls on Black's side.

White will begin with all its pieces off.  Black only has the nulls.

Then specify the exact positions in the drops.  Example: The macro will
read, '(define piece-drop ($1 (verify (and empty? (piece? null
$2)))(change-type $3 $2) add))'.  In the drops section of the King piece
could read, '(piece-drop e1 e8 King)'.

This can be done to desired patterns, mirror or whatever.  The programmer
can have several options in the same drops section for each piece.

If there is a checkmate condition for the King, just place a Black King
in
a dummy position to satisfy the Zillions program's initiation.

I don't know whether it is of any help for anyone, but my zrf for Chess on
a Larger Board with not so few Pieces Dropped provides a contrived example
where the first player to drop Halflings chooses them for both sides.

Michael, why use drops at all?  Just have a piece on a dummy square and use
from -- the move will appear to be from the piece the from is aimed at. 
See the ZRF for Neutral King Chess for an example.  That way you don't
need to drop anything.

Create a dummy position called 'post'.  And place a Black Pawn in it. 
Then with each move, change-owner this piece so that it switches sides
with each move.  It should be the opposing side's piece at the start of
each move.

Then in the win-condition include the following:

(absolute-config (opponent Pawn)(post))

This should work fine.  The condition will not be true until the opponent
has completed their move.

Peter's idea is a good one, but he left out part. The next direction used
in the macro presumes that all spaces on the board have been linked
together with the next direction, and a1 is the first position on the
board. If your ZRF didn't already have this set up, you would have to set
it up before this macro would work.

The OFF position would be defined as a position after the end of the 
board. Here is a macro that would work just as well and is more optimized.

(define Pawn-Win (
   (verify (in-zone? king-capture))
   a1 
   (while (and (not-piece? King) not-enemy?) next)
   add
))

There is no need to check for OFF or even for (on-board? next) -- unless
you loop the whole board back to front, which you don't need to do. A 
while loop stops once the end of the board is reached. Besides this, the 
assumption is that the King is always on the board, and so the King would 
be reached before the while loop went off the board.

Clicking on the Pawn and having capture a piece in a dummy position is
good.  Just remember that this must work with or without Smart Moves. 
So,
you might create a macro with a simple change-type command on that Pawn.

In fact, you could change-type into a special looking dummy piece which
denotes that it has won.  For instance, a Pawn with a halo.  Just the
presense of this piece would negate the necessity of the dummy position. 
The entire macro for the Pawn could read:

(define win-move
(
(verify (in-zone? end-zone))
(change-type HaloedPawn)
add
)
)

I've found that a simple (add HaloedPawn) will not work since it is not
a
primitive that occurs during the move but after the move.

Then the win-condition would be the mere presence of this special Pawn. 
Neat, huh?

Another method could be to have each move look for the presense of an
enemy
Pawn in the zone and change-type it for the win.

The basic question is how do you want the game to end.  Do you want it to
end before a losing player can move, or after?

I suspect that your own idea of using a PseudoKing is what would work best.
And I don't think it entails an extra click to end the game. Just make
the goal of the game the checkmate of the PseudoKing on the dummy square,
and make it possible to check it only by a Pawn on the square it must
reach to win. So long as the opponent can't take it, the player will win
when he reaches that space with his Pawn. But if the opponent can take it,
then the game will continue.

Here is what may be the shortest and most efficient way to do what you
want. In addition to creating a dummy position with a PseudoKing on it and
making the goal checkmate of this piece, use an otherwise unused direction
to link any space the Pawn must reach to win with the dummy space. Then
give the Pawn some extra move code as simple as (tovictory add), assuming
that tovictory is the direction you used. This dispenses with the need to
test for zones or change a piece's type. And that dispenses with the need
to create zones and an additional piece type.

Epaminondas has a delayed win condition (ZRF available at the ZoG site). 
It uses the method outlined by LL Smith.  A checkmate solution won't work
in that game because a player can avoid loss both by capturing the enemy
piece that has attained the far row, and by moving a piece himself into
the (opposite) far row.

If the pieces don't move after they are dropped, make any pieces dropped
outside of the scoring zone neutral, and give each player enough hidden
pieces (on dummy positions or something) so that the neutral player can't
win.

I would really need to see the code of this implementation to give a good
evaluation.  I would only be guessing at this point.

The game of Alapo has the same winning conditions you describe ... 
You may be able to find a good way to do it by looking at the Alapo ZRF.