Check out Balbo's Chess, our featured variant for October, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

EarliestEarlier Reverse Order LaterLatest
Play-test applet for chess variants. Applet you can play your own variant against.[All Comments] [Add Comment or Rating]
💡📝H. G. Muller wrote on Fri, Dec 18, 2020 04:33 PM UTC:

Ah, I think I got it. In the generated Pre-Game code this is fishy:

set partners (f1 d1 f10 d10); // 'rook' locations for castling

This mentions the Queen as possible castling partner, and apparently the move generator doesn't explicitly test for the occupant of the King target, as it assumes the King could not 'see' the Rook when that square is occupied in the first place. (Note that Fischer castling is not supported.) The move take-back during legality testing for highlighting purposes (which does run in the initial position!) apparently counts on the King target being empty, and doesn't put the victim back.

I am not sure how the Applet could have generated this partner set. The values are strange; they seem to apply to the 8x8 board, in absence of any pieces. (By default it is the most-distant piece.)

Another thing that is fishy is that the King table also contains vertical castlings. You must have forgotten to put the s modifier on the O3. This doesn't really hurt, as the piece in front of the King is not in the 'partner' set. It just wastes some time.


Greg Strong wrote on Fri, Dec 18, 2020 04:40 PM UTC in reply to H. G. Muller from 04:33 PM:

Removing post-game does not fix it. Also removing post-move also does not fix it. This is a real head-scratcher. I don't understand at all...


💡📝H. G. Muller wrote on Fri, Dec 18, 2020 04:53 PM UTC in reply to Greg Strong from 04:40 PM:

Note I edited my posting before your latest one!

P.S. I think we had problems before removing a section, when you accidentally had misplaced some of the function calls. This seems a general problem of the GC preset editor. This might explain why 'removing' the Post-Game section has no effect.


Greg Strong wrote on Fri, Dec 18, 2020 05:00 PM UTC:

Oh, ok. Glad you were able to figure it out! I'm going to try to generate the game with the designer again...

How do you remove the King that starts on the board automatically? I don't see any obvious way to remove a piece that has been placed. (General question - not needed for this game.)


💡📝H. G. Muller wrote on Fri, Dec 18, 2020 05:12 PM UTC in reply to Greg Strong from 05:00 PM:

It seems there is a bug in the Applet for generating this 'partners' array. I am pretty sure it worked before. But I had a regression at some point in the Diagram script, when I apparently uploaded a 'fix' applied to an older version, and this probably lost the code for identifying castling partners.Castling doesn't even work in the Diagram itself. (Not obvious, as for legacy reasons it always allows the user to castle with a Rook. But the AI cannot do it anymore.)

The only way to remove a piece is to capture it (and only pseudo-legal moves can capture!).


Greg Strong wrote on Fri, Dec 18, 2020 05:37 PM UTC in reply to H. G. Muller from 05:12 PM:

Ok, I remade it and the problem is gone and I have castling working the way a I want. Unfortunately, I have a new problem. The unmoved pawn can move up to four spaces. So, I used the Omega Pawn which should allow it to move up to the center. I'm sure this used to work, but now the white pawn can move one square too far and the black pawn ends one square too soon. (In the generated GC code, not sure if this affects the diagram/AI.)


💡📝H. G. Muller wrote on Fri, Dec 18, 2020 06:42 PM UTC in reply to Greg Strong from 05:37 PM:

I don't understand that. The * range is encoded as -1 in the tables, which is then dynamically replaced by the actual range in the move generator:

    switch #rng:
      case -1:
        set rng cond < 0 #dy rank #cursqr - lastrank rank #cursqr;
        set rng - >> lastrank 1 #rng;
        set rng max 1 #rng;

In infix notation this reads

rng = (dy > 0 ? RANK(cursqr) : LASTRANK - RANK(cursqr)); // start rank (flipped for black)
rng = (LASTRANK >> 1) - rng; // distance from board half.
rng = max(1, rng); // minimally 1

On a 10-rank board MAXRANK = 9, so LASTRANK>>1 should be 4. That should give you 4 steps from the back rank (rank 0 for white and 9 for black). From their starting rank it should be 3 steps. I don't see anything wrong here. In particular, I don't see how white and black Pawns could behave differently.

Can the GAME-code variable 'lastrank' actually return the number of board files (minus 1)?


Greg Strong wrote on Fri, Dec 18, 2020 06:55 PM UTC in reply to H. G. Muller from 06:42 PM:

I don't know how to test that. I tried:

tell lastrank; tell var lastrank; tell #lastrank;

None of them work...


💡📝H. G. Muller wrote on Fri, Dec 18, 2020 07:38 PM UTC in reply to Greg Strong from 06:55 PM:

It seems I can modify & test the preset as well, even though it is not mine, through Edit, Test, Play. I tried

print lastrank; die;

as first thing in the Pre-Game code. This prints 11...


Greg Strong wrote on Fri, Dec 18, 2020 07:41 PM UTC in reply to H. G. Muller from 07:38 PM:

Ok, so lastrank is returning the last file and not the last rank.


Greg Strong wrote on Fri, Dec 18, 2020 08:17 PM UTC in reply to Greg Strong from 07:41 PM:

Hmmm... So I found where this is handled in the PHP code and it looks correct:

       case "lastfile": // Returns numeric index of last file
           array_push ($output,  count($file)-1);
           break;
       case "lastrank": // Returns numeric index of last rank
           array_push ($output,  count($rank)-1);
           break;

So I'm not sure why this is happening.


💡📝H. G. Muller wrote on Sat, Dec 19, 2020 06:45 AM UTC:

You defined too many rank labels.

Automatic detection of the castling partners should now also work again in the Applet. It is invoked every time you press the 'Start Position' button. It does assume white and black have their castling partners on the same files.


Greg Strong wrote on Sat, Dec 19, 2020 03:11 PM UTC in reply to H. G. Muller from 06:45 AM:

You defined too many rank labels.

Thank you!  Must have made this from an earlier preset.  Sorry for the trouble!


Greg Strong wrote on Sun, Dec 20, 2020 12:19 AM UTC in reply to H. G. Muller from Sat Dec 19 06:45 AM:

It seems there's an issue with the optional javascript. It works with alfaerie, but when I change it to abstract it only appears OK until I move a piece.

https://www.chessvariants.com/play/pbm/play.php?game%3DJanus+Kamil+Chess%26settings%3Dstandard

I think the issue is probably that some of the abstract pieces are smaller than the square size.


💡📝H. G. Muller wrote on Sun, Dec 20, 2020 08:52 AM UTC in reply to Greg Strong from 12:19 AM:

I think the issue is probably that some of the abstract pieces are smaller than the square size.

Indeed, the Abstract images have variable size. The movepiece.js script copies their URL from cell content to background style, and apparently the default mode for background is to tile, starting in the upper-left corner.

This was easy to fix: in the loop that does the image copy I now also set the background-repeat and background-position styles to 'no repeat' and 'center center'. You would probably have to append a ?nocache=true parameter to the movepiece.js URL to make sure the new version is used.


Greg Strong wrote on Sun, Dec 20, 2020 05:06 PM UTC in reply to H. G. Muller from 08:52 AM:

Thanks! Updated Janus Kamil presets have been published. I plan to, over time, update older presets with this technology. Hopefully I'll be able to streamline the process so it doesn't take too long.


Greg Strong wrote on Fri, Dec 25, 2020 10:29 PM UTC:

Here's a small problem: the generated GC presets don't recognize or allow the command "resign"


💡📝H. G. Muller wrote on Sat, Dec 26, 2020 08:45 AM UTC in reply to Greg Strong from Fri Dec 25 10:29 PM:

Here's a small problem: the generated GC presets don't recognize or allow the command "resign"

Isn't that by definition a Game Courier / GAME code problem? I would think that resigning should always be possible in any game in any situation. It also seems that 'resign' should be considered a move, rather than a command; it is one of the possible things a player can (always) do when it is his turn.

The include file bans commands. I don't want the preset to allow commands in general, just to be able to process 'resign'.


Greg Strong wrote on Sat, Dec 26, 2020 03:51 PM UTC in reply to H. G. Muller from 08:45 AM:

The error is "board step does not mention two squares". Isn't that message generated by your code? I think even when commands are banned, that one is still allowed.


💡📝H. G. Muller wrote on Sat, Dec 26, 2020 08:43 PM UTC in reply to Greg Strong from 03:51 PM:

Ah, OK. I guess ticking the checkbox to not include moves in the GAME code also applies to 'resign'. I will let my move parser recognize it.

Should I expect similar problems for draw offers?


Greg Strong wrote on Sat, Dec 26, 2020 09:48 PM UTC in reply to H. G. Muller from 08:43 PM:

Yes, you should probably allow "drawn" too. Players will discuss a draw in comments and then one will enter the drawn command.


💡📝H. G. Muller wrote on Fri, Jan 1, 2021 10:34 AM UTC in reply to Greg Strong from Sat Dec 26 2020 09:48 PM:

Yes, you should probably allow "drawn" too. Players will discuss a draw in comments and then one will enter the drawn command.

This should be fixed now, without any impact on the preset's efficiency: I only do the test for resign and drawn at the point where it otherwise would have given the error message about the move syntax.


Greg Strong wrote on Fri, Jan 1, 2021 06:37 PM UTC in reply to H. G. Muller from 10:34 AM:

It still didn't work, but now there's a new message:

Syntax Error on line 24

Misplaced endsub.


💡📝H. G. Muller wrote on Fri, Jan 1, 2021 07:52 PM UTC in reply to Greg Strong from 06:37 PM:

My bad, I wrote elsif: instead of elseif: somewhere. And I didn't test, as I figured that 'resign' would only work when you are actually playing a game. But it seems I can actually type 'resign' in Play mode. But this produces very strange behavior. I have this code in ParseMove now:

  if != 2 count #sqrs:                               // must give 2 squares
print . count= count #sqrs;
print thismove;
    if == resign thismove:
print ok;
      resign;
    elseif == drawn thismove:
      drawn;
    endif;
    die "board step does not mention two squares";
  endif;


When I enter 'resign' it prints 'count=1', 'resign' and 'ok' as expected. Then, however, it survives the 'die', and continues until it later dies with the complaint that 'resign' isn't even pseudo-legal for a Pawn.

[Edit] It seems resign doesn't have the new behavior in this context: it terminates execution of the current subroutine, but not of the GAME code. It happily continues with the caller.


🕸Fergus Duniho wrote on Sat, Jan 2, 2021 01:17 AM UTC in reply to H. G. Muller from Fri Jan 1 07:52 PM:

It seems resign doesn't have the new behavior in this context: it terminates execution of the current subroutine, but not of the GAME code. It happily continues with the caller.

Would you set up a sample preset that exhibits the bug you're describing?


25 comments displayed

EarliestEarlier Reverse Order LaterLatest

Permalink to the exact comments currently displayed.