Ratings & Comments

Hi H.G.

For the Alibaba if I recall right I gave a considerable (x2) leaper bonus to both the A and D components, before primitively concluding AD (aka Spider)=A+D+P=2.25

Where A=D (roughly) = (N-P)/[2 times 2] (roughly) each (Why the N? - I treated an A or D leap as kind of similar enough to a N leap, except they each only go to half as many cells). Why the 'N-P'? Well, if Q=R+B+P then my imprecise way of guessing a piece half a Q's power would be (Q-P)/2, for example. Why '/[2 times 2]'? Well that's the final penalty factor, where one of the 2's means that an A (or D) only has half as many moves as a N.

If I also recall right, it's

Where A is binded 3 ways, and D is bound just 2 ways, but is often slower than an A (thus a penalty factor of /[2*8] should perhaps be used for each [rather than /4] I feel, but the leaper bonus I gave for the A and D each is a factor of x2, and I [perhaps generously] gave A and D each a x2 bonus for distance often covered faster by a series of leaps compared to a series of N leaps, so thus the final /4 penalty factor).

So, A+D+P (for AD, aka Spider) = (N-P)/4+(N-P)/4+P = 0.625+0.625+1 = 2.25

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.

Just for fun

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.

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.

Greg, what is the strength of the king used by the joker value evaluation?

BLACK TO MOVE AND WIN???

The year is 2023 and the rules for this 8x7 variant still state:

"... 6. A pawn may only promote to a captured piece [QRNB] and not move to the last row unless there is a piece to promote to. 7. If a player can only legally move his King or can not legally move any pieces (a very rare situation), then he loses."

So Rule [6] encourages me to play Black King f1-e2-d2-c2-b2 and start promoting pawns. But the always infuriating rule [7] makes this a lost position for Black. The question remains: What is going on here?

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.

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.

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

Link?

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.

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".

Suzumu Shogi is ready

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

Also, I am getting this error whenever I try to update my previous comment:

Attempting to update comment.

SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'WHERE `CommentID` = ?' at line 1

Update of Comment with ID of 46749 failed.

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.