[ Help | Earliest Comments | Latest Comments ]

[ List All Subjects of Discussion | Create New Subject of Discussion ]

[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments by HGMuller

⇩Latest ⇩Later ⇩Reverse Order⇧ Earlier⇩ Earliest⇧

Game Courier. PHP script for playing Chess variants online.[All Comments] [Add Comment or Rating]

H. G. Muller wrote on Sat, Apr 30, 2022 08:55 PM UTC in reply to Fergus Duniho from 01:29 PM:

The original alfaerie set should be considered obsolete now that we have alfaeriePNG, and its use should be discouraged. The anti-aliased version looks so much better. But the anti-aliasing causes pixels on the boundary of the black outline and the colored interior to be darker versions of the interior color, by mixing in the black. So simply looking for an exact match of the original color fails to replace the boundary pixels. This problem can be solved, though: you could test every pixel for the value of the briggtest RGB component, and deduce from that by which factor it is darkened compared to the interior color. And then darken the replacement color by the same factor. (This assumes the outline is pure black.) To make it resistant to multi-color originals you could even check whether the other two RGB components of the original are indeed similarly darkened (within some tolerance for rounding.)

H. G. Muller wrote on Sat, Apr 30, 2022 07:42 AM UTC in reply to Fergus Duniho from 03:02 AM:

Does it also work for the anti-aliased piece sets?

Chess 66. Board based on the 8x8 arrangement - with the difference that 66 fields are now available. (8x8, Cells: 66) [All Comments] [Add Comment or Rating]

H. G. Muller wrote on Thu, Apr 21, 2022 08:43 PM UTC in reply to Bn Em from 07:38 PM:

One way to program it would be to have a single square 4/a4, and to introduce a number of extra piece types, each especially adapted to have the moves that the switches would allow. That is, you would have a special Rook for on a3, which would move forward both as a normal Rook, or with a move that switched file after one forward step. (And for a2 one that switched after 2 forward steps, etc.) When a piece of this Rook family would land on an edge file you make it automatically 'promote' to the kind of Rook that belongs on that square. When a Rook landed on a4 there would be a kind of promotion choice: it either stays/becomes a normal Rook, or one that replaces its forward move by a Left-Griffon move. Same idea for the other piece types.

I suppose that through this method I could even have the Interactive Diagram play Chess66. A user-supplied JavaScript function WeirdPromotion would take care of the 'promotions'.

H. G. Muller wrote on Thu, Apr 21, 2022 07:54 AM UTC:

Just to make sure I fully understand this:

A Bishop on a4 could move along c5-d6-e7-f8 but not b5-c6-d7-e8. For a Bishop on 4 the reverse would be true. But that also means a Bishop on a4 can only be captured from c5-d6-e7-f8 and not from b5-c6-d7-e8.

If this is true the only thing that 'switches' are the connections of 4/a4 to the upper board half. These are either to a5 (f) and b5 (fr), or to a5 (fl), b5 (f) and c5 (fr). And the switch is only in a determined state when 4/a4 is occupied. (And that state has to be chosen as part of the move that occupies it.) When the square is empty you can use all the connections to enter it from above, or to leave it in the same move when you entered it from below.

The intepretation of this that I consider conceptualy the simplest is that 4/a4 is indeed a single square cell, but that the setting of the switch is extra game state. Which can conveniently be indicated by placing the piece that occupies it in the right or left half of the cell, as the distinction only has to be made when the square is occupied. In a computer implementation one could implement the state of the switch through making separate cells of 4 and a4, with only single exits to 5th rank, and duplicate the exits to it from a3 (f), b3 (fl) and b4 (l) so that one connects to 4, the other to a4, both available at any time. But that still would require some 'unnatural' treatment of the spaces 4/a4, to consider one blocked when the other is occupied.

The issue of teh Knight is really an independent one. If the Knight's move is defined 'subtractively', by excluding moves that a Queen can do, its mobility is reduced in the vicinity of the switch, as Q gets extra moves there. In a 'constructive' definition of the Knight move, it would benefit from the switch topology to get extra moves as well.

H. G. Muller wrote on Mon, Apr 18, 2022 08:58 AM UTC:

A somewhat simplified version of the same idea is this:




							h5
a4

There is only a single, double-width cell a4 here, and there is no additional game state to distinguish between an occupant being in the right or left half of it. Moves (or move continuations) that leave a4 to 5th rank can choose whether they consider a5 or b5 the only square that connects to the upper edge of a4. So a4 has 2 'north' exits (to a5 and b5), two 'north-east' exits (to b5 and c5), and a single 'north-west' exit (to a5).

The difference with the rules that were given is that 'forward' moves even fork from a4, in addition to a1-a3.

How a Knight should move in the vicinity of the switch fields depends on which of the (normally equivalent) descriptions of Knight moves one adopts for the regular part of the board. The description "all two-step King moves that cannot be made by a Queen" is a rather unusual one; commonly one finds "one orthogonal King step followed by an outward diagonal one" (i.e. a non-lame Mao) or L-shaped "2 orthogonal steps plus a perpendicular one". Where the latter might also allow the move to start with the short leg. In my opinion the non-lame Mao description would be most intuitive here.

H. G. Muller wrote on Mon, Apr 18, 2022 06:36 AM UTC in reply to Gerd Degens from 06:22 AM:

Right. So there is no path 4-a3-b2-c1. Which is what I meant, and needed to be said, because in the representation I had drawn, it looked like there could be.

I am still looking for a somewhat more intuitive description. It looks like 4 and a4 are really the same cell, (double width in my drawing), which always borders b4. And that there is a sliding door that either closes off the connection with a5 or b5, which has to be set as soon as you enter 4/a4, and can then not be altered until you leave it. (Which could be on the same turn.) Entering from above forces you to set the door such that you could enter.

H. G. Muller wrote on Mon, Apr 18, 2022 05:53 AM UTC in reply to Gerd Degens from 05:26 AM:

By a Bishop. In the way I had drawn it, the orthogonal moves you describe would not enter a4' directly; they would enter a4, and then optionally transfer to a4'.

The other phrase you quote was intended to describe what happens when you start on a4/a4'.

It is still a bit ambiguous how a knight could move from h6 if h5/h5' is occupied, (and the switch thus in a known position).

H. G. Muller wrote on Sun, Apr 17, 2022 08:32 PM UTC in reply to Gerd Degens from 08:10 PM:

What I meant is that a4' cannot be reached from a3.

My description was not complete, though, as I did not mention what would happen when a move starts from or ends on a4/a4'. I understand now that when you end there you have to choose which of the two to occupy. Which is only relevant for when you move into the upper board half; a move into the lower board half would always look as if you started from a4.

H. G. Muller wrote on Sun, Apr 17, 2022 06:54 PM UTC in reply to Fergus Duniho from 05:12 PM:

The way I understand it is that ranks 5-8 are shifted one square left:




		h5	h5'
a4'	a4

Whenever a move passes through a4 from below, it can be continued normally, or like the upper board half was not shifted (i.e. from a4'), and similar for h4 reached from above. a4' cannot be reached from below.

Darza. Members-Only Lin Carter's "Darza" (Callistan Chess) from "Renegade of Callisto". (7x9, Cells: 63) [All Comments] [Add Comment or Rating]

Since this comment is for a page that has not been published yet, you must be signed in to read it.

Devingt Chess. Decimal chess with 20 pieces per side including Sages (moving as Camels).[All Comments] [Add Comment or Rating]

H. G. Muller wrote on Wed, Apr 6, 2022 10:42 AM UTC:

Well, if doing it the hard way turns out to be too hard, it might not be such a crazy idea after all to do it the easy way instead.

H. G. Muller wrote on Sun, Apr 3, 2022 05:36 PM UTC in reply to Jean-Louis Cazaux from 04:38 PM:

The Play-Test Applet would have no problems to generate GAME code that handles the castling and the e.p. capture as desired, when the King's move is defined as KisO2isO3, and the Pawn's move as fmWfceFifmnDifmnH. The promote-to-captured can be requested by prefixing the pieces in the promoChoice string with a *. I am not completely sure whether it would then suppress the highlighting of a Pawn step to last rank if there is nothing to promote too, but in any case it would not accept such a move if the user selected it as destination.

Taijitu Qi. Xiang Qi pieces are joined by (but not combined with) their duals. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]

H. G. Muller wrote on Thu, Mar 31, 2022 06:09 AM UTC:

I think the 2 x 2 is a typo, and that this game uses a standard Xiangqi board. Perhaps the error was inspired by the fact that on a traditional Xiangqi board the Palace does look like a 2x2 area of squares, with a diagonal cross in it.

Tardis Taijitu. Xiang Qi board but with movable, bigger-inside-than-outside Fortresses. (3x(9x10), Cells: 144) [All Comments] [Add Comment or Rating]

H. G. Muller wrote on Tue, Mar 29, 2022 08:19 PM UTC in reply to Bn Em from 07:38 PM:

This concept of Tardises is very nice, but I am a bit worried that when they can be used to teleport Kings, achieving checkmate would be a hopeless task. The way they are implemented here In this particular incarnation they are also a bit large for my taste. I would be inclined to make them 2x2 on the outside, and 4x4 on the inside (embedded in an 8x8 board). And have the additional rule that it would not be allowed to move a Tardis when in check. An even more modest implementation would be a single square, and internally 2x2. This has the advantage that every square in it still borders the outside world, so that a King in there can still be easily checked.

Veteran Chess. Most pieces can or must irreversibly promote when they capture.[All Comments] [Add Comment or Rating]

💡📝H. G. Muller wrote on Sun, Mar 27, 2022 06:02 PM UTC:

I changed the rules as described in the article now such that PxP does not provide a promotion opportunity. I also considered smaller rule modifications, such as that this would only hold in the move immediately after PxP, or only on P x promoted P, but I decided the added complexity (having an e.p.-rights-like extra game state, or distinguishing two different kinds of Veterans) was not worth it. The new rule creates a difference from Maka Dai Dai Shogi when a Pawn captures an unprotected Pawn, where it can now not promote. Just the reverse of the old problem, where a Pawn that recaptured after PxP could promote in Veteran Chess, while such a recapture would never be possible in Maka Dai Dai Shogi in the first place. The new rules do not discourage attacking Pawn chains, however.

I also made a second rule change: the Lady is now also contageous, and pieces capturing it mandatorily promote to Queen. With a non-contageous Lady I felt it was too easy to avoid Queens appearing at all by early indirect trading of the Ladies. In addition it makes the Lady a more powerful attacking piece: when kept sufficiently protected it can now safely be exposed to attacks by even less valuable pieces, as the exchange would result in a Queen. So it can be used in the vanguard.

The Interactive Diagram now also implements these rule changes, and I made some improvements to the general diagram script that makes optional deferral also possible with custom-defined promotions. (The previous implementation would automatically defer on demotions, and mandatorily promote otherwise.)

Darza. Members-Only Lin Carter's "Darza" (Callistan Chess) from "Renegade of Callisto". (7x9, Cells: 63) [All Comments] [Add Comment or Rating]

Since this comment is for a page that has not been published yet, you must be signed in to read it.

Heavy Shako.

10x10 variant inspired by Yangsi, made by Eric Silverman and Jean-Louis Cazaux.[All Comments] [Add Comment or Rating]

H. G. Muller wrote on Fri, Mar 25, 2022 07:39 AM UTC in reply to A. M. DeWitt from 02:45 AM:

To avoid the somewhat ambiguous notion on what 'different' means, you could write (in the piece overview) that kings castle with the rooks by moving two squares in their direction.

New Grand Apothecary Chess Error.[Subject Thread] [Add Response]

H. G. Muller wrote on Tue, Mar 22, 2022 07:46 AM UTC in reply to Aurelian Florea from 07:20 AM:

That is a consequence of pseudo-legal highlighting. The issue of moving into / out of / through check is what makes the difference between fully legal and pseudo-legal moves.

H. G. Muller wrote on Fri, Mar 18, 2022 01:04 PM UTC in reply to Aurelian Florea from Thu Mar 17 07:25 PM:

I now fixed the Play-Test Applet's GAME-code generation such that it does use the correct way for specifying a move as imitation in the 'legdefs' table it generates.

One caveat: the trick the betza.txt include file uses for determining whether moves are legal during highlighting is not reliable when imitators are present. Because it determines the pinned pieces and attacked squares before the move. And the move will usually change what the imitator is immitating. So it is recommended to use highlighting of all pseudo-legal moves, by specifying

set pseudo 1;

at the end of the Pre-Game section.

H. G. Muller wrote on Thu, Mar 17, 2022 07:17 PM UTC in reply to Aurelian Florea from 06:15 PM:

The GAME code in the betza.txt include file updates a variable 'toimitate' in its HandleMove routine, so that it will contain the ID of the piece to imitate on the next move. You could use the trick with the dummy piece also here. Say that its ID would be X or x, you could add this code in the Post-Move 1 section after the call to Handle move:

set toimitate cond == #toimitate p x #toimitate;

And in the Post-Move 2 section the same, but with capital P and X. The == #toimitate p tests whether the next piece to imitate would be a pawn, and if so, changes it to x, but otherwise leaves it as it was.

H. G. Muller wrote on Sun, Mar 13, 2022 12:55 PM UTC in reply to Aurelian Florea from 07:53 AM:

Each line in the legdefs array represents the leg of a move, and contains either 5 or 4 numbers. The first leg always contains 5 numbers, the first number indicating how many legs the move has. A zero there indicates no more moves follow for that piece.

The other 4 numbers are range (1 = leaper), x-step y-step and 'mode'. The latter describes what must occupy the target square for the leg to be possible.

Ranges smaller than 1 are of course meaningless, and those are used to indicate special cases that cannot be described as a (repeated) step. Such as imitation. These 'invalid' rages are recognized, and will cause execution of dedicated GAME code to handle the particular case. E.g. -1 would be used for the variable range of Pawns moving up to the board half. A -3 would cause calling of a user-supplied GAME code subroutine for generating the move.

I guess there is currently a mismatch between how the Interactive Diagram handles imitation (indicating it by some bit in the 'mode') and how the betza.txt GAME-code include file handles it (through range = -2). It would have been the task of the Play-Test Applet to make that translation when you make it generate GAME code. I cannot recall changing any of these. But I must have, if you say it worked before. In any case I should fix the Play-Test Applet to emit the -2 as range when the mode specifies imitation.

Shogi. Play the Japanese form of Chess, in which captured pieces can be dropped back as your own. (Recognized!)[All Comments] [Add Comment or Rating]

H. G. Muller wrote on Sat, Mar 12, 2022 09:13 PM UTC in reply to Fergus Duniho from Fri Mar 11 03:59 AM:

It currently stops the actual move, but it still displays the Pawn drop as a legal move.

Shogi rules are different from Chess, in this respect. In Chess illegal moves can never occur in a game; FIDE rules prescribe that such move should be taken back, and replaced by a legal one. But in Shogi, you just lose. In practice this seems to happen quite often even between club players through dropping Pawns in files that already contain one. The Japanese consider this an important thing: the 81-Dojo server does not refuse illegal Pawn drops, because that would be considered computer help.

So I think it would be logical to add the illegal move that caused game termination to the game record. Otherwise you would never know why the game suddenly ended.

New Grand Apothecary Chess Error.[Subject Thread] [Add Response]

H. G. Muller wrote on Sat, Mar 12, 2022 09:05 PM UTC in reply to Aurelian Florea from 04:22 PM:

It seems the J/j piece is not defined as an imitator. In the Pre-Game code the legdefs array should be initialized for the Imitator as

1 -2  0  1   16777219 // joker(1826)
0
1 -2  0 -1   16777219 // joker(1832)
0

But instead of a -2 you now have a 1 there.

How was this Pre-Game code created? Did you paste an existing Interactive Diagram into the Play-Test Applet, or did you select the pieces one by one from the table?

Hopping Sliders[Subject Thread] [Add Response]

H. G. Muller wrote on Thu, Mar 3, 2022 07:55 AM UTC:

The Heavenly Tetrarch in Tenjiku Shogi has ski-slide moves, but combines them with igui on the skipped square. The Wyvern in the Daring Dragons army of CwDA has a sideway ski-slide. (This caused a lot of trouble when programming it in the KingSlayer engine.)

波斯象棋(Shatranj). 廣泛出現在波斯的遊戲，國際象棋的前身 (Chinese Language)[All Comments] [Add Comment or Rating]

H. G. Muller wrote on Sat, Feb 19, 2022 11:51 AM UTC in reply to Fergus Duniho from 03:34 AM:

Why do we have pages in Chinese anyway? Is it the idea to translate the entire website in Chinese? And why Chinese, and not, say, Spanish?

It seems bad to intermingle pages of different languages. Is there a separate index for those (because I don't see this page in the normal alphabetical index)?

菲舍爾任意制象棋(Fischer Random Chess). 费舍尔的随机国际象棋变体 (Chinese Language)[All Comments] [Add Comment or Rating]

H. G. Muller wrote on Fri, Feb 18, 2022 01:27 PM UTC:

Note there are two different kinds of Chinese: traditional (Taiwan, Hong Kong) and simplified (China). And that the Japanese use basically the same kanji script. All use different encodings, though (Big 5, GB 2312 or Shift-JIS). In Windows Big 5 = page 950, and BG2312 = page 936. Japanese = page 932.

Baseball Chess. Missing description (9x9, Cells: 81) [All Comments] [Add Comment or Rating]

H. G. Muller wrote on Tue, Feb 8, 2022 06:23 PM UTC:

You are arguing with a spam bot.

Play-test applet for chess variants. Applet you can play your own variant against.[All Comments] [Add Comment or Rating]

💡📝H. G. Muller wrote on Mon, Feb 7, 2022 10:06 PM UTC in reply to Daniel Zacharias from 07:00 PM:

I implemented the dau work-around for friendly hopping in the Diagram only after I wrote the betza.txt include file. And I don't think I ever got to adapting that likewise. But eventually I should do that. Like you say, it is pretty exotic, so it was not a priority. E.g. Shogi promotions seem a much more common feature.

💡📝H. G. Muller wrote on Mon, Feb 7, 2022 06:51 PM UTC in reply to Daniel Zacharias from 06:37 PM:

Is this for unloading the piece that is captured at the end of the move, or for a locust capture? I remember having tested the GAME code for Odin's Rune Chess, and the Valkyrie there did work properly. Unloading locust victimes might not have been implemented yet, though. I could of course have broken something while implementing other new features.

Home page of The Chess Variant Pages. Homepage of The Chess Variant Pages.[All Comments] [Add Comment or Rating]

H. G. Muller wrote on Mon, Feb 7, 2022 04:04 PM UTC:

Initially I did not implement it because the Play-Test Applet is not suitable for specifying a variant with Shogi promotion: the order of the piece definitions is critical in that case, while the Applet inherits the order from the table of available pieces, without any interface for re-ordering them. But now that Diagram specifications can be pasted back into the Applet, this has changed. I guess I should make the textbox in which the HTML for the Diagram appears when you press the button editable. Then users could re-order the piece definitions there, and paste it back. Or perhaps there should even be a button for reloading what is in that textbox.

H. G. Muller wrote on Mon, Feb 7, 2022 11:31 AM UTC in reply to Fergus Duniho from Sun Feb 6 10:23 PM:

It sounds like something in your code is producing an unwanted goto to the beginning of the program when the E piece is moved.

That is totally unexpected behavior, and makes it virtually impossile to figure out what the error is. Isn't it possible to do some syntax checking on the GAME code (e.g. when it gest submitted) to prevent such erratic behavior?

@Daniel: You redefined the Promote routine just to implement Shogi-style promotion? Perhaps the betza.txt include should already provide a standard way to do that. E.g. triggered by the presence of an associative array #shogiprom, which would provide the promoted type when indexed with the basic type, and then set #choice to an array containing that promoted type and the piece itself. This could still be intersected with the possible choices for each rank (e.g. to suppress deferral for Pawns on the last rank, or Shogi Knights on the last two ranks). But it could probably bypass intersection with the captured pieces plus supply, as promotion to captured pieces only seem to make no sense with Shogi promotions.

H. G. Muller wrote on Sun, Feb 6, 2022 10:01 PM UTC:

You are right, moving E appears to trigger the problem. Which is strange, because all pieces use the same code for generating their moves; it is just that the data stored for describing E and e is in a different section of the array with move descriptions. Functions E and e are supposed to tell where exactly. Perhaps something disastrous happens in GAME code when using functions called E or e?

The shorter game causes the same problem: I put print statements at the start of the Pre-Game and Post-Move sections to see when they are called, and a printr $space; at the end of the Pre-Game section. This shows the same behavior also for the short game: Game Courier attempts to play the game twice for deducing the current position, but when it plays it the second time the Pre-Game section doesn't seem to be executed properly, because it sticks with the position resulting from applying the moves the first time instead of producing the initial position. So that the the fist halfmove cannot be applied to it the second time, and aborts the loading with an error message (see below).

I think the key to this is still understanding why Game Courier goes through the movelist twice. I see no need for it to do that.




Please report any bugs or errors to H.G. Muller

pregame

Array
(
    [a12] => d
    [b12] => l
    [c12] => u
    [d12] => z
    [e12] => o
    [f12] => q
    [g12] => k
    [h12] => o
    [i12] => z
    [j12] => u
    [k12] => l
    [l12] => d
    [a11] => r
    [b11] => m
    [c11] => n
    [d11] => b
    [e11] => a
    [f11] => y
    [g11] => y
    [h11] => a
    [i11] => b
    [j11] => n
    [k11] => m
    [l11] => r
    [a10] => x
    [b10] => i
    [c10] => e
    [d10] => g
    [e10] => s
    [f10] => c
    [g10] => c
    [h10] => s
    [i10] => g
    [j10] => e
    [k10] => i
    [l10] => x
    [a9] => p
    [b9] => p
    [c9] => p
    [d9] => p
    [e9] => p
    [f9] => p
    [g9] => p
    [h9] => p
    [i9] => p
    [j9] => p
    [k9] => p
    [l9] => p
    [a8] => @
    [b8] => @
    [c8] => @
    [d8] => @
    [e8] => @
    [f8] => @
    [g8] => @
    [h8] => @
    [i8] => @
    [j8] => @
    [k8] => @
    [l8] => @
    [a7] => @
    [b7] => @
    [c7] => @
    [d7] => @
    [e7] => @
    [f7] => @
    [g7] => @
    [h7] => @
    [i7] => @
    [j7] => @
    [k7] => @
    [l7] => @
    [a6] => @
    [b6] => @
    [c6] => @
    [d6] => @
    [e6] => @
    [f6] => @
    [g6] => @
    [h6] => @
    [i6] => @
    [j6] => @
    [k6] => @
    [l6] => @
    [a5] => @
    [b5] => @
    [c5] => @
    [d5] => @
    [e5] => @
    [f5] => @
    [g5] => @
    [h5] => @
    [i5] => @
    [j5] => @
    [k5] => @
    [l5] => @
    [a4] => P
    [b4] => P
    [c4] => P
    [d4] => P
    [e4] => P
    [f4] => P
    [g4] => P
    [h4] => P
    [i4] => P
    [j4] => P
    [k4] => P
    [l4] => P
    [a3] => X
    [b3] => I
    [c3] => E
    [d3] => G
    [e3] => S
    [f3] => C
    [g3] => C
    [h3] => S
    [i3] => G
    [j3] => E
    [k3] => I
    [l3] => X
    [a2] => R
    [b2] => M
    [c2] => N
    [d2] => B
    [e2] => A
    [f2] => Y
    [g2] => Y
    [h2] => A
    [i2] => B
    [j2] => N
    [k2] => M
    [l2] => R
    [a1] => D
    [b1] => L
    [c1] => U
    [d1] => Z
    [e1] => O
    [f1] => Q
    [g1] => K
    [h1] => O
    [i1] => Z
    [j1] => U
    [k1] => L
    [l1] => D
)

postmove1

postmove2

postmove1

pregame

Array
(
    [a12] => d
    [b12] => l
    [c12] => u
    [d12] => z
    [e12] => o
    [f12] => q
    [g12] => k
    [h12] => o
    [i12] => z
    [j12] => u
    [k12] => l
    [l12] => d
    [a11] => r
    [b11] => m
    [c11] => n
    [d11] => b
    [e11] => a
    [f11] => y
    [g11] => y
    [h11] => a
    [i11] => b
    [j11] => n
    [k11] => m
    [l11] => r
    [a10] => x
    [b10] => i
    [c10] => e
    [d10] => g
    [e10] => s
    [f10] => c
    [g10] => c
    [h10] => s
    [i10] => g
    [j10] => e
    [k10] => i
    [l10] => x
    [a9] => p
    [b9] => p
    [c9] => p
    [d9] => @
    [e9] => p
    [f9] => p
    [g9] => p
    [h9] => p
    [i9] => p
    [j9] => p
    [k9] => p
    [l9] => p
    [a8] => @
    [b8] => @
    [c8] => @
    [d8] => p
    [e8] => @
    [f8] => @
    [g8] => @
    [h8] => @
    [i8] => @
    [j8] => @
    [k8] => @
    [l8] => @
    [a7] => @
    [b7] => @
    [c7] => @
    [d7] => @
    [e7] => @
    [f7] => @
    [g7] => @
    [h7] => @
    [i7] => @
    [j7] => @
    [k7] => @
    [l7] => @
    [a6] => @
    [b6] => @
    [c6] => @
    [d6] => @
    [e6] => @
    [f6] => @
    [g6] => @
    [h6] => @
    [i6] => @
    [j6] => @
    [k6] => @
    [l6] => @
    [a5] => @
    [b5] => @
    [c5] => @
    [d5] => @
    [e5] => @
    [f5] => @
    [g5] => @
    [h5] => @
    [i5] => P
    [j5] => @
    [k5] => @
    [l5] => @
    [a4] => P
    [b4] => P
    [c4] => P
    [d4] => P
    [e4] => P
    [f4] => P
    [g4] => P
    [h4] => P
    [i4] => E
    [j4] => P
    [k4] => P
    [l4] => P
    [a3] => X
    [b3] => I
    [c3] => E
    [d3] => G
    [e3] => S
    [f3] => C
    [g3] => C
    [h3] => S
    [i3] => G
    [j3] => E
    [k3] => I
    [l3] => X
    [a2] => R
    [b2] => M
    [c2] => N
    [d2] => B
    [e2] => A
    [f2] => Y
    [g2] => Y
    [h2] => A
    [i2] => B
    [j2] => N
    [k2] => M
    [l2] => R
    [a1] => D
    [b1] => L
    [c1] => U
    [d1] => Z
    [e1] => O
    [f1] => Q
    [g1] => K
    [h1] => O
    [i1] => Z
    [j1] => U
    [k1] => L
    [l1] => D
)

postmove1

ILLEGAL: P i4-i5 on turn 1:

There was no P on i4. The piece on i4 is a E.

Go back with your browser's BACK button, reload the page, and try again.

For diagnostic purposes, here is the full movelist:

1. P i4-i5 
1... p d9-d8 
2. E j3-i4

H. G. Muller wrote on Sun, Feb 6, 2022 09:12 PM UTC:

I tried to debug it some time ago, and the error message was provoked by the first halfmove of the game being applied to the position resembling the one that occurs after all moves have already been applied once. So the question is: why would Game Courier try to apply the set of moves twice? And, as I said, it also appears to execute the Pre-Game code twice. (But not fully, otherwise the first loading of the game would be fully erased, and undetectable.) I had the impression it was due to the previous move being a check, but this could be a coincidence.

H. G. Muller wrote on Sun, Feb 6, 2022 06:12 PM UTC in reply to Fergus Duniho from 05:30 PM:

The array shufflespecs needs an extra 0 at the end (in addition to the triples describing the individual shuffle steps) to symmetrize the position, and the preset's Pre-Game code doesn't seem to have that. If this is code generated through the Play-Test Applet it could be that it got confused about the symmetry of the diagram. When symmetry=none it would shuffle white and black independently.

@Fergus: please also have a look at the problem reported here. I really think there must be something wrong other than the GAME-code, because when I put a printr $spaces; at the end of the Pre-Game section it prints the array twice. I don't think that should ever be possible, no matter how buggy the GAME code might be, if the underlying software functions properly.

Chak. A modern vision of what a Mayan chess would look like.[All Comments] [Add Comment or Rating]

H. G. Muller wrote on Thu, Jan 20, 2022 08:28 AM UTC in reply to Daniel Lee from Wed Jan 19 10:10 PM:

Nice! One thing I notice is that the script asks if you want to promote -- it's mandatory and not a choice.

Good point. I used the regular Shogi-style promotion supported by the Diagram, which always offers the choice. It is possible to implement mandatory promotion by supplying an additional JavaScript routine WeirdPromotion() on the page, which is a bit of a hassle. Perhaps I should support an alternative method for declaring promotion mandatory, e.g. through the already existing promoChoice parameter to the Diagram. With Shogi-style promotions this is currently not used. It would be logical to let the setting + mean mandatory promotion, and += that there is a choice. Unfortunately this is not backward compatible with Diagrams of games with Shogi-style promotion I (and others) made in the past, which often specify promoChoice as just +, or not at all. I will give it some thought how best to make this a standard feature of the Diagram.

[Edit] OK. I fixed it by using a newly added feature of the Diagram (so only active after refresh of the browser cache): if the promoChoice string contains !L in some variant with Shogi-style promotion (i.e. promoOffset non-zero), the piece with ID L will not be allowed to defer, and will promote automatically on reaching the zone. This was inspired on the same notation being used with Chess-style promotions for indicated that the choice is not allowed on last rank. (Which is commonly used to force promotion of a Pawn there when promotion on other ranks is optional.)

Ideas for future of chess variants[Subject Thread] [Add Response]

H. G. Muller wrote on Tue, Jan 18, 2022 05:23 PM UTC in reply to Kevin Pacey from 03:27 PM:

RF is Dragon King. Dragon Horse is BW.

A Wizard for GAME-Code Generation. A tutorial on using the Play-Test Applet for automating Game Courier presets.[All Comments] [Add Comment or Rating]

💡📝H. G. Muller wrote on Tue, Jan 18, 2022 12:59 PM UTC in reply to Aurelian Florea from 09:56 AM:

That would be too bad. But I don't think anyone but Fergus can fix bugs in Game Courier or the GAME code interpreter.

💡📝H. G. Muller wrote on Sat, Jan 15, 2022 01:30 PM UTC:

This error is weird: the error message obviously comes from the GAME code used to automate the preset, from the move parser. But it seems thise is called in an unexpected context: Game Courier tries to feed the game history to the code in the Post-Move sections twice. And the second time the position has already been changed from the initial one to some weird one, which indeed has a Z on g4.

For debugging I added a statement

printr $space

at the end of the Pre-Game section. When I then use the preset in Play mode, and play the given game, the page that complains about the error contains two dumps of the $space array. The first is the initial position (as expected), but the second is

Array
(
    [a12] => d
    [b12] => l
    [c12] => u
    [d12] => z
    [e12] => o
    [f12] => q
    [g12] => k
    [h12] => o
    [i12] => z
    [j12] => u
    [k12] => l
    [l12] => d
    [a11] => r
    [b11] => m
    [c11] => n
    [d11] => b
    [e11] => a
    [f11] => y
    [g11] => y
    [h11] => a
    [i11] => b
    [j11] => n
    [k11] => m
    [l11] => r
    [a10] => x
    [b10] => i
    [c10] => e
    [d10] => g
    [e10] => s
    [f10] => c
    [g10] => c
    [h10] => s
    [i10] => g
    [j10] => e
    [k10] => i
    [l10] => x
    [a9] => p
    [b9] => p
    [c9] => p
    [d9] => p
    [e9] => p
    [f9] => p
    [g9] => @
    [h9] => p
    [i9] => p
    [j9] => p
    [k9] => p
    [l9] => p
    [a8] => @
    [b8] => @
    [c8] => @
    [d8] => @
    [e8] => @
    [f8] => @
    [g8] => @
    [h8] => @
    [i8] => @
    [j8] => @
    [k8] => @
    [l8] => @
    [a7] => @
    [b7] => @
    [c7] => @
    [d7] => @
    [e7] => @
    [f7] => @
    [g7] => p
    [h7] => @
    [i7] => @
    [j7] => @
    [k7] => @
    [l7] => @
    [a6] => @
    [b6] => @
    [c6] => P
    [d6] => @
    [e6] => @
    [f6] => @
    [g6] => P
    [h6] => @
    [i6] => @
    [j6] => @
    [k6] => @
    [l6] => @
    [a5] => @
    [b5] => @
    [c5] => @
    [d5] => @
    [e5] => A
    [f5] => P
    [g5] => @
    [h5] => @
    [i5] => @
    [j5] => @
    [k5] => @
    [l5] => @
    [a4] => P
    [b4] => P
    [c4] => @
    [d4] => P
    [e4] => P
    [f4] => @
    [g4] => Z
    [h4] => P
    [i4] => P
    [j4] => P
    [k4] => P
    [l4] => P
    [a3] => X
    [b3] => I
    [c3] => E
    [d3] => G
    [e3] => S
    [f3] => C
    [g3] => C
    [h3] => S
    [i3] => G
    [j3] => E
    [k3] => I
    [l3] => X
    [a2] => R
    [b2] => M
    [c2] => N
    [d2] => @
    [e2] => A
    [f2] => Y
    [g2] => Y
    [h2] => A
    [i2] => B
    [j2] => N
    [k2] => M
    [l2] => R
    [a1] => D
    [b1] => L
    [c1] => U
    [d1] => Z
    [e1] => O
    [f1] => Q
    [g1] => K
    [h1] => O
    [i1] => @
    [j1] => U
    [k1] => L
    [l1] => D
)

This is neither the initial nor the current position, although it does have some characteristics of the current position.

Perhaps Fergus can shed some light on how the Pre-Game section could be executed twice when entering a single move in Play mode.

Tamerlane II. Modern variant based upon ancient large chess variant. (11x11, Cells: 121) [All Comments] [Add Comment or Rating]

H. G. Muller wrote on Tue, Jan 11, 2022 05:07 PM UTC in reply to Jean-Louis Cazaux from 04:12 PM:

OK, I see. But the Diagram is intended as a means for practicing the variant that people have just read the rules of in the article, so I think it would be bad to surprise them with other rules. If you manage to correct the article, I will adapt the Diagram accordingly. Of course it would be better if you included the Diagram in the main page of the article; then it will not be pushed into oblivion by later discussions like this one. And then you can correct the Prince move yourself.

H. G. Muller wrote on Tue, Jan 11, 2022 01:52 PM UTC in reply to Jean-Louis Cazaux from Sat Jan 8 06:47 PM:

I was looking to this Interactive Diagram (thanks HG). The Prince's move is not correct. It is not K. It should be KimfnD.

The description in the page says K, so that is what I use in the Diagram.

Play-test applet for chess variants. Applet you can play your own variant against.[All Comments] [Add Comment or Rating]

💡📝H. G. Muller wrote on Sun, Jan 2, 2022 07:58 PM UTC in reply to Jean-Louis Cazaux from 06:20 PM:

It is easy enough to get value estimates for pieces with moves that are not in the table, since you can alter the moves that are in the table by default. Just type the Betza notation for the move you want in the text entry below the table, and then click the cell with the move of some piece that is in the table to give it that move.

There is just one caveat: you have to assign all the moves before you ever ask for the values by clicking the header of the move column, (or use the Diagram to play against), because it only calculates the values once, and is not aware that a move has changed. (Because in the normal function of the Diagram this cannot happen; Arguably this is a bug and I should make the code that assigns the new move, which is specific to the Play-Test Applet page, also recalculate the piece values.)

Interactive diagrams. Diagrams that interactively show piece moves.[All Comments] [Add Comment or Rating]

💡📝H. G. Muller wrote on Wed, Dec 29, 2021 10:00 PM UTC in reply to Aurelian Florea from 08:43 AM:

Well, actually it doesn't, because I messed up. One should not test pieceType (which will always be 14 at this point), but imi, to decide which moves to forbid. In addition, I tested for a full square, rather than an empty. The following routine should work: it first declares OK all non-imitator moves, all imitations of non-pawns, and all moves to occupied squares. At that point only non-capture pawn imitations are left, and advances of more than 1 rank can be flagged as illegal. finally it tests for e.p. depending on which pawn type is imitated.

    function BadZone(toFile, toRank, pieceType, color, fromFile, fromRank) {
      if(pieceType != 14) return 0;
      if((imi & 511) > 2) return 0;
      if(board[toRank][toFile] & 511) return 0;
      if(fromRank > toRank + 1 || fromRank < toRank - 1) return 1; 
      if(imi == 1) return (toFile != fromFile);
      return (toFile == fromFile);
    }

💡📝H. G. Muller wrote on Tue, Dec 28, 2021 10:34 PM UTC in reply to Aurelian Florea from 09:08 PM:

No, ther can be only one function BadZone, which must detect all moves you want to forbid, and return true (non-zero) for those (and false or 0 for the others). So you have to put this in BadZone just before the final return statement (which would otherwise return 'false', because in e.p. capture you only advance one rank)

💡📝H. G. Muller wrote on Tue, Dec 28, 2021 05:55 PM UTC in reply to Aurelian Florea from 03:59 PM:

Promotion is done based on the piece type, so if the Joker is not amongst the promotable pieces, it will not promote. Only moves are immitated.

Because you have two different kinds of Pawns the test for it becomes complicated. In any case the destination square must be empty. But then for normal Pawns diagonal moves must be excluded, and for Berolinas the straight moves. So omething like

if(board[toRank][toFile] & 511) {
  if(pieceType == 1) return (toFile != fromFile);
  if(pieceType == 2) return (toFile == fromFile);
}

💡📝H. G. Muller wrote on Tue, Dec 28, 2021 02:23 PM UTC in reply to Aurelian Florea from 01:26 PM:

OK, the problem obviously is that 'imi' is not defined. I am pretty sure I uploaded the version that updates 'imi' also on user moves yesterday, but it turns out the old version was still on the CVP website. So somehow th upload must have failed. I now uploaded it again, and this fixes the problem. You can remove the document... line from the BadZone function now.

💡📝H. G. Muller wrote on Tue, Dec 28, 2021 01:05 PM UTC in reply to Aurelian Florea from 12:52 PM:

OK, so the routine is in fact called. Try the following. Below the script add a place where we can print debug output:

Then inside the BadZone routine add a line

document.getElementById("debug").innerHTML += 'BadZone(' + toFile + ',' + toRank + ',' + pieceType + ',' + color + ',' + fromFile + ',' + toFile + ') imi =' + imi + '<br>';

Then we can get an impression of what goes wrong.

💡📝H. G. Muller wrote on Tue, Dec 28, 2021 12:34 PM UTC in reply to Aurelian Florea from 09:58 AM:

I can confirm that the BadZone function has no effect in the page at the link you gave. The weird thing is that when I ask the page source of that page, copy the Diagram in it to a local HTML page on my own computer, and open it in the browser, the distant moves do get suppressed. I have no idea why it doesn't work on your page. If I look in the browser console I do not get any error messages from the JavaScript on your page.

The problem is that I cannot experiment on your page; only you have access to it. This is why I copied to my own computer, but the copy shows no errors, so there is nothing to debug. Perhaps you can try the following: add as a first line in the BadZone routine the line

return 1;

This should suppress every move of every piece, and even prevent the highlighting of the piece itself. If that has no effect, I am pretty sure that the routine BadZone never gets called.

💡📝H. G. Muller wrote on Tue, Dec 28, 2021 09:06 AM UTC in reply to Aurelian Florea from 07:02 AM:

OK, I found the problem. It turns out that the variable 'imi' was copied directly from the board, where it also contains color and highlighting information, besides the piece type. So these bits have to be stripped first by taking (imi & 511) to be left with the type. I suppose I should change the Diagram script to already do this by itself when storing imi, rather than when using it. For now you can fix it by using

  <script>
    function BadZone(toFile, toRank, pieceType, color, fromFile, fromRank) {
      if(pieceType != 14) return 0;
      if((imi & 511) > 2) return 0;
      return (fromRank > toRank + 1 || fromRank < toRank - 1);
    }
  </script>

This also fixes the problem that the highlighting function is also called to highlight the selected piece itself (so that fromRank equals toRank), and we don't want to suppress that. So I changed the test for suppressing only moves of more than 1 rank.

Note that it still wouldbe able to e.p. capture when imitating a pawn.

💡📝H. G. Muller wrote on Mon, Dec 27, 2021 10:22 PM UTC in reply to Aurelian Florea from 06:25 PM:

Well, that looks OK. If you would post a link to the page where you have it, I could have a look at it, and maybe we could have some progress...

💡📝H. G. Muller wrote on Mon, Dec 27, 2021 06:00 PM UTC in reply to Aurelian Florea from 03:40 PM:

No, it does not. It is not in the table. (In fact the Diagram uses piece type = 250 for holes internally.) The Diagram should be put on the HTML page that contains the Diagram. It should not matter where. There is no way to relate the script to a specific Diagram, however. So if there are more than a single Diagram on the same page, they will all use the BadZone function defined in the script.

💡📝H. G. Muller wrote on Mon, Dec 27, 2021 01:45 PM UTC in reply to Aurelian Florea from 04:17 AM:

Well, the idea was not to change any piece types, but detect whether the generated move was for an imitator imitating a pawn, and in that case forbid the move (by returning a non-zero value) when it advanced more than one rank. This was not so easy, though, because BadZone did not get the coordinates of the origin square passed to it, and it was not obvious what the imitator was imitating.

I did change the Diagram script now to make this easier: the variable 'imi' now contains the imitated piece at all times during the game, not just when the AI is thinking. And the square of origin are passed as extra parameters to BadZone. (Refresh the browser cache!) This should make the following script so what you want:

<script>
function BadZone(toFile, toRank, pieceType, color, fromFile, fromRank) {
  if(pieceType != NUMBER_OF_JOKER) return 0;
  if(imi != NUMBER_OF_PAWN) return 0;
  return (fromRank != (color ? toRank + 1 : toRank - 1));
}
</script>

(Replace the NUMBER_OF_... by the actual numbers your pieces have in your table.)

💡📝H. G. Muller wrote on Sun, Dec 26, 2021 09:39 PM UTC in reply to Aurelian Florea from 06:19 PM:

The Diagram does not support 'partial imitators', which can only imitate a subset of the pieces, or of the moves of some of the pieces. I suppose it would be possible to exploit the possibility to veto unwanted moves through a user-supplied JavaScript function BadZone. Originally this feature was created for confining pieces to part of the board as in Xiangqi. It could be used to veto moves for any reason, though. Problem in this case is that the routine should know which piece the imitator is imitating, because you don't want to veto distant forward moves when it is imitating a Rook. The Diagram keeps track of that in a variable that is accessible from the routine. But it is a different variable in case of a move in the game from when the AI is thinking.

Play-test applet for chess variants. Applet you can play your own variant against.[All Comments] [Add Comment or Rating]

💡📝H. G. Muller wrote on Mon, Dec 20, 2021 05:07 PM UTC in reply to Jean-Louis Cazaux from 02:00 PM:

I wonder if increasing the number of 10 positions would decrease the results' span.

Sure, in the limit of an infinite number of positions this should converge to a fixed value. I suppose this limit could even be calculated from the probabilities that squares will be occupied (and by what) according to the rules used by the model to generate the positions. It was just less work to have the program estimate it.

The variation between attempts is not larger than the accuracy of the method anyway. (And a bit of randomization helps to avoid deterministic play.) Different distributions of black vs white pieces might result in a different limit: the more your pieces gravitate to your own side of the board, the larger will be the reward for 'forwardness'. Perhaps the move counts should have been weighted to take account of the probability the piece will be there (which would be smaller in the enemy camp). Using a different filling fraction would affect the relative values of leapers, sliders and hoppers. (Strong chess programs do use separate sets of piece values in end-game and opening phase. The Diagram's AI is not that advanced, which probably means it handles hoppers stupidly. But if I would ever imrove that I would probably have it determine the values with a 50% and 10% filling fraction, respectively.)

There are also many 'global' aspects of the move patterns that are not taken into account. It seems that there should be some bonus for attacking orthogonally adjacent squares ('concentration'), which is the most likely explanation for the unexpectedly high value of the Archbishop. There probably should be a penalty for color binding, especially for severe forms of color binding. As it is, the algortithm would value an Alibaba about equal to a Knight, because it is not aware it can only access 1/4 of the board. Having only step moves (i.e. Shogi generals) should probably be penalized.

💡📝H. G. Muller wrote on Mon, Dec 20, 2021 07:56 AM UTC in reply to Jean-Louis Cazaux from Sat Dec 18 06:28 PM:

I did not describe that anywhere yet. But it involves some randomization: it starts by generating some 10 random positions with a filling fraction of 25%, where the pieces of a given color are 3 times more likely to be at their own back rank than on the far rank. Then it counts the number of moves the piece under test would have on every empty square in these positions, distinguishing captures from non-captures. It translates that to the number of reachable and attacked squares on an empty board using the filling fraction. (E.g. if it would on average have 1.5 captures while the board is 12.5% populated with enemy pieces, it counts 1.5/0.125=12 attacked squares. If I would count attacked squares on an empty board directly, sliders would get too many moves, and hoppers would not have any.) It does not only calculate the average number of moves of the piece this way, but also the standard deviation, and adds the latter to the average. (This to compensate for the effect that during play you put pieces on squares where they are active, and avoid bad squares.) From the thus calculated mobilities N I derive a piece value with the formula (33+0.7*N)*N (centi-Pawn), which takes account of average cooperativity between moves, where captures are weighted as 1.33 move, and non-captures as 0.67. (And locust captures have some extra weight.)

It is still far from perfect, but good enough for the level at which the AI of the diagram is intended to play.

Betza notation (extended). The powerful XBetza extension to Betza's funny notation.[All Comments] [Add Comment or Rating]

💡📝H. G. Muller wrote on Thu, Dec 16, 2021 10:13 PM UTC in reply to Daniel Zacharias from Wed Dec 15 07:52 PM:

[Q-odfQ-ubK]cQ seems to work too

Indeed; the u after an o leg apparently is ignored. I guess this is because you always have to end on an empty square with this move, so there is nothing to unload. (With a bit of bad luck it would have created a hole at the square of origin :-) ) Q-f..Q is not recommended, though:it creates a lot of different paths to a distant destination, as every square that is traveled to would be (successfully) tried as an intermediate. So it slows down the AI. With Q-f..K you don't have that: the intermediate square must be the last before the obstacle, or the K step could not hit the latter.

💡📝H. G. Muller wrote on Wed, Dec 15, 2021 08:54 AM UTC in reply to Daniel Zacharias from 01:41 AM:

I tried (dauf)Q, thinking that would describe a queen that could pass through friendly pieces, but if it captures after unloading the captured piece ends up at the starting square of the whole move. Is that intended?

No, this was a bug. I fixed that now.

Doesn't the withdrawer in Ultima move as a queen, so wouldn't need to detect the board edge?

The problem is that when you put a plain mQ move in the Withdrawer, it can also make this move away from an enemy piece without capturing it. To make the capture mandatory you have to detour the path over the potential victim, either passing through an empty square or hopping over a friendly piece, but capturing as the only way to pass over an enemy. But if you do that (e.g. [mcK-bK-fmQ][dK-buK-fmQ]) the Withdrawer can no longer move away from a board edge. So you would need an extra [E-mQ] move (or change mc to mco for the sensing step).

The same problem exists for the 'maximum range slider': you want to sense if the next square in its path is occupied by a friend, but you should also be able to approach an edge. So [Q-fdK-buK][Q-foK-bK]cQ would do it. (The simpler [dQ-buK][oQ-bK]cQ would allow null move when standing against a friend or edge.)

💡📝H. G. Muller wrote on Tue, Dec 14, 2021 10:43 AM UTC:

The o modifier for straying off-board is a very powerful tool, but unfortunately not very intuitive. From the examples I discussed in the previous comment it appears that it almost exclusively occurs in back-and-forth move, for testing if we are on an edge square. This is somewhat clumsy idiom, and last night it occurred to me it could be useful to create a new atom to perform this task in a more intuitive way: E could mean a null move that can only be made on an edge square. The Edgehog would then be [E-Q][mcQ-E], which I would consider a rather intuitive description. Because a null move has no intrinsic direction, we can stipulate that for the leg following it the forward direction is determined by the leg preceding it. (Or, in other words, 'forward' is continuing to move in the same direction as the latest leg that really moved.) So [B?E-sB] would be a reflecting Bishop. When the E is in the initial leg, the forward direction for the following leg could be defined as perpendicular away from the edge. So [E-fR] would mean a Rook move away from the edge. I guess we could allow directional modifiers on the E for indicating in which absolute direction it has to test for an edge: [B?sE-sB] would only be able to reflect from the left and right edges.

The other idiomatic construct in which o appeared was useful for 'burning' a single piece as the side effect of a move, i.e. a locust capture that must be made when it is possible, but would not preclude the move from being made when it is not possible (because there is no enemy on the indicated square, or the square would fall off board). This also involves a back-and-forth step, which needs the 'most-general non-overlapping' mode omc + friendly hop, which covers all possible states of the target square, and specifies its clearing only when it is an enemy. This problem was compounded by the fact that we have no modifier for friendly hopping, and that this needs the ckludge of friendly-capture + immediate unload. Where the need for the unload then makes in uncombinable with the c, so that you end up with a horrible [..omcK-bK...][...dK-buK...] construction. It would be nice to have some shorthand for this: burn the target if you can, but never mind if you cannot. One idea that came to mind is to use cc for this. So ccK would burn (without moving) an adjacent enemy in the direction of choice (which could be limited by directional modifiers) if one was there, but also continue if there wasn't. The Advancer would then simply be [Q-fccK]. The Withdrawer would be [ccK-bmQ], the b indicating that the Q move should go in the opposit direction from the burn square (and an m needed to suppress normal capture the final leg would have by default). Of course we could have a similar dd for friendly burning.

If no single direction is specified on the cc leg, any single one of the allowed directions can be chosen (as is usual in Betza notation). So the Forest Ox of Odin's Rune Chess could be written as [N?ccK]: move as Knight, and then optionally burn one enemy of choice adjacent to the destination square. If you would want to burn more victims, you would have to repeat the atom. E.g. [R-flccF-rccF] would burn two victims diagonally forward from the destination. It is a bit awkward here that the second burn needs r rather than fr, because it is referenced to the previous burn rather than the Rook move. (But ccK must (re)define a 'last direction', or otherwise the Withdrawer could not work.)

Does any of this make sense?

Reservists' doublechess. Each side has 16 non-pawn pieces, split among 10 types.[All Comments] [Add Comment or Rating]

H. G. Muller wrote on Tue, Dec 14, 2021 09:36 AM UTC in reply to Ben Reiniger from Mon Dec 13 05:34 PM:

I suspect 'cannot be placed in check' was intended to mean 'is not subject to any checking rule'. Why else call it a Commoner?

I would avoid calling the Nightrider a major pieces, as this term usually indicates pieces with mating potential. I suggest to use the term 'heavy piece' instead.

The full-file rule strikes me as odd: it tries to 'solve' the problem that on a full file there would be no room for a new Pawn, so that you could not capture a heavy piece in it, by merely making that same problem occurring earlier, when the file still has one empty square. It still seems to be a never-happens situation, but if this rule is just added for completeness, it would seem best to make it such that it only has to be invoked at the latest possible stage, i.e. that you cannot capture a heavy piece on a completely filled file. If the idea is that this gives the game an interesting twist, and should actually occur in games, it should already kick in on more sparsely filled files. E.g. half full, or when there is no empty square on your own half of the board.

Anarchian Chess 2. Members-Only Chess variant with pieces suggested by r/AnarchyChess.[All Comments] [Add Comment or Rating]

Since this comment is for a page that has not been published yet, you must be signed in to read it.

Betza notation (extended). The powerful XBetza extension to Betza's funny notation.[All Comments] [Add Comment or Rating]

💡📝H. G. Muller wrote on Mon, Dec 13, 2021 01:22 PM UTC:

I have implemented a new meaning of the o modifier on non-final legs. On a final or only leg the legacy meaning of 'cylindrical piece' remains valid. On non-final legs it means the move is allowed to step off board. This is treated similarly to hopping, where you step on an occupied square, and will terminate the current leg to continue with the next.

Why would this ever be useful? Well, it turns out there are several applications. One is the Reflecting Bishop, which bounces from the board edge. To 'sense' the edge you can optionally extend the Bishop move with a Ferz step in the same direction. And if that lands off board, you can retrace that with another Ferz step, and then continue as a Bishop at right angles. So [B?foF-bF-sB]. The ? indicates this 'hook move' extension of the trajectory is optional, and that you can terminate after a normal B move as well.

Another example is the Edgehog: this moves as a Queen, but only from or to an edge square. To describe these moves you need to sense for the edge at the start or the end of the move, respectively. When a back-and-forth King step can hit an off-board square you are on the edge, and can continue with the real move in the next (and in this case final) leg: [oK-bK-Q]. Or for moving to an edge [mcQ-oK-bK]. (There has to be an explicit c on the Q move there, as otherwise the latter would not be able to capture, being a non-final leg.) This works, but is a bit inefficient for the AI, which is still too stupid to recognize that moves that go through a different path to the same square are really the same move. So it would search each Edgehog move 3 times, reaching the destination through the three different off-board square the oK step can reach. This would needlessly drive up its thinking time. This can be cured by probing more selectively (directionwise) for the edge: [vvssoK-bK-Q][mcQ-foK-bK]. This limits initial probing to orthogonal directions, (which, except for the corner case, hits only a single off-board square), and probing on the target square to the forward direction.

Off-board detours also make it possible to describe the Ultima Withdrawer and Advancer. These are given an extra back-and-forth step at the start or the end of their trajectory, respectively. With this step they must either capture an enemy, hop over a friend, move through an empty square, or stray off board. Without the latter, it would not be possible to describe moves that dissociate them from the edge. There is one problem: we cannot use the p for describing the hopping, because that would also allow hopping over an enemy piece, and thus make the capture of it optional. While the capture must be a mandatory side effect of the move. Fortunately we can use the 'friendly capture + unload' trick to describe friendly hopping. But this forces us to describe it as a separate move from the real capture, as the latter should not be unloaded. So we get [omcK-bK-fmQ][dK-buK-fmQ] for the Withdrawer, the first move describing moving away from the edge, and empty square or an enemy (and capturing the latter), the second moving away from a friendly piece.

Similarly, the Advancer will be [Q-fomcK-bK][Q-fdK-buK]. These descriptions are not very intuitive; it would probably be preferable to have some method to describe the captures here as Fire-Demon style 'burning', but in a specific direction, rather than through all K steps. This still has to be designed, though.

💡📝H. G. Muller wrote on Sun, Dec 12, 2021 07:31 PM UTC in reply to Daniel Zacharias from 06:09 PM:

OK, I now made it such that dau and cau are treated as hop onto friend/foe-only, and are treated just as pa. That means you can still have another locust capture or unload square on the same move, and the unload would then refer to the piece captured in the destination.

I am afraid that what you want still would not work, because the slider could also hit the board edge, and there doesn't exist any method yet to 'sense' that. I once considered to allow o in non-final legs to allow the leg to go off board (or onto a 'hole'), but it conflicts with the use it has now for indicating cylindrical pieces. Of course a new modifier could be introduced for this.

Problem is that at best its use would lead to contrived solutions. If new symbols have to be introduced, it might be better to introduce something that directly does what you want: force a slider to its maximum range. Like we already have W* for moving up to half the board. E.g. R$ (or perhaps W$ ?) could mean 'only the farthest accessible empty square. You could then write Q$cQ.

New Grand Apothecary Chess Error.[Subject Thread] [Add Response]

H. G. Muller wrote on Sun, Dec 12, 2021 06:26 PM UTC in reply to Aurelian Florea from 01:06 PM:

Well, I fixed the previous problem we had as Fergus suggested, by retrieving the shuffle made when the game was created from the constant 'startshuffle', like:

  if isconst startshuffle:        // shuffle has already been determined
    setsystem space @startshuffle;// retrieve it
  else:                           // new game; must shuffle
    ... // perform shuffling on $space
    setconst startshuffle $space;        // save the shuffle for persistent use
  endif;

That is, Fergus told me to write an @ before it, otherwise a wrong, uninitialized variable was retrieved, which led to a board of all white pawns. This seemed to work at the time. If you get a new shuffle now, it can only be because the test "isconst startshuffle" returns false, and it starts making a new shuffle rather than retreiving the old one (which apparently for some reason ceased to exist). If you shuffle again you are unlikely to get the same position. Perhaps Fergus knows how a constant can disappear.

Grand Chess. Christian Freeling's popular large chess variant on 10 by 10 board. Rules and links. (10x10, Cells: 100) (Recognized!)[All Comments] [Add Comment or Rating]

H. G. Muller wrote on Sun, Dec 12, 2021 10:41 AM UTC:

I am not sure what exactly you are referring to. I never measured piece values explicitly for Grand Chess; I always assumed they would be equal to those of Capablanca Chess, as extra ranks behind the armies should not have much effect on game play. For Capablanca Chess the values are Q=950, C=900, A=875, R=500, B=350, B-pair bonus=50, N=300, P=100. There is a rather strong manifestation of the 'leveling effect', though: the super-pieces are effectively worth less when they face many lighter pieces. So sacrifycing one super-piece for R + minor or 3 minors ups the effective value of your remaining super-pieces compared to those of the opponent, which can give more than a Pawn in compensation (if you still have these super-pieces).

Betza notation (extended). The powerful XBetza extension to Betza's funny notation.[All Comments] [Add Comment or Rating]

💡📝H. G. Muller wrote on Sun, Dec 12, 2021 10:28 AM UTC in reply to Daniel Zacharias from 07:28 AM:

I'm confused about u. I'm trying the move dyaubQ but when I try it out the replaced piece never ends up where I expected it too, on it's original square.

The problem you are running into here is that locust capture of a friendly piece is used by the Diagram for encoding castlings. (As a locust capture by the king of its own rook. That allows indicating both the castling partner and the King destination.) So when the GUI performs the move that you entered, it tries to castle with the captured piece, and would relocate it even when there would not have been a u.) The u modifier is officially defined only for unloading the piece that was captured at the end of the move. (This to side-step the issue what we should unload when multiple pieces are captured.)

I am not sure what you are trying to achieve here. If u would have been defined as unloading the last (or only) victim that was captured during the move, the described move would unload the victim at the square it was captured (and then steps back one square). Are you trying to use this as a method for hopping over (or in this case bouncing back from) friendly pieces only? I guess it would be nice if (say) dyaufQ could be used to describe a Grasshopper that can only hop over friendly pieces, and cyaufQ for only hopping over enemies. I suppose the definition of u could be adapted to always unload the last piece that was captured before it, and if none was captured, the first piece captured after it. (And then exclude that piece from relocation by any following u.) That way you could always slip in as many cau and dau combinations you want, as alternative to pa. I could of course limit the interpretation of friendly locust capture as castling by the GUI to pieces that acually have castling defined as one of their moves.

It seems something else is wrong too, as I have to enter the first leg twice as locust square, before the final destination gets highlighted. This could be a consequence of that unload squares must also be clicked (e.g. the Valkyrie from Odin's Rune Chess allows relocation of the captured piece anywhere along the path of the move, and you will have to indicate where. So with afudQ it first lets you select the (empty) unload square, and then the (friendly) victim at the final destination. So I guess it first prompts you for the locust victim, and then for the unload square. Which is a bit silly when these must be the same according to the move description. I can streamline this, but with end-point victims only this situation was not supposed to occur.

[Edit] I did reserve the castling interpretation of friendly locust capture now for pieces that can castle. This means you can at least now define such moves on other pieces. But of course such captures are not likely to occur in a variant as such, as the players would avoid those like the plague. That becomes different when the piece reappears somewhere else. Problem is that the internal move representation of the GUI only has a single locust square, and it is already used to indicate the locust capture. When it points to an empty square it is interpreted as an unload. Of course an unload on the same square as the capture really is a no-op; it just becomes a simple (hopper) move, and the e.p. square would not have to be set or indicated at all, just as for entering hops you don't have to indicate the mount. So the highlighting function should be changed to treat locust capture + unload on the same square the same as a hop, the only difference being that it tests whether the victim has the right color.

💡📝H. G. Muller wrote on Sat, Dec 11, 2021 06:34 PM UTC in reply to Bn Em from 05:05 PM:

I can even get an offset giraffe‐rider (or even zemel‐rider — presumably longer ones work too, if they'd fit on the board), even though normal giraffe‐riders (FXFX?) are apparently unsupported!

The way it works now is that an even number of y force the next leg to be orthogonal/diagonal with a stride of half that number + 1, while the next odd number of y then adds a sideway step of 1 to that. (So there is currently no way to specify a Zebrarider in the 2nd leg.) But the preprocessor would not recognize any rider beyond CC, and never generates more than the 5 y needed to request that. Duplication of extended atoms is indeed not supported. Initially I thought of atom duplication as a legacy feature, and preferred a range 0 for specifying unlimited-range riders. FX0 should work.

But the y extension still fails for e.g. [W?sfZZ] (also shouldn't that be fsNN ⁊c?), let alone pathological things like [C?fsZZ], so if we're making an effort to support direction‐type changes it probably deserves to be more general.

That I used sf in [W-sfNN] was nonsense (and in fact turned out to be buggy when I first tried it), as sfN means the same as fN: both forward-most moves. I had suppressed the multiple-y extension on oblique first leg, but there really is no need to do that, so I lifted that ban now, and [C-fNN] should work too.

Also speaking of the Z, [Z?sfB] currently gives me Zebra‐then‐Rook, and vice‐versa

This is a consequence of sf being an invalid direction specification for B after an oblique. The continuation here always uses the K system of directional specs, and I laid out the transparent path of Z before B so that it ends in the diagonal direction, which means that B is the f direction. The specification fs causes the underlying XBetza interpreter to apply atom rotation, making the continuation Rook-like. So this is an example where the directional spec overrules the atom type. (Which of course is the basis of XBetza, which doesn't even specify the continuation atoms.) [Z?fB] should have given you what you wanted.

Now that we can use incommensurate atoms, the definition of 'forward' continuation had to be extended. I did that such that after oblique this is the diagonal slide that stays in the same quadrant. While oblique after queen-like uses the degenerate 8-fold system, so that f refers to a pair of moves.

💡📝H. G. Muller wrote on Sat, Dec 11, 2021 04:14 PM UTC in reply to Bn Em from 01:23 PM:

Oþoh I can see the other case where someone expects to simply be able to write e.g. [B-fW] for a transcendental prelate/contramanticore, and is confused by the fact that it disallows the W squares ...

But there B is an initial leg, and I don't like it at all that initial legs would behave differently from only legs. Perhaps we have different intuition, because I would consider it natural that the Tamerlane Giraffe would only need F+2W: one for every traversed square where it isn't allowed to stop. When 0 steps is allowed, you would need [F-fF-fB] for the Tamerlane Picket, and [F-fB] would be a normal Bishop. I think that is really strange.

BTW, [W?sfNN], and even [W?sfCC] work now. All through using a new, undocumented (and quite horrible) extension of XBetza.

💡📝H. G. Muller wrote on Sat, Dec 11, 2021 12:46 PM UTC in reply to Bn Em from 12:09 PM:

Imo the explicit mention in the description (which is also erroneous as it omits the nD move — though the diagram includes it) is only because humans aren't used to counting to (or from) 0(!)

True, but isn't 'intuitiveness' all about catering to human peculiarities? It is not so much that I am worried about the description of the Fox, but more that in all kind of other cases people will get extra moves because they did not count on a slider leg also eliminating itself by taking 0 steps.

At that point surely it's not much harder just to support an arbitrary leaper atom as the first stage?

Well, so far every leaper is a special case, where I have determined by hand at what point it has to turn the corner, and how much extra transparent squares to add before or after that point. For inital N, C or Z this works now.

I'm guessing the likes of [W-NN] are out of scope for now? :P let alone [W-CC] which camel moves can't emulate at all…

Yes, this is hard. Because so far I implemented everything as a pre-processor, translating the bracket notation to XBetza by replacing the hyphens / question marks for a, eliminating all atoms, and writing the first atom at the end. So it cannot do anything that XBetza cannot do. (The resulting XBetza can be seen in the Betza Sandbox by clicking the move in the table a second time, btw.)

💡📝H. G. Muller wrote on Sat, Dec 11, 2021 08:57 AM UTC in reply to Bn Em from 01:06 AM:

It feels a bit silly to adapt a notation to the shortcomings of a particular font, but the - and ~ here are nearly indistinguishable for me on my desktop. (Not on my tablet, though!?) So I was looking for alternatives that also convey the intuitive notion of optional versus mandatory. How about ? and ! for this? So [F?fsR] would be the Griffon, and [F!fsR] the one that does not have the F move. The Tamerlane Picket would be [F!fB]. The area move from Tenjiku Shogi would be [K?K?K]. I am not sure ! would be intuitively better than - , though, as a mandatory sequel.

I kind of like the ?, though. In most cases it would make it unnecessary to allow zero steps in a slider leg; you could use ? in front of it instead. I admit that this would not work if there are still other legs following the slider leg you want to cut short, (such as with the Fox), because these would then be cut off the move too. But the F and D moves of the Fox are a rather non-intuitive consequence of the general description, so I would not consider it bad if it needed to be mentioned separately. (As the textual description indeed does!) Like [W-fsB-fsW][W-W].

Tamerlane Picket: [F-fB]
Ski-Bishop: [A?fB] (but XBetza also offers jB for this)
Slip-Rook: [W?fDD]
Griffon: [F?fsR]
Manticore: [W?fsB]
Unicorn: [N?fB]
Osprey: [D?fsB]
Lame (Picket-like) Osprey: [nD?fsB]
'Delayed' Manticore: [W?fW?fsB]
Mao: [W-fsF]
MaoWazir: [W?fsW]
Narrow Mao: v[W-fsF]
Wide Mao: s[W-fsF]
Moa: [F-fsW]
Narrow Moa: v[F-fsW]
Wide Moa: s[F-fsW]
Moo: [K-fsK]
Ship: v[F?fsR]
Sissa: [Q-ivsQ]
Checker capture: f[cF-fmF] or [fcF-fmF]
Fox [W-fsB-fsW][W-W]

Of these notations, the Interactive Diagram currently only fails to understand the Ship, Wide/Narrow Moa (v or s would be applied to the first leg, not the move as a whole), and the Unicorn (N and B are not 'commensurate' atoms, and it would use NN in the second leg). I already solved the problem of incompatible strides in the first two legs (B, R, Q after D, A, G or H) by automatically slipping in transparent steps to get the initial leap. I suppose I would have to add some dedicated code for Q after N as well (and perhaps after C and Z?). Depending on whether the second leg is B or R the initial N leap should be either layed out as a Mao or a Moa, to align the second step with the f direction of the original second leg. For Q after N we would have a problem, as it is not clear anymore whether the most-outward direction is the adjacent diagonal or orthogonal slide. But I guess it would be no big loss to declare that illegal.

💡📝H. G. Muller wrote on Fri, Dec 10, 2021 09:40 PM UTC in reply to Daniel Zacharias from 07:38 PM:

What about using the brackets alone to indicate that all the moves contained within are part of a sequence? [FfR] [smpWsR]

Well, for practical reasons I would prefer to have some separator between the legs. (Then I can just use the JavaScript split method to split the move in the parts between the hyphens, while otherwise this should be judged by the case of every individual letter.) I think that once you allow the brackets, allowing other non-alphabetic characters as well is no longer a problem.

The idea of considering a certain grouped sequence of directional modifiers plus atoms as a 'crooked atom', and allowing the whole group to be prefixed, does have merit, however. Otherwise you would have to specify a separate move for each leg the mount could be in to make a hopper. E.g. for the Grao you would need [pF-fsR][F~fspR] (i.e. mount either at the F square or in the Rook path). Then p[F~fsR] is a lot simpler. The Interactive Diagram internally already uses this method for moves like zB and qN: it creates a complete description of the maximum-length path as a sequence of 1-step legs, with in each leg a special mode flag to indicate the move can also terminate there. And it does allow the entire path to be used as a hopper, in order to allow zpB or zgB. I could easily extend that to allow user-defined paths.

And you are right: the entire Griffon move is essentially an oblique slider, like the Nightrider. So it does make sense to allow indicating the individual trajectories by the same direction system as the trajectories of the Nightrider (or Knight). So the Ship would be the 'Narrow Griffon', like vN is the Narrow Knight.

💡📝H. G. Muller wrote on Fri, Dec 10, 2021 08:10 PM UTC in reply to Jean-Louis Cazaux from 06:34 PM:

Not sure what you mean by long. The "R" part? I don't see what the problem is, it is not easy by messages. "Outward" for me means the move is always in the direction of going away from the starting square both in x and y. If after the first leg, the second leg starts by going to a square that is closer to starting square either in x or y than the intermediate square (between the two legs), then it is not outward on that definition.

If the N moves goes from e1 to f3 (i.e. both increasing in the x and y dimension) then both f3 -> f8 and f3 -> h3 are R moves that neither decrease x nor y. So both fit your definition. But they are not equivalent. Probably f3 -> f8 has the best claim on being called 'outward'. One could argue that the other one is unnatural, because it crosses its counterpart that moves from e1 -> g2 -> g8, and therefore is unlikely to ever occur in any game. So that there also is no need to have any notation for it.

Anyway, I brought this up in order to show that just having one new symbol, meaning 'outward', is not enough, but that we would likely need a complete system for indicating all 8 relative directions. Which seemed worse than just using the existing system used for indicating the 8 directions relative to the player. As these new symbols would only be encountered in multi-leg moves, which are quite rare themselves, so that people would not be familiar with those, but likely think "what kind of a freaky symbol is that???".

The price for this is that these symbols would no longer be available for indicating absolute directions, though.

The Ship just happens to be one of these very rare nasty cases, because the equivalent moves of the Ferz alternately bent to the left and the right. It hardly ever happens that referring to an absolute direction is of any help. I can think of many solutions, but most of those require introducing new symbols or new meanings of existing symbols that would virtually never be used, and thus unknown to the casual user of Betza notation. I think the best way is to accept that compactnes and intuitiveness here are conflicting demands, and thus go for the somewhat cumbersome description [frblF~flR][flbrF~frR], to explicitly indicate on which starting steps there is a right bend, and on which a left bend.

A more practical problem is that the difference between tilde and hyphen is hardly visible in this font...

💡📝H. G. Muller wrote on Fri, Dec 10, 2021 06:24 PM UTC in reply to Daniel Zacharias from 03:51 PM:

I think mpsyasW is pretty clear, but perhaps not very intuitive.

Well, I think it is a justified complaint that it is not easy to see that there is a Rook move hidden in there. The bracket notation [smpW-sR] would make that more explicit. The notation of a full Griffin based on this idea would be [mpW-sR], and would automatically visit the F squares, as these are now reached by the first sideway Rook step. But it literally requires some 'out of the box' thinking to detour the trajectory over an auxiliary square (sW), and subsequently make that square fully transparent by giving it mode mp. And this obscures the fact that in reality the first square visited by the piece (in the sence that it can move to it or be blocked there) is an F square. That distracts greatly from the intuitiveness.

Doubling of directional modifiers is a bit tricky, as sometimes it is needed to prevent such modifiers from combining to the intermediate direction. E.g. if we want to describe a Knight that lacks the two backward-most moves, we must specify an s and an f direction on it. But we cannot just write fsN, as this means flNfrN, and fl and fr describe individual N moves. To prevent that we write ffssN.

💡📝H. G. Muller wrote on Fri, Dec 10, 2021 10:34 AM UTC in reply to Jean-Louis Cazaux from 07:23 AM:

I see Betza's notation as a convenient and intuitive way of describing the moves of a chess piece. I believe XBetza's notation has another goal, that of being able to be understood by an AI for the cases not covered by the basic notation.

In principle there is no limit to what an AI can understand; it is just a matter of how much effort you put in creating it. And I subscribe to the goal of making move description convenient and intuitive, even for moves that are intrinsically more complex, such as the Griffon, Falcon or Chu-Shogi Lion. So think it is worth it to put a great deal of effort in achieving that goal.

But for any system of notation it seems important that it is unambiguous, and covers sufficiently many cases. Betza himself has suggested the t[F,R] notation for Griffon, but this is not unambiguous, as an 'Acute Griffon', which would continue inward instead of outward, making a 135-degree turn, (or the piece that can continue in all four Rook directions), would be written the same. Furthermore, the leading t seems redundant here: the 'then' meaning could be implied by the presence of the brackets. I think Betza suggested also other uses for the brackets, like z[F,W] for a slider that alternats W and F steps in a crooked way, but this distinction could also have been made by using other separators than comma for that, e.g. [W/F]. Once non-alphanumeric characters are allowed in the notation, lots of options are available.

I hope you agree that it hardly matters for the intuitive understanding whether one would write F&R, F-R, [F-R] or [F,R]. But now suppose that we want to slam extra W moves on a Griffon... I don't like WF&R so much, because intuitively you would parse this as (WF)&R, as punctuation usually separates 'words'. While it is intended to mean W(F&R). This is why I think it would be better to require some sort of parentheses around the complex moves. And to stay as closely as possible to Betza's legacy, these can be brackets. With W[F-R] there is little doubt that the W is a separate move.

The ambiguity problem has to be solved by putting some directional specification on the continuation legs, to distingush outward from inward, or even between several possible outward directions (such as in the case of the Ship). In your example you suggested a new prefix character ($, as we have run out of letters) for indicating 'outward'. This has the advantage that we can keep using the original directional modifiers in the meaning they have in the absolute frame of reference. This works well for the Ship, where you can write F&$vR to make the extra v pick out the vertical of the two outward Rook paths.

But I wonder whether introducing a whole new system for indicating relative directions is worth it. For one, the use of an absolute direction to disambiguate equivalent relative directions only rarely works; the Ship is a favorable case. It would for instance not work on a 'Chiral Griffon', which would bend always in the same relative direction (left or right), to give a rotation-symmetric rather than reflection-symmetric move pattern. And how would you know that in N&$R 'outward' would mean 'in the direction of the long component'? Some are v and others s so you cannot use those to indicate it. And if you define the meaning of 'outward' on oblique moves as in their long direction, how would you describe a piece that would continue like a Rook in the short direction of the knight move? It seems that we would have to create a whole new system for describing relative directions, or groups of directions, similar to the existing Betza system for absolute (initial) directions, but using puntuation characters instead of the familiar fbvlrs. That would involve a lot of new characters, but perhaps these could be chosen in a somewhat intuitive way, so they would not be too hard to remember (like ! for outward, ^ for inward, < for turn left, > for turn right, _ for < or > and | for ! or ^). But it still seems a hassle, which can be exploited only very rarely.

So I think there is a lot of merit in sticking to the existing Betza scheme for indicating directions, but interpret them as relative directions on continuation legs. Then instead of needing a new symbol like $ or ! for 'outward', we can simply use f for outward. In a sense the Betza directional modifiers have always been relative: for simple moves they are relative compared to the way the player is looking. We also say fmWfcF for black Pawns! (And in a 4-player game even v and s have player-dependent meaning.) Is F&fR really any less intuitive than F&$R ? You would lose the possibility to disambiguate the two outward Rook moves by use of an absolute direction, but you now have a simple way to write a (right-handed) Chiral Griffon: F&frR. One always has to compromise: what makes one piece easier to describe, will make some other piece that behaves in the opposit way more difficult to describe. I think it would be a mistake to judge a description system solely on how well it does on a single piece that you happen to use, but is not very common, and even less representative for the general problem.

There also is a more fundamental issue: writing the Griffon as F&fR or [F-fR] assumes the move can also be terminated without making all its legs, after just the F step. It might be subjective whether this is intuitive or not; it seems to me that this is mainly inspired by the case at hand (i.e. bent slider). Problem is there are many other cases where you would not want this. E.g. lame leapers like the Mao also need a multi-leg description to indicate where they can be blocked. But if W&fF or [W-fF] also allows making a W move, how can we describe the Mao then? And if fcF&fmF would also allow plain capturing diagonally forward (fcF), how would we describe the Checker? We do need a way to describe complex paths that cannot be terminated half-way. One way would be to forbid incomplete moves, so that these have to be described as separate moves when they are desired. (Advantage: no new notation needed. Disadvantage: move descriptions get longer.) The alternative is to introduce a different symbol for continuations that are only optional. E.g. [F~fR] could mean a Griffon that can make F moves, as the fR continuation is optional. While [F-fR] could not make the F move, although it can be blocked on the F square, as the fR continuation is mandatory. Actually I sort of like this latter solution, even though it requires introduction of a new symbol.

I would also like to have some feedback from other people, on what they would consider intuitively clear in these matters.

💡📝H. G. Muller wrote on Thu, Dec 9, 2021 09:48 AM UTC in reply to Jean-Louis Cazaux from Wed Dec 8 08:00 PM:

I am still a bit unhappy with the need for an s prefix on a diagonal atom (where it does not select any initial direction) in order to define a meaning of q and z in following legs. Perhaps we should always classify all moves of an atom as either bending left or right; for oblique atoms this is natural, as the left and right moves are mirror images. For orthogonal and diagonal atoms this would be artificial, but could be adopted as a convention. E.g. on a diagonal atom fr and bl could be defined as bending right, while fl and br could be defined as bending left. For an orthogonal atom we could define f and r as bending right, and b and l as bending left. (I cannot imagine a case where this would be useful for f and b, though.) A Ship would become FafzF with these conventions, as we want the initial fr step to bend left, i.e. in opposit direction as the (artificially assigned) initial bend.

@Jean-Louis:

I would still like your opinion on whether you think F(F-fsR) would be a less cryptic notation for the Griffon (and F(F-fzR) for the Ship, KNAD(cK-K)(cK-bK)(K-bK) for the Chu-Shogi Lion, where (cK-bK) is the igui, (cK-K) the locust and double captures, and (K-bK) the turn pass). Or perhaps F[F-fzR] with brackets instead of parentheses?

[Edit] Just to try it out a bit I now made it such that notations like [fF-fsR] are also accepted for multi-leg moves. The interpretation is still very flaky, though. Basically the atoms mentioned in the later legs are ignored, except their range (which must be leaper or infinite). The direction is purely derived from the angular spec in front of them. So it does not matter whether you would write B, R or Q as continuation leg. I suppose that I could make it such that it checks whether the directional spec is compatible with the mentioned atom, and issue an error message when it is not. Nice feature is that the first atom can be a distant orthogonal or diagonal leap, and then combine with a slider in the next leg. So the Osprey would be D[D-fsB]. It can also be made non-jumping, e.g. R2[nD-fsB].

💡📝H. G. Muller wrote on Wed, Dec 8, 2021 07:00 PM UTC in reply to Bn Em from 06:02 PM:

BTW, I now made it such that FsyafqF for the Ship works too. (Refresh cache!)

Explanation: q in a continuation leg stands for l or r that would bend the path in same direction as before / initially. So fq can mean either 45-degrees left or right. Now the s at the start of the multi-leg part defines 'sideways' as the initial direction (which for diagonal atoms would otherwise be ambiguous). So the move toward the lower right bends to the right (if you imagine it to start to the right), so it bends 45-degree right again for the second leg, which makes that move straight down. The move to the upper right, however, had to bend left if it startes horizontally to the right. So the leg after that one bends left, making it move straight up.

💡📝H. G. Muller wrote on Wed, Dec 8, 2021 05:18 PM UTC in reply to Jean-Louis Cazaux from 04:48 PM:

flbryafrFfrblyaflF: doesn't work. It skips the F-square

That is correct. But then you simply add it explicitly: FflbryafrFfrblyaflF.

All the bent trajectories you can specify with XBetza skip the first square (or actually the entire first leg if it is more than a single square, or even all non-final legs if they have more than two legs). All legs mentioned in a description are compulsary, and must contain at least one step if they are sliding.

This was a choice; it could have been defined such that slider continuation legs can make 0 to infinite steps, rather than 1 to infinite (like the initial or only leg can). But what would you do then for a piece where you don't want that? E.g. a Griffon that cannot move to the F squares, even though it can be blocked there? It is much easier to add the F moves to a piece that not naturally has those, than it would be to prevent it from stopping on the first square of its path. So asR is a hook mover that must turn a corner, and cannot move like a simple Rook. If you would want it to move as a simple Rook as well, as the Hook Mover from the large Shogi variants can, just write RasR.

💡📝H. G. Muller wrote on Wed, Dec 8, 2021 04:08 PM UTC:

@Bn Em: your trick for the Ship with the z is clever, but makes the description even less intuitive. When I made the Tamerlane II diagram this alternative use of z did not exist, though. I am not sure if defining a meaning for z and q without first using an s would be helpful. But, come to think of it, s is a dummy on a diagonal atom, as lF is the two left moves, and rF the two right moves, so together these are a full Ferz. But such a dummy s could be used to define the symmetry breaking as used by following z or q. I guess it would be most useful to define it such that it causes the diagonal atom to be interpreted as an oblique one with the longest leap in the sideway direction (i.e. as sN would have been interpreted). Then the Ship would be FsyafqF.

I have no idea why yafqF does what it does. Without a preceding s or oblique leg it triggers the code for the old Betza meaning, which lays out the entire path for the circular piece, with a special mode flag to indicate it can be terminated at any square along the path. But the preceding leg must utterly confuse it...

💡📝H. G. Muller wrote on Wed, Dec 8, 2021 03:23 PM UTC in reply to Jean-Louis Cazaux from 11:50 AM:

I agree that the way XBetza handles multi-leg moves is not very intuitive. I don't think it is too late to switch to a more intuitive notation, as long as it doesn't allow specification of moves that would not be possible to specify in XBetza. Because then it would be quite easy to just equip the Interactive Diagram (or XBoard) with a simple pre-processor, which just converts the more human-friendly notation to XBetza before interpreting the latter.

E.g. how about writing multi-leg moves always within parentheses, using a hyphen as leg separator, and requiring all atoms should be 'compatible'? Where compatibility means they should either all be multiples of K steps, or of the same oblique leap. The Griffin would then be F(F-fsR), and the pre-processor would act on anything between parentheses, run through the legs to see whether range-toggling is needed. Depending on that it then translates the hyphen to a or ya. So that it ends up with the modifier string yafs, after which it then writes the leading atom F to get the equivalent XBetza. (I guess we could also use square brackets and commas, to stay closer to Betza's original suggestion: F[F,fsR].)

As to your specific questions: the Snake is easy: vWvyafsW. This is just the Manticore with all its moves prefixed with a v. The Ship, however is hard. This is not so much the fault of the notation, but caused by the fact that moves with different initial steps bend in different directions, and you have to indicate which (while for the Snake all moves bent in both directions). The only way to do it is to separate the left-bending from the right-bending move, i.e. the diagonal from the anti-diagonal first steps. This in itself is cumbersome, as there are no shorthands like v or s for diametrically opposed diagonal moves. So you have to write out all directions, and being diagonals, each direction requires two letters. E.g. a Ferz moving along an anti-diagonal is flbrF, and in the Ship you want those to bend to the right (i.e. fr) in the next leg. So you get flbryafrF for these two paths. And then you have to write the other two paths in the same way, changing all l into r and vice versa. This is how I did it in my Diagram for Tamerlane II. (Note that flbr[F,frR] as it would look in the proposed more intuitive system would not be much less cumbersome...)

Interactive diagrams. Diagrams that interactively show piece moves.[All Comments] [Add Comment or Rating]

💡📝H. G. Muller wrote on Tue, Dec 7, 2021 11:11 AM UTC in reply to A. M. DeWitt from 02:42 AM:

OK, the pawn on e3 made all the difference. Clearing the cache I do all the time, to test new features.

The code was lacking a test at the second leg to see if the locust squares that were entered so far matched the move that was currently being generated, and would thus also highlight the third leg of all other possible triple captures. This should be fixed now.

Good catch, it had escaped my testing! (Another case that had escaped my initial testing, but which I discovered later myself, was Fischer castling with K@c1 and R@b1, because the code tried to calculate the destination of the Rook from the direction the King moves in. While it should have tested what side the Rook is on initially!) Yet another bug I fixed recently was in preserving left-right symmetry when shuffling; this did not work correctly on a board with an odd number of files.

💡📝H. G. Muller wrote on Mon, Dec 6, 2021 07:27 PM UTC in reply to A. M. DeWitt from 05:46 PM:

This is really weird. I have tried Chrome too now, and also don't see anything strange there. When you try this with an open console (F12), do you get any error messages there while you enter the move?

💡📝H. G. Muller wrote on Mon, Dec 6, 2021 08:53 AM UTC in reply to A. M. DeWitt from 01:57 AM:

What I see is this (Fire Fox and Android browser):

1st click on e4: d4 and c4 -> blue star (= 2nd leg can follow), b4 = red dot (simple capture e4xb4)
2nd click on d4: e4 -> yellow dot (igui), d4 -> red dot (simple capture e4xd4), c4 -> blue star (3rd leg can follow), b4 -> red dot (e4xd4xb4 double capture)
3rd click on c4: c4 -> red dot (e4xd4xc4 double capture), b4 -> red dot (e4xd4xc4xb4 triple capture)
4th click on b4 -> move accepted, move indicated with greenish background on e4, b4 and reddish background on c4, d4.

This is exactly as it is supposed to be. Do you see anything different? If so, what?

Fischer Random Chess. Play from a random setup. (8x8, Cells: 64) (Recognized!)[All Comments] [Add Comment or Rating]

H. G. Muller wrote on Sun, Dec 5, 2021 09:50 PM UTC:

Fischer castling now should work in the Interactive Diagram, including the AI.

[Editor's note: Disabled to prevent interference with Interactive Diagram on page.]

<script type="text/javascript" src="/membergraphics/MSinteractive-diagrams/betza.js">
</script>
<div class="idiagram">
  graphicsDir=/graphics.dir/alfaeriePNG35/
  graphicsType=png
  symmetry=mirror
  shuffle=N!BRQK
  pawn::::a2-h2
  knight:N:::b1,g1
  bishop::::c1,f1
  rook::::a1,h1
  queen::Q::d1
  king::::e1
</div>

Interactive diagrams. Diagrams that interactively show piece moves.[All Comments] [Add Comment or Rating]

💡📝H. G. Muller wrote on Sun, Dec 5, 2021 07:10 PM UTC in reply to A. M. DeWitt from 06:32 PM:

Either I cannot reproduce it, or I don't understand what you mean. When I go to the Betza Sandbox, and assign the more compact description of the Lion Dog I gave below to the 'star piece', and play e12-e3 b2-b3 c2-c3 d2-d3 (all illegal, but just to set up a situation), I can then enter e3xd3xc3xb3, and I don't see any spurious highlighting or other irregular behavior. While there are still lot of pieces in range for the KADGH direct captures.

Are you sure you are not running a cached version of the old script?

Capablanca Random Chess. Randomized setup for Capablanca chess. (10x8, Cells: 80) [All Comments] [Add Comment or Rating]

H. G. Muller wrote on Sat, Dec 4, 2021 10:13 AM UTC:

I have made an attempt to implement Fischer castling in the Interactive Diagram. There is no special XBetza notation for this; a shuffle game has to be specified with a 'nominal' setup. This setup defines (together with the XBetza normal castling definition) where the king must end up, and what the castling partners are (the corner pieces, which must be of equal type). If such a castling is defined, any shuffle that involves the king will then be restricted to make the king end up between the castling partners, and will activate Fischer castling.

To support the shuffle rules of Capablanca Random Chess I enhanced the Diagram's shuffle feature: An exclamation point before a piece in a shuffle specification now either means that pieces of that type should be equally distributed over square shades, or, when there only is one such piece, that it must remain on the shade it is already on. This way Q and A can be forced on different shades by putting them so in the nominal position, and order an extra shuffle of only Q and A to determine which one goes on which shade. The shuffle specs are thus QA,N!BR!AC!QK.

Initially a Diagram always shows the nominal position; there is no spontaneous shuffle. To shuffle you have to press 'Restart' in the AI control bar.

[Editor's Note: Disabling this diagram to keep it from interfering with the one on the page.]

<script type="text/javascript" src="/membergraphics/MSinteractive-diagrams/betza.js?nocache=true">
</script>
<div class="idiagram">
files=10
ranks=8
promoZone=1
promoChoice=NBRQAC
graphicsDir=/membergraphics/MSelven-chess/
squareSize=35
graphicsType=png
shuffle=QA,N!BR!AC!QK
pawn:P:ifmnDfmWfceF:pawn:a2,b2,c2,d2,e2,f2,g2,h2,i2,j2,,a7,b7,c7,d7,e7,f7,g7,h7,i7,j7
knight:N:N:knight:c1,h1,,c8,h8
bishop:B:B:bishop:d1,g1,,d8,g8
rook:R:R:rook:a1,j1,,a8,j8
queen:Q:Q:queen:e1,,e8
archbishop:A:BN::b1,,b8
chancellor:C:RN:chancellor:i1,,i8
king:K:KisO3:king:f1,,f8
</div>

Betza notation (extended). The powerful XBetza extension to Betza's funny notation.[All Comments] [Add Comment or Rating]

💡📝H. G. Muller wrote on Fri, Dec 3, 2021 02:00 PM UTC:

I extended XBetza notation to give new meaning to the use of the z and q modifier in continuation legs of multi-leg moves, where the original meaning of crooked and circular are not useful. The intention was to solve the problem that in a bent trajectory that contains an s (also in combinations fs / bs) the equivalence of l and r is broken. A move described as afs...W starts like the Xiangqi Horse (W, and from there diagonally outward). But in a description like afsafrW the next bend in the path is 45 degree to the right, irrespective of whether whether the first bend was taken to the left or right. It thus describes two different move shapes (Alfil-like or Camel-like), rather than two orientations of moves of identical shape. That is incovenient: it preclude the use of s for compactifying the notation, and forces one to write the two symmetry-equivalent paths separately (afraflWaflafrW for the Camel-like or 'crooked' version).

From now on this can be written as afsafzW. The z then indicates that the path bends in the opposit direction as the preceding s. A sequence of z legs would thus always describe a crooked path. Similarly, a q would indicate bending in the same direction as the previous bend, and a sequence of q legs would give a circular path. This new use of the modifiers allows the description of the Falcon move to be shortened to afafsKafsafzfK: the first atom describes a path that bends after 2 steps, the second atom one that bends immediately, and then either bends in opposit direction (fz) or goes straight on (f).

Note that on oblique atoms the symmetry is broken from the very start, even without the use of an s. Such moves are interpreted as if they started in their longest direction. (So g1-f3 would be a 'left' move.) You should thus never use l or r in continuation legs of an oblique atom, or after an s leg, but always use z or q instead.

The Sultan's Game. Variant on 11 by 11 board from 19th century Germany. (11x11, Cells: 121) [All Comments] [Add Comment or Rating]

H. G. Muller wrote on Thu, Dec 2, 2021 07:30 PM UTC in reply to Jean-Louis Cazaux from 06:37 PM:

When castling, the king move four squares toward one of the rooks, and the rook jumps to the other side of the king.

That definitely sounds more sensible. I had to add a special parameter castlingGap to the Interactive Diagram to support the weird way of castling that is described in the text. (I see the Diagram in the article has already been changed to castle in the normal way, though, unlike the one I first published in the comments.)

Capablanca Random Chess. Randomized setup for Capablanca chess. (10x8, Cells: 80) [All Comments] [Add Comment or Rating]

H. G. Muller wrote on Thu, Dec 2, 2021 07:26 PM UTC in reply to Thomas from 06:04 PM:

Umm, I did not even know this rule existed. WinBoard restricts the shuffle only to have the Bishops on different colors. I agree the rule makes no sense. I have also seen descriptions that did not allow the Bishops to be on adjacent squares. (That also seemed to make little sense.)

The Interactive Diagram would have to struggle to enforce this rule, because there is no way to tell it directly that a pair of pieces of different types would have to be placed on different square shades. As a work-around you could 'mark' the shades by piece type, by defining the nominal start position with a back rank RBRBNKNCQA, so that RNQ are on dark squares, and BKCA on light. You can then order a sequence of shuffles, RNQ,BKCA,QA,!BNRKC .

The first shuffle solely serves to put Q on a random dark square, the second to put A on a random light square, and the third then randomly swaps the two. The remaining pieces then have to be shuffled the usual way, i.e. the Bishops would have to go on opposit shades (indicated by the ! prefix).

I guess it would be useful to extend the shuffling capabilities of the Diagram with a prefix to indicate the piece should stay on the same color as it was in the nominal setup. Sy This would be indicated by #, then the shuffle instructions could be K#QC#AR!BN,QA, with a nominal setup where Q and A start on different shades.

Interactive diagrams. Diagrams that interactively show piece moves.[All Comments] [Add Comment or Rating]

💡📝H. G. Muller wrote on Thu, Dec 2, 2021 06:45 PM UTC:

I finally got to upgrading the Diagram so that it would be able to support (a limited form of) double locust capture. In particular, I considered it a blemish that it was not able to handle the Lion Dog that occurs in the large Shogi variants (which can make up to 3 radial King steps per turn, and thus capture up to 3 pieces in one move). The AI of the Diagram was already capable of supporting any number of locust captures, but up to now it was not possible for the user to enter a capture with more than one locust victim (in addition to the normal victim in the destination square).

This is now fixed, albeit in a clumsy way. The Diagram still does not support locust capture of any pair of pieces, but only those where these victims are on the same ray, on the first and second square. But that is exactly what the Lion Dog needs. (This limitation came about by the fact that it still uses only a single e.p. square, which then implies the second square.)

There was a lot involved in getting this to work. (It needed new code for generating the move notation, parsing such moves when you paste a game, communicating it to and from the AI, and of course for interpreting the clicks made when you enter a move.) I hope that I got everything right. I also made the Diagram smarter in understanding XBetza descriptors that have both destructive and non-destructive action at the square connecting the legs. (These need a different set of clicks to play: non-destructive intermediates, like the corners in a bent-leaper trajectory, never need to be clicked, while locust victims do.)

The Lion Dog can now be represented in XBetza notation as: KADGHcavKmcafcavKpafcafKcafmpafK . This is a bit cumbersome, but I saw no easy way to allow a 2-out-1-in move (using v in the 3rd leg) only when the first square gets captured or already was empty, and forbid it (using f)when it was an occupied square that was hopped over. So 3 types of three-leg moves need to be described. I guess to also describe null move an extra abK would be needed.

[Edit] I guess that the slightly more compact KADGHcavKmpafcavKcafcmpafK would also work. This only needs two descriptions of the 3-leg move. One for the 3-out move that captures the adjacent victim, and in addition optionally the one on the second square. And another that in any case captures two squares away, and then either continues either out or in. Possibly making a normal capture on its destination. The disadvantage of this is that for the 2-out-1-in move the victims are captured in reverse order (furthest first). Which could make a difference in the case of contageon, when both the captured pieces are contageous. (As they could be in Maka Dai Dai Shogi. Although this is of course a 'never happens' situation.)

Home page of The Chess Variant Pages. Homepage of The Chess Variant Pages.[All Comments] [Add Comment or Rating]

H. G. Muller wrote on Thu, Dec 2, 2021 08:23 AM UTC:

The re-definition of the piece images is at the bottom of the Pre-Game section in all these presets. Somewhat further down in this discussion Aurelian posted a link to an ongoing game with this preset, where the problem manifests itself.

Symmetric Chess.

Variant with two Queens flanking the King and Bishops Conversion Rule. (9x8, Cells: 72) [All Comments] [Add Comment or Rating]

H. G. Muller wrote on Wed, Dec 1, 2021 09:41 PM UTC:

When I paste that game up to move 24 back into the Diagram, and then play Rxb3, it doesn't reply with that same Bishop move. And when I play the (illegal) move Qa6 instead of Rxb3 it doesn't capture the Queen, but plays Bd8. Did you flush the browser cache, (Shift + reload in FireFox) to make sure you are using the latest version of the diagram script? You might have been using the old version where I hadn't implemented the rule yet. If you are sure you have flushed the cache you can paste the moves 1-23 back in the Diagram (in the dashed text box below the navigation buttons), and continue the game from there.

H. G. Muller wrote on Wed, Dec 1, 2021 03:55 PM UTC in reply to Carlos Cetina from 02:33 PM:

Do you think that the Interactive Diagram software could be used in the Android environment?

I know that for sure. It is browser-based, and every OS nowadays has a browser that understands HTML and JavaScript. So you don't need a separate App for it. (Of course the browser is also an App, but I assume everyone already has that.) It works fine on my Samsung Tablet.

H. G. Muller wrote on Wed, Dec 1, 2021 10:13 AM UTC:

I have implemented the bishop conversion rule now as a standard feature of the Interactive Diagram. So that it is now also possible to play Symmetric Chess against the AI (for which the trick of changing both bishop's piece types when one of them moved did not work). All that is now required is define the bishop with an extra initial iW move, and add a parameter conversion=N, where N is the number of the piece table of the piece to which the rule applies. (So here N=3). The first moves of pieces of this type are then forced to go to different square shades.

files=9 promoChoice=NBRQ graphicsDir=../graphics.dir/alfaeriePNG/ whitePrefix=w blackPrefix=b graphicsType=png squareSize=50 symmetry=none conversion=3 pawn::::a2,b2,c2,d2,e2,f2,g2,h2,i2,,a7,b7,c7,d7,e7,f7,g7,h7,i7 knight:N:::b1,h1,,b8,h8 bishop::BiW::c1,g1,,c8,g8 rook::::a1,i1,,a8,i8 queen::::d1,f1,,d8,f8 king::::e1,,e8

Play-test applet for chess variants. Applet you can play your own variant against.[All Comments] [Add Comment or Rating]

💡📝H. G. Muller wrote on Mon, Nov 29, 2021 06:43 PM UTC in reply to Jean-Louis Cazaux from 04:41 PM:

How to remove a piece from the diagram. For example if I want to put the King on another square than those on which they stand by default?

You can move the pieces over the board, just like you can when you use the diagram for playing. If you want to remove a piece that you selected by mistake, but do not want on the board after all, it is a bit more tricky: you would have to capture it with another piece, and the Diagram only accept attempts to capture if they are pseudo-legal moves (i.e. when the piece to capture gets highlighted when you select the piece you are going to capture it with.) Best way is just to move the piece next to the opposing king (moves to empty squares are always accepted, even when not pseudo-legal), and then capture it with the king, and finally move the king back to where it belongs.

Also, how to use "paste an existing diagram". For example, I want to create a play-test for Shako. What can I paste in that box, an image? the link for the shako page? something else? I don't know how to use this?

That box is for pasting diagram descriptions of the type you get when you press the 'Show HTML' button at the bottom of the article. It is intended for trying out diagrams that you modified by editing the text of their description, e.g. to implement some features that the Play-Test applet would not allow you to switch on. Such as Shogi-style promotion. You can then first make the Diagram without that feature, ask for the HTML, paste it in a text editor to modify it, and copy-paste the modified version back into the diagram. Or when you get a Diagram from another page (by asking for 'Page Source', and copy-paste from there. (I discovered that also there you have to paste it into a text editor first; directly copying from the Page Source seems to leave in all kind of invisible formatting information the Play-Test Applet chokes on.)

E.g. when you want two promoting piece types, you would have to add the line maxPromote=2 to the Diagram description, otherwise only Pawns will promote.

[Edit] I forgot to say: there is also a button for creating GAME code for automating a Game Courier preset. Originally the paste box was added to make it possible to convert an Interactive Diagram that you made before and posted somewhere else to GAME code. Without the need to entirely recreate the Diagram through the Applet. Which for large variants would be more cumbersomet than just copy-pasting an existing and well-tested Diagram into the box, and pressing the GAME-code button.

MSchess-with-different-queens[All Comments] [Add Comment or Rating]

H. G. Muller wrote on Sun, Nov 28, 2021 07:29 PM UTC:

I see that the Lion now has become a regular 2-step area mover. I tested a Lion that was blocked more easily (KaFafsW), because it was missing the Moa path and lame Dabbabah (nD), so that only the D move was multi-path (reachable in 2 ways), by pitting it against a Queen in Fairy-Max. To my surprise the lameness did not weaken it that much compared to a KNAD: it beat the Queen by 63% in 200 games, which is only slightly smaller than the Pawn-odds score.

The balance could still be improved a little by making every square on the 'second ring' reachable through a single path only. E.g. the A squares through the F squares, (as they already are), and all others through the W squares. So that it becomes a compound of a range-two Queen and a Xiangqi Horse (Q2afsW). That would most likely still leave it stronger than a Queen, while all other replacements are weaker than Queen.

I also tried the WyasW against a normal Griffon. It was only marginally stronger. I guess it suffers a lot from the fact that the paths cross on the F squares, which means that there now are 8 squares where two of its arms can be blocked. This makes the detour over the W squares nearly as much as a liability as an asset. Furthermore, it made the piece very difficult to develop; the initial F step is really useful for sneaking between Pawns. This was quite annoying, so I would not recommend use of this piece. and stick to the regular Griffon.

Home page of The Chess Variant Pages. Homepage of The Chess Variant Pages.[All Comments] [Add Comment or Rating]

H. G. Muller wrote on Sun, Nov 28, 2021 07:54 AM UTC in reply to Aurelian Florea from 12:12 AM:

Well, like you said, there is nothing for me to see. The GAME code looks OK as far as chanģing the piece set is concerned, and does work on the first ply. It was not changed between the first and second ply. This is a general Game Courier problem that only Fergus can shed light on.

Play-test applet for chess variants. Applet you can play your own variant against.[All Comments] [Add Comment or Rating]

💡📝H. G. Muller wrote on Sat, Nov 27, 2021 08:07 PM UTC:

Great! Those caching problems are always very annoying.

The idea of having it first write the Betza notation in a text edit is that you can still alter it by typing in case you want something so special that the move-entry tool does't support it. (Like a limited range of 5 squares, or a bent slider.)

💡📝H. G. Muller wrote on Sat, Nov 27, 2021 07:46 PM UTC:

The only suggestion I can make is that it might be possible to see what is going on through the 'Browser console' in FireFox. This shows whether any errors occur in the JavaScript program of a page. On a PC I can open it in the lower half of the screen by pressing the F12 function key and selecting the 'console' tab, or typing Ctrl + Shift + J to open it in a separate window. But I don't know if a Mac keyboard even has these keys. You might be able to get there through some menu.

If you press the button that would activate the code that is supposed to place the text, an error message might appear in the console, to report what went awry.

Another thought: have you tried to flush the browser cache (Shift + reload on my FireFox). Perhaps you are still using an old version of some JavaScript file that is still cached in your browser.

💡📝H. G. Muller wrote on Sat, Nov 27, 2021 01:17 PM UTC:

What is the difference between the play-test applet and the diagram?

The Play-Test Applet is an interface page for altering the Diagram it contains, and use it in-place, or display its HTML source code so that you could post the Diagram elsewhere. In that other location it would still be an Interactive Diagram, but you can no longer change the rules by which it plays. (Unless you edit the page, of course.) In principle you could also have typed the source code of that Diagram by hand, if you knew the definition format. There is a seperate article here over Interactive Diagrams, which contains a 'Design Wizard' that also can generate source code for you. This is a bit less user-friendly (you have to complete a large form for specifying all kinds of parameters, also for defining graphics), but gives you more control over the generated Diagram than the Play-Test Applet.

Of course you can also use a hybrid method for creating a Diagram: use the Play-Test Applet to design a Diagram that is as close as possible you can get to what you want within the Applet's limitations, (e.g. everything except the promotion rules), and then edit the source code to add what it was missing. You can then post this modified source code on a page of your own (or in a comment). Or you can even paste it back into the Play-Test Applet, to test it there.

To implement Shogi-style promotions you would have to redefine the parameters maxPromote (giving the number of promotable pieces) and promoOffset (how much they shift up in the piece table when promoting), and reorder the piece definitions such that they are in the right place in the table to cause the correct promotions.

💡📝H. G. Muller wrote on Sat, Nov 27, 2021 10:50 AM UTC in reply to Jean-Louis Cazaux from 08:44 AM:

Am I doing wrong ?

Well, that the squares go blank again when you press one of the buttons is intended behavior. But the Betza notation for the cleared squares should appear in the text entry 'Betza move description' just below the table from which you select pieces. E.g. if I click the square above the star piece and press the move-only button, the text fmW should appear there. If I then click the squares diagonally above the star piece, and press capture-only, the text should change to fmWfcF. I have no Mac where I can test this, but on my PC it works with FireFox, and on my Android tablet with the Android browser it works too.

Home page of The Chess Variant Pages. Homepage of The Chess Variant Pages.[All Comments] [Add Comment or Rating]

H. G. Muller wrote on Fri, Nov 26, 2021 01:41 PM UTC in reply to Aurelian Florea from 07:17 AM:

@HG, I don't see the problem.

I don't understand what problem you don't see. You wouldn't be posting this here if you did not see some problem.

Play-test applet for chess variants. Applet you can play your own variant against.[All Comments] [Add Comment or Rating]

💡📝H. G. Muller wrote on Fri, Nov 26, 2021 01:35 PM UTC in reply to Daniel Zacharias from 03:36 AM:

Is there a way to have different promotion options for different pieces, as in shogi?

Not in the Play-Test-Applet. The Diagram itself of course supports it, and the Design Wizard as well. But it does require a more complex interface than the Play-Test Applet has to specify that. Because it requires the pieces to be listed in the Diagram in some specific order to associate the correct promoted form to a base piece. And the Play-Test Applet uses the order of the table from which you select the pieces. It is already a bit inconvenient to have promotion to pieces that are not initially on the board; in order to generate a Diagram or GAME code that would include those pieces you wuld have to drag those somewher on the board after having pressed the Initial Position button, but before generating the HTML or GAME code.

I am not sure how a Shogi-type promotion could be defined. Perhaps it could be done by, after defining the initial position by pressing the button, replacing all pieces in it by their promoted versions, and then hit some 'Promotion Assignment' button.

100 comments displayed

⇩Latest ⇩Later ⇩Reverse Order⇧ Earlier⇩ Earliest⇧

Permalink to the exact comments currently displayed.