Ratings & Comments

 

In the picture above the black cannon at f12 is putting the white king in check.  Is that correct for a standard cannon movement? If no, I have to fix some code.  I went to piece-o-pedia and the cannon must jump a screen for the attack.  Am I correct with the following statements:

1) the white king is not in check

2) the black cannon at f12 can not attack anything due to a mess of black pieces in front of it.

3) the white cannon at g1 can take cannon g12

===

I think I am correct, but I want to check with my fellow chess players to confirm that I understand the cannon capture move.

 

Today I was thinking about possible obstacles to more than one chess variant being played by several (or many) people face-to-face presently (or in future) at given location(s), ideally at CV clubs (but at the least at some CVs tournament held at a physical site). One matter is how to determine which variant(s) will be played (all year round or even on one given day), e.g. in a club, but what may entirely determine this at any given time is the CV equipment available at a given location, for a given time period.

We've heard of card sharks, who are good at all sorts of card games that use a standard 52 card deck, but CV sharks might be harder to ever come by in large numbers in offline play, since all CVs do not use the same equipment. Still, offline CV tournaments (or clubs) that involve a relatively small number of CVs (not always the same ones, necessarily) might become relatively common one day. Standardized, mass produced CV equipment that can be used for a large number of existing CVs would be helpful. CVs that can use the same equipment as for chess (maybe with a small number of extra pieces added, as in Seirawan Chess) would be particularly golden, for the time being at least.

There's also the problem of how to make more people interested enough in CVs locally, though a potential CV physical club (or tournament) organizer can learn from any local Bridge, Chess, Go etc. club or tournament organizer that they might know. An extra chore could be to make a pamphlet about whatever are deemed to be the most essential CV 'basics' (besides the CV club/tournament location & hours info) to distribute locally, perhaps even in schools. At the moment tournaments for bughouse just by itself (or as side events to more serious children's chess tournaments) have something of a foothold, in Canada at least, now more often with cash prizes involved. Face-to-face events have one advantage, based on the experience of chess players and organizers, in that perhaps any cheating (especially with cash prizes at stake) could be easier to detect than for online play (sticking to the latter alone has some big advantages otherwise, as we have seen with Game Courier's features, plus chess and/or CV servers that offer fast [e.g. 5-minutes per side] time controls for CV players, for the given CVs that are available to choose from).

Meanwhile, here's a link provided on this very website, which includes mention of a CV Construction Kit:

https://www.chessvariants.com/where.html

I am not sure how this comment could have ended up in this untitled discussion; I am pretty sure I posted it as a reply to Garth Wallace's piece-definition topic. This must be a bug of the posting system. Perhaps an editor can move this comment to the topic where it belongs. Moved. I'm not sure what could've happened to it initially. --BR

From a practical point of view: the Jocly move generator defines each piece type through a 'graph', which is a board-size array. For each square this stores a set of 'trajectories', where each trajectory is a set of (squares, rights) combinations. The 'rights' part indicates under which conditions the piece can move there: when it is empty, occupied by an enemy (the latter still distinguishing royal and non-royal enemies), or never (but passing through it). First occupied square in the trajectory normally makes all later squares inaccessible (but does not affect other trajectories), except when a capture specifies hopper-capture, in wich case it only considers the moves behind the first occupied square. (This obviously was added as a not very general kludge to be able to do Xiangqi.) By listing this for each board square separately, it does allow location-dependent moving, and boards of irregular topologies. Although the principal reason for doing it that way was probably just efficiency: the graphs would never contain any moves that stray off board, so you would never have to test for that during move generation.

The extended Betza notation used by the XBoard GUI (XBetza) indeed implements general hopping as the ability of a step V, or repeated sequence of identical steps VV* (together referred to as a 'leg' of the move) as a condition on the occupancy of the final square of that leg, namely that it must be occupied, but will not be affected. This makes no sense in final legs of a move, but in non-final leg this 'p' modality supplements the usual 'm' or 'c'. It makes no difference between friend or foe (as hoppers usually don't), but XBoard allows the use of the combination 'tp' to limit the hopping to friendly mounts. (At some point the alphabet is just too small... XBoard also uses 'tc' for a 'tame capture', i.e. one that cannot capture royalty.) As you remarked locust capture can be indicated by a non-final leg with capture rights. And lameness as a non-final leg with 'm' rights only.

To define pieces as the Ultima Withdrawer, still another modality is needed. In principle the move can be seen as a locust capture that starts with a King leg, and then reverses direction for a Queen leg of minimally 2 steps. (Which again can be seen as a King leg followed by a Queen leg in the same direction.) You cannot combine this move with a normal Queen move, because that would make the capture optional. (Which in Ultima it isn't.) But if you always force the detour, the move must not be blocked by a friendly piece there. This can be done by also giving it hop rights (so total modality of the first leg 'mcp'). But that still fails when the Withdrawer wants to move away from a board edge. So I needed an extra modality on non-filal legs for that ('o'), which means 'can (temporarily) leave the board. Then 'mcpo' on the first leg would do it. Similarly, the 'Advancer' would be given a move that overshoots its final destination to make a capture, and then inverts direction.

In my proposal for a Betza 2.0 I tried to solve the problem of combination moves like castling (or catapult pieces) by defining a 'u' modality for 'unload'. The idea is to have one piece transport the other. In any case there also has to be a modality for 'friendly fire' (I picked 'd' for 'destroy'), which enables you to capture friendly pieces. A 'u' in a later leg would then leave there what you 'picked up' (= captured or destroyed) on a previous leg.

Move induction (as in Knight-Relay Chess) is also an interesting problem. It could be seen as a move of the induced piece, but then it would have to 'probe' if a friendly Knight is attacking it. This can be done by a leg step that can hop onto friendly Knights only, and use the first two legs of the move to make back-and-forth Knight jumps, and then a final Knight jump if that was possible. Or it can be seen as a move of the inducer, where it hops onto a friendly piece, transports it by another Knight jump, unloads it there and then retraces its steps. When every piece is inducible, and only a single piece type can induce, the latter method is conceptually simpler. Otherwise you would have to assign the inducible moves to every piece. Except that it is rather cumbersome to have the inducer retrace its steps after it unloaded the induced piece. But for convenience you could make a special unload modality for that ('tu'), which would mean 'unload and return'.

As to the ambiguity of move definitions: to get rid of that you would have to abandon the concept of trajectories, but make 'lameness' an intrinsic part of the definition. So each move becomes a set of squares to be modified in some specified way, (usually just the 'from-square' that gets emptied, and the 'to-square' that gets to hold the moved piece or its promotion choice), plus a set of squares on which a certain condition has to be fulfilled with respect to its occupancy (usually that they have to be empty). As mathematical sets are considered the same irrespective of the order in which their elements are mentioned, and can mention each element only once, you would have no freedom in specifying the move. But this quickly leads to very cumbersome descriptions for sliders (which would be decomposed into lame steps of various distances), and even worse for sliding hoppers (which would have to specify each of their distant hops as a number of combination of empty and occupied squares along their path to make sure the move is only allowed if there is exactly one occupied square in the path).

Because of the "inside-out rook" problem, I started trying to define equivalence for pieces in terms of what conditions (relative piece positions) a move can be performed under, until I realized that this was a much better way of defining moves in the first place. the inside-out rook demonstrates that the sequence of steps is entirely irrelevant, only which squares relative to the starting square can it be blocked on and how.

So at this point, I changed my approach. Instead of a path being a sequence of steps, it becomes a destination vector and a set of "tests", where a test is a pair of a vector and a state that must be true of the square that vector away from the starting square for the move to be legal.

A welcome byproduct of defining everything in terms of vectors from the starting square, instead of vectors from the previous step in a sequence, is that "exotic" board topologies become much easier to deal with. The sequence method was fine for hex boards (it's just a different set of basis vectors), but trying to define, say, a bishop on a moebius strip board was weird (try it!). But if all vectors are treated as having the same origin, there's nothing special about it.

Nice, right? Oops, forgot about divergent captures. Okay, instead of just a destination vector, we have a set of results, a set of "things that happen when the move is taken", which can include a destination and/or capture vectors. The Chu Shogi Lion's igui capture can be expressed as a move with a capture vector but no destination vector, since the Lion doesn't move; a null-move like the Lion's jitto is a move where the result set is the empty set ∅. Promotions? Another kind of member of a result set.

There's still a problem with promotion though. We need to know when it's an option. All moves are relative, but pawn promotion happens at a certain absolute position. Let's say that there is a "promotion zone" state for squares, and any pawn step onto a square with that state is a move with a promotion result. En passant can be defined in terms of a capture move to a "just stepped over by a pawn's double move" state. Of course hte problem here is that "state" is very vague. A promotion zone is permanent, but the en passant square only exists for one turn, and there's no way of specifying that sort of thing within this system yet.

Another important thing has been left out: black and white, or more generally sides. At this point I'd been mostly ignoring them and was thinking in terms of just e.g. "knight" rather than "black knight" and "white knight". I was more or less treating captures as explicitly affecting the opposite side. But that's not very flexible (it disallows, say, a hopper that can only use friendly hurdles, or a piece that can capture friendly pieces). Abstracting away the actual human players (who may not even exist, e.g. in a chess problem), what is the distinction between the sides? Alternating turns! Counting from the beginning of a game, white pieces move on odd-numbered plies and black on even-numbered plies (and neutral on all). So we should include, as part of a move's condition (set of tests), which plies it may be performed on, in most cases some number modulo the number of sides. Together with obligate promotion, we can even define oddities like Petkovian half-neutrals, which change sides when moved. Now that we've introduced a time dimension, we can even include that in our test vectors, allowing us to define en passant more concretely in terms of the previous turn's position instead of hand-waving an "en passant square" state.

I'll get into royal status, mimics, what a "state" really is, rethinking captures, and generalizing to almost everything later, but it's getting late and I have work tomorrow.

For a while now I've been playing with the idea of defining chess pieces in strictly mathematical terms. Originally this was meant as a more flexible/descriptive alternative for Betza Funny Notation, perhaps as a way of specifying pieces for chess-variant-playing AIs, but there is also the possibility of defining operations and functions over them, and maybe even proving some things algebraically.

My early attempts were to define pieces as sets of possible paths, where paths are sequences of steps, and steps are vectors; notation would use the Kleene star for unlimited equal steps. So a wazir, for example, would be {(0,1),(1,0),(0,-1),(-1,0)}, and a rook would be {(0,1)(0,1)*,(1,0)(1,0)*,(0,-1)(0,-1)*,(-1,0)(-1,0)*}. Since most pieces are symmetrical it would make sense to parameterize this as a kind of shorthand, but since some pieces aren't symmetrical it shouldn't be assumed (in the way that "a 1,2 leaper" usually implies the (1,-2), (2,1), etc. leaps). This works for the usual steppers, leapers, and riders, and even bent riders; it's basically how people usually think of chess moves, just in more formal terms.

But this starts to get awkward where pawns are involved (and a way of describing chess pieces that has trouble with pawns is seriously flawed!). First off, we need to separate passive moves from captures. That's not too bad; we can even do so by introducing a "capture step" distinct from a passive step, which must be to a square occupied by an opposing piece, and this lets us do fun things like define the Chu Shogi Lion and the Locust. Then there's the initial double move, and promotions. We can introduce a new kind of "step" that is a promotion to another piece type to deal with these: the initial double-step can be implemented by defining a "starting pawn" that has it, where every move ends with a "promotion" to a "basic pawn" piece that doesn't. The promotion step is also strange, because it always happens at the end, but if you define operations that derive pieces from other pieces (like a "double move" operation that derives a Hook Mover from a Rook) in terms of sequence concatenation, you can end up with a promotion in the middle, or even more than one. So we've unfortunately introduced a distinction between "well-formed" and "ill-formed" pieces, and a need for some sort of normalization.

Introducing hoppers also complicates things. We have to introduce another step, one that requires a hurdle like the capture step but doesn't capture it. But now we've introduced the possibility of moves that "collapse": after all, what is the difference between a (1,2) knight move, and a pair of a regular mao-move and a mao-move over an obligatory hurdle?  Or between the latter and a pair of a regular moa-move and a moa-move over an obligatory hurdle? Equivalence is a mess.

I never found a satisfying way of dealing with en passant, or castling. Defining a piece in terms of the path is travels doesn't lend itself to a move where two pieces are repositioned.

Finally I realized that this approach fundamentally allowed for pathological alternate definitions of pieces. For example, take the rook. One or more equal orthogonal steps, right? Now let's define an "inside-out rook": a piece that leaps orthogonally directly to the square right next to its final destination, then slides by orthogonal steps until it reaches its starting square, then finally leaps directly to its final destination. This piece behaves exactly like the basic rook. It's entirely equivalent: any square it can reach, a standard rook can also reach under the same conditions, and vice versa. Yet it is considered a different piece. While the example is obviously contrived, similarly weird things could be produced by operations that concatenate or interpolate paths.

In computer self-play without opening book Capablanca Chess has only about half the draw rate of orthodox Chess (about 16%, vs 32%). These are all games that start well within the draw margin, though. So as play approaches perfection, they should eventually get a 100% draw rate. A large body of opening theory can be viewed as an attempt to play perfectly at least for the first 20 moves, or so, reducing the game phase in which result-changing errors can occur accordingly.

Does FisherRandomChess (Chess960) produce fewer draws than regular Chess when opponents are about equal in strength? How about Capablanca Chess?

I did commented on the video about triagonal. And don't forget about tetragonal. A (1,2,3,4) leaper would be to long for this though :)!

2:35, he came so close to defining the unicorn ('triagonal' slider), then just kinda went "nah".

8:18, looks like probably the best shot of the starting position.  That one pawn on the backmost rank is odd.  It also looks a little different to me, so maybe it's a replacement queen?

I like the "projected" 3D boards, shrinking as the levels go up, for ease of reaching the pieces inside, though I wonder whether it makes seeing moves harder.

https://www.youtube.com/watch?v=3wFQPSEPgWc&feature=youtu.be&fbclid=IwAR2LYMJcOnnWGPuNDp03EOvKjtxy7DeLBg2UcNKtyxC-sBVULLOs52wl1Sk

Here's a sub-wiki re: Glossary of Chess, under which a brief description of two-board-using 'Basque Chess' can be found. I'm wondering if this match playing technique in any sense properly qualifies as a chess variant. It sort of reminds me of my own recent attempt to create a four-board-using variant (as inspired by this thread's subject heading), i.e. my '3D Chess War' idea, which I'm also not sure should be called a real variant (whether or not it proves to be at all enjoyable, if tried):

https://en.wikipedia.org/wiki/Glossary_of_chess#B

Sound good!

 

I propose that Capablanca Random Chess be left exactly as the inventor described and a new variant be developed. For a name I suggest Capablanca Shuffle Chess (CFC). This variant would have the initial placement of the pieces randomly placed. No requirement for all the pawns to be protected, bishops could start side by side, the queen and archbishop could also start side by side. Initial king position, rook positions, and castling as in Capablance Random Chess. Any comments or suggestions?

Capablanca Random Chess was supposed to be a mix of Capablanca Chess and FisherRandomChess. However neither of these variants required all pawns to be protected. Also FRC did not require that Bishops not be adjacent. If this adjacency rule is not used then logically the rule that Queen and Archbishop not be adjacent would not be applicable. If a CRC game changes the rules from the original inventors rules does the name need to be changed out of respect for the inventor and for consistency? There is a game called Modern Capablanca Random Chess where the black pieces are placed in an inverted order compared to the white pieces.

I would recommend to forget about the protected-Pawn restrictions in the numbering system. The inconvenience of not having direct mapping formulas between numbers and positions seems much worse than having some numbers that correspond to invalid positions.

Note that WinBoard already allows positions to be entered by number, and that the World probably would not become a better place by having ChessV and WinBoard use incompatible numbering systems.

The WinBoard system is a generalization of the traditional Chess960 numbering, to make that applicable to almost any variant. For each piece type you divide the total number by the number of placements for that type (for determining placement of subsequent pieces), and use the remainder as placement code for the current piece type. If the variant has normal castling rather than Fischer castling, you first place the  King and Rooks (or whatever serves as castling partner) in their normal positions. If the board width is even you then place all pairs of color-bound pieces such that they are on different shade. Then you place all remaining pieces on the still open squares, ignoring square shade. In games with Fischer castling you are then left with 3 opens squares, and occupy them by the King between the castling partners.

Currently the WinBoard implementation has some limitations: numbering is not unique if a certain color-bound type occurs in more than two copies. (As this never happened in any of the supported variants, I did not bother with that case.) Also, the order in which pieces are placed depends on the piece encoding WinBoard happens to use, traversed high to low in order to make sure Q is placed before N. And it only recognizes Bishop, Ferz and Alfil as color bound, placing them in the order A, F, B. (Relevant for 'Courier960'!)

Especially the piece order seems hard to objectively define so it would cover every conceivable variant. I want to propose to derive it from a 'mother position', which for Chess960 obviously would be the FIDE array. The pieces can then be ordered according to where they stand on the baseline in this reference position, e.g. for white from left to right this would lead to the order R, N, B, Q, K. They would then be placed in top-down order: K, Q, B, N, R. But B is color bound and present in multiple copies, so it gets precedence: B, K, Q, N, R. Now in variants with castling K and R drop out (either done first or last, but always in a predetermined way), so the final order is B, Q, N, as in Chess960. For CRC it seems logical to use the Capablanca position as reference (as the name suggests that).

It should be easy to write a universal shuffling routine that takes a given position and a random number, and then shuffles that position according to the number. Unfortunately WinBoard now places the super-pieces in the order C, A, Q, which is not what the Capablanca start position would suggest when traversed from left to right.

Why does ChessV not support CRC?  Simply because it hasn't been a priority.  Nor, as far as I know, has anyone previously asked for it.  But I will add it since it shouldn't be too difficult.  One thing I will need to do it find a range of position numbers with a unique mapping of position numbers to actual positions.  FRC has this but CRC does not and the rule that all pawns must be protected makes this difficult.  I could just have a database of positions I suppose.

H.G. Muller: Thanks, I did not think of looking at Winboard. This is what I wanted. However, if you know of an engine that plays CRC I would also like to know about that.

Please contain your emotional outbursts. While I normally enjoy fixing bugs, I'm less inclined to do so when someone makes a huge stink about one. So, for now, I'll just tell you how to work around it. Open another tab, log in to the site, then go back to the tab where your comment was seemingly lost and reload it.

*** The comment-entry script again deletes your message when you are not (or no longer) logged in. This website is total crap! ***

I am not sure what exactly you are looking for. An example of source code? If so, in which programming language?

The WinBoard/XBoard GUI supports CRC, and shuffles a start position for it. (It can in fact do that for any chess variant it supports.) But it is not an engine.

 

If the trouble is just writting initial position code I can guide you through it. You have examples on this wesite with the chess960 preset :)!

I would like to eventually include Capablanca Random Chess in my PR_Chess engine.  I am looking for some

software that determines the starting positions.

ChessV plays many Capablanca variants but technically not Capablanca Random :(!

May I ask why?

Is there a chess engine that plays Capablanca Random Chess?  (SMIRF link is broken).

I had also decided to scrape the extra initial moves of the pieces starting on the bruhaha squares.

In his initial game of Bruhaha Greg Strong has done this in order to have extra opening possibilities.

But in these games it is not that needed. Only the champions has to suffer as he cannot jump to the 3rd rank during his first move. So maybe he will be moved twice in the opening :)!

Hello again folks,

While reading Fergus's "How to enforce rules in game courier"  I rethought the idea of castling (which did not exist until now) in the 2 apothecary games. Even if the game starts with connected rook,s tucking the king to more safety while plunging the rooks into action seems a good extra choice. And I figured as the board is wider I could allow more options, and giving the fact that moving the king closer to the edge is usually more desirable I decided for two sub options in the closer to the middle castles. A specific choice of castling will be available only if the king path to it's destination will be unobstructed, the rook's path to it's destination is unobstructed by anything else than the king and both the rook to be moved and the king have not been yet moved; also the king needs not to cross a checked square in it's path :)!

The king's path is given by a diagonal step back towards the rook and the horizontal steps until destination.

The six castling options are:

1. King side long castle: The king moves (for white) through g1&h1 and lands on i1. The king side rook then jumps on h1.

2. Opposite side long castle: The king moves (for white) through e1&d1 and lands on c1. The king side rook then jumps on d1.

3. King side short castle: The king moves (for white) through g1 and lands on h1. The king side rook then jumps on g1.

4. Opposite side short castle: The king moves (for white) through e1 and lands on d1. The king side rook then jumps on e1.

5. King side short spread castle: The king moves (for white) through g1 and lands on h1. The king side rook then jumps on f1.

6. Opposite side short spread castle: The king moves (for white) through e1 and lands on d1. The king side rook then jumps on f1.

I found the solution. Read my comment in the game.

I attempted to move a square in voidrider chess.  My 1st move e2-e1; -e2  

I think that is legal based on the game rules but I am getting a banned input error

@Fergus

Ok, Got it!...

Sorry for the trouble :)!

@Fergus

Ok, Got it!...

Sorry for the trouble :)!

When you need the value of a variable in an expression, you have to prepend a # to its name or precede it with the var operator. In "if coun1", "coun1" just returns the string value "coin1". Likewise, in "if coin2", "coin2" just returns the value "coin2".

I did save it the way you suggested. The way it was was obviously wrong. The problem is still in the set instruction as far as I can see :(!

Yes, this was one of my later atempts, it does not work without the paratheses :)!

Contrary to the code you posted, this is in your code:

set coin1 (rand 0 1);
set coin2 (rand 0 1);

This code sets coin1 and coin2 to 

Array
                        (
                            [0] => rand
                            [1] => 0
                            [2] => 1
                        )

, not to a random number. You need to remove the parentheses for it to work right.

Ok, here are the 2 apothecaries:

https://www.chessvariants.com/play/pbm/play.php?game=Apothecary+Chess+1&settings=Apothecary1working

https://www.chessvariants.com/play/pbm/play.php?game=Apothecary+Chess+2&settings=Apothecary2working

They are mostly the same, so there is one or the other.

Please ignore the move forcing attemps. For now just the initial position matters. A long time ago I wanted to move forward. I still do. But the initial position still has errors and that should be taken care of first.

Give me a link to what you're working on, and I'll take a look.

Unfortunately I seem to still get the behavior I got two years ago, meaning the second part (the else part) of the code always executes in the two if statements conditioned by the coin1 and coin2 variables. I had tried to use rand 1 2 instead of rand 0 1  and set (rand 0 1) meaning adding parentheses. None of these work. They were desperate attempts anyway .

Game Courier selects a new seed for each game, and it keeps the same seed throughout a game. To test this, you need to make sure you are playing separate games each time. You could issue invitations to yourself, try it out on different browsers, or start each game in a new private or incognito window. If you go back to your preset's menu between games and refresh your cache, that should also work.

Hello everybody!

Once again I need some help with the game courier programming.

I am attempting once again to write rule enforcing presets for my 2 apothecary games.

In my first presets, which I use as basis for development, I had written a short code meant to choose out of the 24 legal initial positions.

Next there is an explanation about what the code is supposed to do.

As I have written in my article apothecary 1&2 have 24 initial possible position which can be chosen by 2 throws of coins and a throw of dice. The first coin throw would decide the placement of the major pieces. If it is centralized (on the d,e&g files) this should be 1 otherwise (on the b,e&i files) it should be 0. The dice throw then decides which of the 6 permutations of pieces occupy the 3 designated fields on the files decided by the first coin (they occupy the 2nd rank for white and the 9th rank for black). The second coin should decide if the bishops occupy the remaining files closer to the king (bishops in) when the coin is 1 or  closer to the edge (bishops out). Take note that the fields on the a and j files (ahead of the rooks) are empty.

In order to achieve  that I had used the following code for apothecary 1 (for 2 there is just a piece naming difference so far):

empty b2 c2 d2 e2 g2 h2 i2 b9 c9 d9 e9 g9 h9 i9
set coin1 rand 0 1;
set coin2 rand 0 1;
if == coin2 0:
drop Q any b2 e2 i2;
drop A any b2 e2 i2;
drop G any b2 e2 i2;
copy b2 b9;
copy e2 e9;
copy i2 i9;
flip b9 e9 i9;
else:
drop Q any d2 e2 g2;
drop A any d2 e2 g2;
drop G any d2 e2 g2;
copy d2 d9;
copy e2 e9;
copy g2 g9;
flip d9 e9 g9;
endif;

if == coin1 0:
drop N last b2 c2 d2;
drop N first g2 h2 i2;
drop n last b9 c9 d9;
drop n first g9 h9 i9;
drop B last b2 c2 d2;
drop B first g2 h2 i2;
drop b last b9 c9 d9;
drop b first g9 h9 i9;
else:
drop B last b2 c2 d2;
drop B first g2 h2 i2;
drop b last b9 c9 d9;
drop b first g9 h9 i9;
drop N last b2 c2 d2;
drop N first g2 h2 i2;
drop n last b9 c9 d9;
drop n first g9 h9 i9;
endif;

My questions are:

1. How do I know that the preset sets a new random seed, if it does, as I do not seem to find any mention on that in the developer guide besides the constants chapter (by the way the link to fisher random chess from the developer's guide seems to be wrong although I could find the game through game courier->games to play-> the letter F->...)?

2. How would I test that the distribution among the 24 position is constant? The play button (playing with myself) yields the same results always?

Thanks!

You're probably right, in hindsight. Still, I'm still thinking over my hypothetical alternative rules. Could make for an interesting variant, if the idea is sound; I'd say in that case it's sort of a 3d variant after all, vaguely like Greg's 'Backlash', yet somehow simpler(!). It's also like that in that apparently the same player always gets White, or Black, on every board.