Ratings & Comments

The queen and wizard don't slide then, correct?

That is correct.

Checkmate might be rather difficult here, but I haven't thought too much about it; the pieces are weaker than many 4D variants, but it's also a very small space.

It's been possible in my testing, but I'm not super good at chess, so I could be missing something.

I successfully tried updating a couple of my comments, including one on this page, and I successfully updated the comment you referred to, though that was with a different script than you would use. So, I have not been able to repeat what you did.

Looking at the PHP error log, I see multiple errors looking like this:

Failed to prepare SQL in update_row: UPDATE `Comment` SE WHERE `CommentID` = :keyvalue

This was added to the error log by a catch clause I have in update_row().

That "SE" shouldn't be there, but there should be the word "SET" followed by a series of parameters being assigned to table columns. Since we appear to be in the same time zone, these were just over an hour and a half ago, and I was not doing any programming then.

Looking at the individual lines modifying $sql, most lines just append to it, and one uses substr to delete the last two characters. That points to one thing that happened. The $sql string could have this value if it were passed an empty array. After appending nothing to "UPDATE Comment SET ", it chopped off the last two characters and appended " WHERE CommentID = :keyvalue". I added some code to update_row to catch this error before this happens, but I'm still not sure why it happened. This is about what arguments were passed in the function call and not about how the function operated.

Editors can do it with the editlink.php script, but we currently have no script for letting authors do it. So, add a comment to your page about what you want the description to say, and someone will add it for you.

update test

Suzumu Shogi is ready

How can I edit the description of a page already created? I mean the description that shows in the listings of pages.

Specifically I want to add a description to Square Attrition Chess so that it does no longer show the bold "Missing description".

To make life easier for those who want to extend the Interactive Diagram with custom JavaSCript, I added a second argument to xxxTinker(): this gets passed the distance to last rank, corrected for piece color. Almost every WeirdPromotion() function I have ever written required calculation of that.

I added functions in the standard script to aid with other tasks: AddVictim(move, x, y) adds a locust square (x, y) to the specified move. And VetChoice(promoPiece, d) tests whether chess-like promotion to promoPiece would be allowed (as per promoZone and promoChoice) when you are d steps removed from last rank. You might want to fake a d within the zone in cases where the user script requests a promotion outside the zone.

The moving piece will always be stored in move[-6]. As an example, when you want to allow piece type 2 to promote when it arrives on last rank from the fore-last one, but not from a larger distance, you could use

function xxxTinker(m, d) {
  if(d != 0) return 0;             // not to last rank
  if((m[-6] & 511) != 2) return 0; // not piece type 2
  if(m[3] != m[1] + 1 && m[3] != m[1] - 1) return 0; // not a single step
  if(!m[-1]) return 4;             // choice not yet made, request one
  return VetChoice(m[-1], 0);      // return whether choice is forbidden (1) or not (0)
}

If under the same conditions a shogi-like promotion to piece type 12 (different from what promoOffset would specify) should take place, things are simpler:

function xxxTinker(m, d) {
  if(d != 0) return 0;             // not to last rank
  if((m[-6] & 511) != 2) return 0; // not piece type 2
  if(m[3] != m[1] + 1 && m[3] != m[1] - 1) return 0; // not a single step
  m[-1] = 12 | m[-6] & 1024;       // specify promoted type (adding color)
  return 3;                        // request choice between this and deferral
}

Scripts like this are only needed to make the promotion dependent on the move; if it is just dependent on the square you move to, or what you capture there, the standard parameters morph and captureMatrix take care of the promotion for you. The way I have implemented it now these would have precedence over the user-supplied scripts. That is, when these specify a promotion, ban or game termination, this will be applied without question, and the xxxTinker() script will only be invoked when they don't specify anything special. So the script only has to handle the non-standard cases.

Although the script could now add as many locust victims to a move as it wants, and wherever it wants those, the trick to request burning or atomic capture through promotion code 512 will still work, and the standard script will add the locust squares in that case.

Link?

The Review New Submissions page seems to be skewed towards new submissions now, rather than submissions that have new changes ready for review. This makes approving pages much harder, as you will only see the newest pages rather than the ones that have changes ready for review. Perhaps if the page is sorted by the timestamp of the last action taken on each article this can be rectified without having to worry about the unreliable modification date.

update test

Mitsugumi Shogi seems to be missing. It doesn't have as many problem pieces as its big brother Suzumu Shogi, so it can be added to the list without much trouble. I've also successfully tested a modified NextLeg function, which relieves the AI from having to use cumbersome recursive functions to vet moves for the range capturing pieces, which I will implement in the CVP articles soon.

I think I will implement the following interface for extending the Interactive Diagram with user-supplied scripts:

The user can supply a JavaScript function xxxTinker(m), where xxx is the satellite name for the Diagram (default value: 'piece'), and m is an array describing the move. This array will contain the board coordinates (which always start counting at 0) for the squares involved in the move, the rank number following the file number of each square. The first square (in m[0] and m[1]) will be the origin, the second (m[2] and m[3]) the destination, and after that will come the locust squares in the reverse order as the XBetza description visited them. The element m[-2] will specify how many squares will be altered by the move. (So if there are no locust squares this will be 2: the origin and destination.) After the locust squares can come squares where e.p. rights are generated; these are not counted in m[-2]. It is not specified how many there are of those, and most moves do not have them.

The element m[-1] contains the promotion piece for the move (i.e. the piece that will appear on the destination square), but it might or might not be initialized.

This xxxTinker() funtion can then modify the m array in any way it wants. Likely modifications are altering or supplying a promotion piece in m[-1], or adding locust squares by writing those in the appropriate m[] elements, and increasing m[-2] correspondingly. When it is done tailoring the move, it should return a value to indicate to the standard script what it should do with that move. Possible return valueas ar:

-2 Terminates game immediately, as a win for the player that can do the move (as if the move captured a King).
-1 Terminates the game as a win if the player making it survives the reply of his opponent (as with Shatranj baring).
 0 Take the move as we now prepared it (which could be unaltered).
 1 Discard the move; it is forbidden (e.g. due to zonal confinement, or improper promotion piece).
 2 Suppress deferral of normal Shogi promotion (as per maxPromote and promoOffset).
 3 Take the promotion we specified in m[-1], but also add a move that defers.
 4 Perform a Chess-like promotion. Moves with every possible promotion type will be subjected to xxxTinker(), and can be
   rejected or accepted by it in the normal way (returning 1 or 0).

The value 4 should only be returned when the value of m[-1] was undefined (if(!m[-1])...), to make a move that otherwise would not promote at all offer a Chess-like promotion choice. If m[-1] does have a value > 0 the promotion choice has already been made, and we must only reject or accept it.

SHATRANJ BLOCKADE STALEMATE IN 20 MOVES

Using Zillions, I played out a make-believe game, which ends with the 4 remaining Black Pawns blockaded by 4 White pieces, while a Black King, Chariot, Knight, Counselor, and Elephant are locked in behind the Pawns. Even if the rules allowed Kings to move into check and be captured, Black still has no legal moves in the final position.

NOTE: the initial position had Kings on the d-file. I posted the completely legal game on the Shatranj page way back on [2005-03-08]. Apparently this led to the latest version of Rule [7]. See my previous post for why I am still dubious about the entire rule set.

I'll look into it more deeply hopefully!

I added mention of the pO notation for fast castling to the XBetza section, and dressed up the article with two Interactive Diagrams for exemplifying flexible and fast castling.

I also added mention of the K~b1 notation for unambiguously specifying flexible castlings.

The article is a bit vague about the castling and promotion rules. The choices you made in the FSF settings (O3 castling and no promotion to Prince) seem the logical ones, though.

Anyway, I put in some section headings, and added an Interactive Diagram in the Setup section, playing by these rules.

And you are right: this 'promotion to King' business seems a bit nonsensical: you simply win by reaching the last rank with a Prince, so there is no need to change it for another piece. There is a question, though, whether it is allowed to promote it on a square attacked by the opponent. In the Diagram I programmed it as an immediate win, because the rules explicitly say that you can expose a Prince to capture. But if you would really promote it, it would no longer be a Prince, and you would have exposed the resulting King to capture. So this 'promotion to King' could be just be a roundabout way of saying that this is a delayed winning condition, where you have to survive the opponent's 'after-move' in order to win (like in King of the Hill). But this interpretation is subverted by the mention of the first variant, which uses the resulting King as extinction royalty, so that it could be exposed to capture.

Just for fun

Here is a Fairy-Stockfish variant file that I made for the variant. Despite the E and Elephant symbol, these pieces are still princes (princE). It might not be 100% accurate, but this should be incredibly similar to the actual variant, as there are essentially no differences between promoting the princes to kings to win (by getting them directly to the last rank) or merely getting the princes to the end of the board (the last rank) to win. This variant also has defined castling rules.

[chessii:janus]
startFen = rnbeqkebnr/pppppppppp/10/10/10/10/PPPPPPPPPP/RNBEQKEBNR w KQkq - 0 1
customPiece1 = e:WF
pieceToCharTable = PNBRQ............E...Kpnbrq............e...k
castlingKingsideFile = i
castlingQueensideFile = c
whiteFlag = *8
blackFlag = *1
flagPiece = e
maxFile = 10
archbishop = -
promotionPieceTypes = rnbq

This is meant to be used with https://fairyground.vercel.app/, and should be pasted into a file called variants.ini, before loading the variants.ini file into the website.

I edited my previous comment, in case any missed that.