Comments by ChessShogi

Diagram parameters would be ideal, but there's one little problem. When rule enforcement require complex decision making (such as in Suzumu Shogi's current version, which forbids burning pieces from burning each other) the diagram parameters would be less than ideal. So there would likely still be a need for such functions even if the parameters eliminate the majority of cases where they would be needed.

I'm not sure how you intend to merge move rejection, game termination, mandatory promotion, and offering promotion choice, into a single function, unless JS allows you to return a value that could be one of many different types.

But I suppose it is better to stick to perfecting the new move generation system for now and focus on the functions later in development.

It seems that the holdings do not work correctly. Whenever holdingsType is set to anything other than 0, for each piece, it subtracts the amount on the board from the amount present at the start of the game rather than showing the actual amount in the hand. Also, setting holdingsType to -1 does not change the color for Shogi drops like it should.

It is now fixed.  However, I also noticed that promoted pieces are affecting the hand when they shouldn't, particularly for Shogi-style promotions (increments original, decrements promotion).

Nice.

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.