Comments by ChessShogi

I fixed most of the issues. Now the only problem that I can see is that the Heavenly Tetrarch's first burn is being rejected when it shouldn't be when the distance between the origin and destination of the first part of the move is at least 2. The problem is likely in the HT subroutine, since it controls the function definition for the second and third parts of the Tetrarch's move, but I could be wrong.

Here is the link for the preset's Edit form: Edit: Suzumu Shogi on the Chess Variants Game Courier

And here's the list of moves for which the error occured:

1. d 8k-8j 
1... D 9f-9g 
2. p 7l-7k 
2... P 10e-10f 
3. bg 6m-8k 
3... BG 11d-9f 
4. fd 7n-6k 
4... FD 10c-11f 
5. fd 6k-8i 
5... FD 11f-9h; pass 
6. fd 8i-5f; fd 5f-5e; fd 5e-4e 
6... FD 9h-12k; FD 12k-12l; FD 12l-13l 
7. fd 5f-7f; pass 
7... FD 12k-10k; pass 
8. fd 7f-7e; fd 7e-7f; fd 7f-8f 
8... FD 10k-10l; FD 10l-10k; FD 10k-9k 
9. bg 8k-15d; +bg-dest 
9... BG 9f-2m; +BG-dest 
10. dk 5n-5o 
10... DK 12c-12b 
11. cs 4o-14e; +cs-dest 
11... CS 13b-3l; +CS-dest 
12. +cs 14e-14d; +cs 14d-14e; +cs 14e-13d 
12... +CS 3l-3m; +CS 3m-3l; +CS 3l-4m 
13. +cs 14e-11b; +cs 11b-10a // <- ERROR: You may not move a +cs from 11b to 10a

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.

I can make a revision with the BadZone code in it if you want.

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.

Suzumu Shogi is ready

Thanks for fixing checkahop.

As for the rest of the RANGECAPTURE code, the not so compact cx and cy assignments were me trying to fix the bug before realizing it was a server-side issue. I can just use cmp there since the jumping Generals can only jump along the eight cardinal directions. Since they use #ori and #dst (the variables that store origin and dest), and the jumping Generals cannot change direction mid-move, there is no need to compare directions, as using cx and cy with checkaride and checkhop returns the same direction as that of the first part of the move. The if statement with the checkaride clause is there to enforce the two jump limit for these pieces. If that checkaride clause fails but the ismultimove subroutine succeeds, the moving pieces has jumped over a piece (and another piece which it just captured) already, and thus cannot jump any more pieces.

Fair enough.

It seems I had an extra parameter in the israngecapture subroutine from when I was trying to use a subroutine to determine whether a range capturing piece had any legal moves left mid-move. It is fixed now. The responsibility of determining whether a piece has any moves left mid-move has been moved to the Post-Game sections, making use of the legalmoves2 subroutine's return value. I also fixed Mitsugumi Shogi's GC preset, which had the same problem.

Edit: I also got rid of the from parameter in the israngecapture subroutine and the statements that call it. Since it wasn't being used within the subroutine itself, there was no need to include it in the parameter list.

BTW, I have played Tenjiku at high level according to 'modern' rules, where the King can be jump-captured. To my surprise this was very playable, and not too unbalanced. If you know the correct opening lines. Which my Tenjiku engine was able to determine.

In addition I came to realize that the King has highest rank does not necessarily have to refer to capture. Originally I thought that outlawing jumping over a King only would be pointless, as you would never be interested in doing that when you could also capture it. But it could also refer to your own King. So the evidence that historic rules did not allow King capture is starting to get flimsy.

Jumping Generals are not allowed to jump over a King or Prince (or other higher-ranking pieces) of either side, regardless of which ruleset you use, so the fact that the rankings could refer to friendly pieces is a rather dubious piece of evidence for allowing jump-captures of royals. Besides, even if the evidence for forbidding jump-captures of royals is indeed flimsy, it still improves the gameplay, as allowing jump-capturing of the King creates a critical weaknesses in the opening after 1. 7k (2. VG 2g#) which is only solvable via 1... SE3f. Furthermore, this weakness persists throughout much of the game, as the King remains boxed in throughout the opening and (early) middlegame, the Soaring Eagle on 3f (and other pieces defending 2g and 1h) can easily be threatened with capture, and one wrong move can result in a smothered mate. The point is, you should not need to use an AI to find a good opening.

Unfortunately this is not so easy, because BadZone only gets the locust squares passed. Not the pieces jumped over. The non-destructive intermediate squares are not part of the internal move representation. But I suppose BadZone could be made such that it scans the board for high-rank blockers along the path from origin to destination itself.

You can just use board[y][x] & 511 for the piece type, and a call to a recursive function that scans the in-between squares to handle the rest.

Ok, fair enough.