Check out Symmetric Chess, our featured variant for March, 2024.


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

Comments/Ratings for a Single Item

LatestLater Reverse Order EarlierEarliest
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, Jan 8, 2021 09:13 PM UTC in reply to Daniel Zacharias from 07:38 PM:

Strange. Promotion in my Mighty-Lion test preset (which, apart from the tables, uses the same code) still works fine. But this doesn't have an option to defer.

I have the feeling something changed in the implementation of the GAME-code askpromote command that broke it. I notice several things:

  • In Mighty Lion the button at the bottom has the inscription 'Play', in the screen at your link it is blank.
  • Above the Pawn there is a message that says it declines promotion. I don't recall having seen that before.
  • After you make the choice and submit it through the button, it seems the original move is gone. The askpromote screen is supposed to append the choice to the move you had so far, in the form "; X-dest" (where X is the label of the chosen piece). But here it seems to replace the move by that, so that this now becomes the only move primitive. Which is of course invalid.

 


Daniel Zacharias wrote on Fri, Jan 8, 2021 07:38 PM UTC:

Something seems to be wrong with this game. When I declined to promote my pawn, the promotion options keep showing up for both players. I did have to modify the promotion options from the generated code to get them the way I wanted, but it all seemed to be working before.

https://www.chessvariants.com/play/pbm/play.php?game=Expanded+Chess&log=arx-cvgameroom-2020-345-802


💡📝H. G. Muller wrote on Fri, Jan 8, 2021 11:03 AM UTC in reply to H. G. Muller from Thu Jan 7 03:24 PM:

I am in fact more worried that it is possible to one-sidedly end a game as a draw by entering a drawn command. Wouldn't it be better to treat that command as a draw offer, requiring that both players must enter it (in subsequent turns) before it gets executed? I can define a 'constant' lastDrawOffer, initialized to -2, which would remember the turn number where a drawn command was last received, and then only execute it when the previous value was one lower. If we want to stick to FIDE rules, the 50-move and 3-fold-repeat conditions could automatically submit the offer at the turn where it occurs, so that either player can claim, rather than immediately adjudicating the game.


💡📝H. G. Muller wrote on Thu, Jan 7, 2021 03:24 PM UTC in reply to Greg Strong from 03:12 PM:

No, they aren't. Are automated presets supposed to do that? If so, how?


Greg Strong wrote on Thu, Jan 7, 2021 03:12 PM UTC in reply to H. G. Muller from 11:20 AM:

Are the generated presets supposed to declare check? If so, it doesn't seem to be working:

https://www.chessvariants.com/play/pbm/play.php?game=Janus+Kamil+Chess&log=mageofmaple-cvgameroom-2020-354-836


💡📝H. G. Muller wrote on Thu, Jan 7, 2021 11:20 AM UTC in reply to Jean-Louis Cazaux from Tue Jan 5 10:08 PM:

The interpretation of 'passing through check' is usually based on the King move not being atomic, but having to be broken down into a sequence of intermediate positions. Where each of the intermediate positions then would also have to be legal as a final position. (Note that is an independent issue from not being allowed to move out of check, which doesn't need any intermediate position, but puts a condition on the postion after a turn pass.)

Metamachy is unusual in this respect, as legality of the initial King move also depends 'attacks' on squares that the King can never visit as an intermediate step, because these squares are already occupied by another piece.


Jean-Louis Cazaux wrote on Tue, Jan 5, 2021 10:08 PM UTC in reply to Daniel Zacharias from 09:45 PM:

OK, I see the point. Thanks


Jean-Louis Cazaux wrote on Tue, Jan 5, 2021 09:55 PM UTC in reply to Daniel Zacharias from 08:18 PM:

Daniel, formally you are right. Nothing in the Spanish text specifies if the King could leap while in check, nor if he could fly over threatened squares (at Grant Acedrex). However, it can be extrapolated that it was the case by comparison with the rules played at (standard) lepchess as reported in other contemporary sources. Allowing that King's jump to escape a check would be anachronistic in my opinion.


Daniel Zacharias wrote on Tue, Jan 5, 2021 09:45 PM UTC in reply to Jean-Louis Cazaux from 09:35 PM:

I think what H. G. Muller meant by that was that the play-test applet treats the king's castling move as if en passant applied for the purpose of checking whether the king would pass through check or not, and this can't be extended to leaping.

It's a limitation of the way the applet works, not a misunderstanding of the rules.


Jean-Louis Cazaux wrote on Tue, Jan 5, 2021 09:35 PM UTC in reply to H. G. Muller from 07:21 PM:

As far as Metamachy is concerned, you guys loose me. I don't understand what you say "And the jumped-over piece would then block its protector from moving to the e.p. square to make the capture".

There is nothing exceptional with the King's jump in Metamachy. It is simply to adopt the rule that was in force at chess in several places in the Middle Ages, before castling was adopted. Basically, the King was allowed an initial 2-square away move, including horse's leap, providing he was not in check and he was not passing over a square where he could have been checked. The same idea is still applied for castling, the King must not go over a square under threat either. Castling is a particular case of the King's jump. Plus, of course, the fact that castling gathered two consecutive moves in one, 1) bringing the Rook close to the King, 2) the King jumping over the Rook. That is the true evolution that led to our modern castling.


Bn Em wrote on Tue, Jan 5, 2021 08:35 PM UTC in reply to H. G. Muller from 07:21 PM:

Or we could introduce a special XBetza notation for virgin moves that cannot be played when in check

If that's the chosen option, it seems like it'd make sense to expand it to any move that can't be made while in check — see, for instance, David Cannon's Lemniscate Chess where a checked king can't move at all. (That variant in particular is probably well out of scope for the applet, but similar rules are concievable for other more mobile kings as an alternative to excluding movement through check)


Daniel Zacharias wrote on Tue, Jan 5, 2021 08:18 PM UTC in reply to H. G. Muller from 07:21 PM:

I think the Grande Acedrex king might be an exception to that. I can't find any rules for that game that mention such a restriction.


Greg Strong wrote on Tue, Jan 5, 2021 07:25 PM UTC in reply to H. G. Muller from 07:21 PM:

Ah, ok. I think it is safe to apply to all moves that are both xbetza 'i' moves and of pieces that are royal. I can't think of any exceptions.


💡📝H. G. Muller wrote on Tue, Jan 5, 2021 07:21 PM UTC in reply to Greg Strong from 04:27 PM:

With 'initial move' I did not mean just the first time the piece was moved, but a move that would only be allowed when the piece is still virgin (XBetza i). Pawns can definitely not be e.p. captured on their starting square, after their double push, so I treated this more as a property of castling than as a consequence of the virgin-only requirement. But if other royal initial moves (such as the Knight jump in Chaturanga or Ouk, or the Alibaba move in Grant Acedrex) are forbidden when in check, I could make it the default behavior for all i moves of a royal.

If it is not universal, it would have to be configurable, and there are several aspects to that: Interactive Diagram (AI), Play-Test Applet (interface), GAME code. Or we could introduce a special XBetza notation for virgin moves that cannot be played when in check.

Metamachy is a bit exceptional anyway: the ban on the King's virgin moves there cannot be explained in terms of e.p. capture, as you are also not allowed to jump over protected enemy pieces with them. And the jumped-over piece would then block its protector from moving to the e.p. square to make the capture.


Daniel Zacharias wrote on Tue, Jan 5, 2021 04:51 PM UTC in reply to H. G. Muller from 03:48 PM:

I think it should be possible, even if it's not universal. In Metamachy, and some others, the king has an initial jump, but cannot use it to escape check


Greg Strong wrote on Tue, Jan 5, 2021 04:27 PM UTC in reply to H. G. Muller from 03:48 PM:

A royal could make a normal step to avoid get out of check on its first move. The royal queen in Cassia Britania could slide out of check. So it doesn't seem this is universally valid. But, it is probably safe to consider it for any initial move that changes the location of a second piece.


💡📝H. G. Muller wrote on Tue, Jan 5, 2021 03:48 PM UTC in reply to Daniel Zacharias from 05:46 AM:

The passing-through-slider-check should be fixed now. (For accepting the move. It is still highlighted. And it still gives this strange error message when you try it illegally.)

If castling were working, would that also mean a king would be unable to make an initial leap to escape check?

This is not an automatic rule. Should it be one? I could designate the origin of an initial move by a royal always an e.p. square, and that would then enforce this rule. But I don't know if the rule is universally valid.


Daniel Zacharias wrote on Tue, Jan 5, 2021 05:46 AM UTC in reply to H. G. Muller from Mon Jan 4 09:16 PM:

If castling were working, would that also mean a king would be unable to make an initial leap to escape check?


💡📝H. G. Muller wrote on Mon, Jan 4, 2021 09:16 PM UTC in reply to Daniel Zacharias from 05:02 PM:

Indeed, I still have to do some more work on this. The current code only works when the attacked square is at the end of the attacker's range, which is always true for leapers, and true for sliders when castling occurs on the back rank. But not when it occurs on 2nd rank.

I treat the 'passing through check' rule as e.p. capture of the King. So castling, but also sliding royals like in Caissa Brittania set an entire series of e.p. squares along their path. (Where castling is special, as even the origin is an e.p. square there.) When such e.p. squares are created by the move of a royal piece, any normal capture will also be allowed to e.p. capture (and hence make the previous move illegal in variants that have the checking rule). But this only works when sliders, which normally can only capture someting at the furthest square of their range, must test for e.p. capture on all squares en route to that too, to detect whether their path intersects the ray of e.p. squares. I did not do that yet. (So Caissa Brittania would also not work, had it been automated through the Applet.)


Daniel Zacharias wrote on Mon, Jan 4, 2021 05:02 PM UTC in reply to H. G. Muller from Sun Jan 3 07:08 PM:

https://www.chessvariants.com/play/pbm/play.php?game=Expanded+Chess&settings=expanded-test

I tried castling through check in this preset, and sometimes it was stopped with that same error, but sometimes it was allowed. It seemed to depend on which square was attacked and which piece was attacking, and also whether the king was in check already or not.

When a purely leaping piece was threatening one of the squares the king would pass through, the error occurred. When a diagonal slider could reach the square directly beside the king, castling was allowed.

When a white bishop threatened h9, the black king did not have the option to castle, but when the king was also in check, castling was marked as legal and produced the error as before.


💡📝H. G. Muller wrote on Sun, Jan 3, 2021 07:08 PM UTC in reply to Greg Strong from 06:44 PM:

Ah yes. I am afraid that testing castling legality for moving through check is still on the to-do list. I suppose all I have to do is set the e.p. squares to all the squares the King moved through.

[Edit] I did that now, and although the castling is still highlighted, it will not be accepted when the King starts in, or passes through check. The error message it gives in that case is strange, though, and I do not understand how it can be given:

     hit2=1

     Trading of this piece is not allowed

This is generated by GAME code:

print . hit2= #hit;
  if == #hit Xdummy:               // the 'royal' was actually a banned trade
    die "Trading of this piece is not allowed";
  elseif #checkrule and #hit:      // he can and we care
    die "This exposes your royal piece to capture";
  endif;


As the preceding print shows that #hit contains 1 here, how can it compare as equal to the constant string Xdummy???


Greg Strong wrote on Sun, Jan 3, 2021 06:44 PM UTC in reply to H. G. Muller from Sat Jan 2 08:16 AM:

This doesn't seem right - in this position, it is letting me castle through the square being attacked by white's camel.

https://www.chessvariants.com/play/pbm/play.php?game=Janus+Kamil+Chess&log=mageofmaple-cvgameroom-2020-354-836&userid=mageofmaple


💡📝H. G. Muller wrote on Sat, Jan 2, 2021 08:16 AM UTC:

This is generated by an include file that contains the code

  set sqrs explode chr 45 trim elem dec #i #parts;   // split last part at hyphen
  if != 2 count #sqrs:                               // must give 2 squares
print . count= count #sqrs;
print thismove;
    if == resign thismove:
print ok;
      resign;
    elseif == drawn thismove:
print notok;
      drawn;
    endif;
print giveup;
    die "board step does not mention two squares";
  endif;
print survived;


in its ParseMove routine. So for normal move primitives (i.e. containing a hyphen) is directly skips to the 'print survived'. On receiving 'resign' it correctly reaches the 'print ok', and aborts ParseMove, so that it never reaches the die or 'print survived'. But it continues execution of the GAME code at the caller of ParseMove (HandleMove in the Pre-Move code), which eventually leads to the later die when it chokes on 'resign'.


Greg Strong wrote on Sat, Jan 2, 2021 02:30 AM UTC in reply to Fergus Duniho from 01:17 AM:

If it helps, here's the log I'm trying to resign in:

https://www.chessvariants.com/play/pbm/play.php?game=Kinglet&log=mageofmaple-cvgameroom-2020-357-122&userid=mageofmaple

The resign command now gives me a long list of "survived"s followed by:

count=1

resign

ok

resign is not even pseudo-legal for a R


🕸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

LatestLater Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.