Ratings & Comments

I have not looked there in a while! Why do you ask?

• Mitsugumi Shogi

(Same as old page, but with the hyphen removed)

There is something wrong with the diagram for Desert Pub Chess. When the AI moves, it seems to spuriously remove pieces from the board in unpredictable ways. Furthermore, this bug also affects the desert pieces, causing them to not capture properly when they capture more than once.

Normal Move Bug Replication

Move each pawn forward one at a time, you should see the opponent's pawns add locust squares (the dull red highlights) when moving. Eventually the AI will make a Knight move that removes a friendly pawn. 

Desert Piece Bug

Make the following moves manually:

1. e2e4 f2g4 2. Fc8d5

Then open the AI dashboard and move a white piece. You will see some very strange behavior (only one white pawn gets captured and the other is "moved" to a different square).

pieces are tramplers

That happened to me too when I signed in after trying to change my password by email. Email is not working, and I didn't get the email it sent. When I signed in from the same page where I had tried to send an email for changing my password, it said "Cannot continue, because no row in the Person table could be identified." To change your password, do it within five minutes of signing in, or ask for assistance. Since you were able to sign in to post this, you should be able to do it within five minutes of signing in. Just click on the link with your name, or select "Personal Information" from the menu with your name, and then click on Change Password.

The set groups Chushin Shogi and Taishin Shogi have no working graphics for any of the sets listed.

Problem when trying to change password: "Cannot continue, because no row in the Person table could be identified."

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.