Ratings & Comments

The problem is that the Notes section includes some TEXTAREAs of its own, and when the first one closes, it closes the TEXTAREA the Notes HTML is being displayed in.

Okay, it's looking good.

The text was rewritten and the graphics were fixed. It is ready.

@Fergus: I have moved the Interactive Diagram that was somewhere down in the comments section into your article, replacing the diagram of the initial setup. (Your original image is still there, within <noscript> tags for those who have JavaScript disabled.) It tried to mimic the original image as much as possible, without resorting to a dedicated background image of the whole board. I hope this is OK with you.

(N.B. Flush the browser cache to use the latest Diagram script, as the previous one did not 'bleach' the dark color for the odd files when displayiong a move diagram.)

Hello Greg,

I have 2 questions:

1. How does the colourbound pieces bonus/penalty work when more pairs of colourbound pieces are involved?
2. Does the endgame value of a piece influence opening exchanges, or is it just the middlegame value?

For some reason it is not possible to edit this article through the [edit content] link editors will see at the bottom of the page. That is, you get to the edit form, but when you press the 'Send' button nothing happens. I had no such problems with oter articles.

Is there a place where editors report their acivities, so that the other current and future editors knows what is being done?

I usually report my activities on relevant pages. There is no centralized place for this. If you want to, you could post what you're doing to your profile, since posting comments to profiles is now doable.

https://pychess-pr-657.herokuapp.com/

Mansindam has been temporarily added to Pychess!

Here is the BadZone function's code:

function badzoneZone(x2, y2, piece, color, x1, y1, ex, ey) {
  if(touched) return 0; // not during ShowMoves()
  if(piece == 35 || piece == 65 || piece == 66) // Fire Demons and Heavenly Tetrarches
  {
    evic = (ex >= 0) ? board[ey][ex] & 511:-1;  // intermediate square
    if(evic == 35 || evic == 65 || evic == 66) { // Problem area
      if((x1 == x2 && y1 == y2) || (ex == x2 && ey == y2)) return 0; // Allow direct capture or igui
        else return 1; // else reject
      }
    }
    return 0;
  }
}

Eventually I hope to make it so that burning pieces cannot burn each other at all.

You can view a diagram with this function implemented here.

The definition of the Knight move is not correct. On an undistorted board it would allow the Knight to also move like Wazir or Ferz. This could be fixed by also excluding moves that are reachable in a single step.

I missed that before, but you are correct. I can rewrite it like this:

The Knight can leap directly to any space that could be reached in two one-space moves except for those reachable by a Rook or Bishop. Since it's a one-space move from A4 to b4 or from H5 to g5, a Knight on A4 or H5 can leap further away than a Knight can normally leap.

I made an Alfaerie set for Chu Shogi that makes use of Jeremy Good's pieces. I reversed the colors, so that dark pieces are used for Black and white pieces are used for White.

It seems that the new move handler isn't updating the part of the diagram that shows which piece is selected.

Ah yes, it wasn't. I now fixed that too.

That was what I was thinking as well, and given that the rest of the code is fine, we are probably right. Unfortunately, simply getting rid of that clause won't really solve the issue. The Heavenly Tetrarch has a unique mechanic that causes it to jump over the first square it travels over, so the preset needs to take that into account. It might be possible to get rid of it with clever use of the cond statemenet though.

Edit: Turns out I was using the wrong variables to account for the distance of the first part of the move. The values of origin and dest were updated before the move was evaluated, so the distance would always be 1 and the move would thus get rejected. I fixed this by using ori and dst instead, which stay the same for all parts of the move.

So the problem is that the Tetrarch should not be able to capture another Tetrarch when it lands on a square next to it, but should be able to capture it when it was already standing next to it, without moving? In addition to capturing one other piece?

I see that your HT subroutine has a line where it refers to origin and dest instead of to #from and #to. That may be where your bug lies.

Thx, but about moving of previous version of Ox, it’s just historic note.

If you want to make historic notes about Horizons, the Horizon article would be the place to do it. Not the article about another Chess variant. People intersted in Horizons might never look here, people interested in Stone Garden Chess might not be interested in Horizons, let alone in its history.

Thanks, Greg!