Comments/Ratings for a Single Item
Generated-code games are now giving an error saying "You may not set $extralegal with setsystem."
💡📝H. G. Muller wrote on 2022-11-16 UTCDaniel Zacharias wrote on 2022-11-16 UTC
https://www.chessvariants.com/play/pbm/play.php?game=Skica&log=sissa-arx-2022-289-168
We're having a problem with this game. On move 17, the pawn on g6 is captured when it shouldn't be. This seems to happen no matter what move white makes.
Should be fixed now. Turned out e.p. squares were never cleared until another double push was made. Apparently g8-g6 had been the latest double-push, so when a Pawn then captured to g7... Amazing that no one ran into this problem before.
https://www.chessvariants.com/play/pbm/play.php?game=Skica&log=sissa-arx-2022-289-168
We're having a problem with this game. On move 17, the pawn on g6 is captured when it shouldn't be. This seems to happen no matter what move white makes.
Some time ago I tried using the game code wizard to make a preset for a large (18x18) game using a few crooked sliding pieces. Now I notice that one of them, the Hornet from Seenschach, works in the applet but not in the generated code. The way I defined it was Wafs(alar)7Wafsal(aral)7WzB. Part of the move works, but the zB seems to be ignored, even though the generated code appears to include those moves as well.
💡📝H. G. Muller wrote on 2022-08-06 UTCI am not sure that this is feasible. Alice Chess is basically a 3-dimensional variant (with 2 levels), where all pieces have two-leg moves where the seccond leg changes level, and which are lame or (locust-)capturing by their orthodox move in the first leg. But the code in the include file used by the wizard assumes 2-dimensional boards.
Of course you can map the 3d board onto a wider 2d board (16x8, or perhaps 18x8 to allow a dead zone in between the boards that even Knights cannot cross, deleting the squares in that guard zone from the board in the Pre-Game code). And then define all moves as 2-leg moves that have a (dx, dy) = (+-18, 0) leap as second leg. There is no way to describe that in Betza notation, so the Interactive Diagram could not be used to generate the legdefs array with move definitions. But you could of course write that by hand. Either from scratch, or by adapting the code generated for orthodox chess, adding a second leg to each move. E.g. the Bishop in orthodox Chess would have
1 99 1 1 3 // bishop(104) 1 99 1 -1 3 1 99 -1 -1 3 1 99 -1 1 3 0
and this would have to be changed to
2 99 1 1 3 // bishop(???) 1 18 0 1 2 99 1 -1 3 1 18 0 1 2 99 -1 -1 3 1 18 0 1 2 99 -1 1 3 1 18 0 1 2 99 1 1 3 1 -18 0 1 2 99 1 -1 3 1 -18 0 1 2 99 -1 -1 3 1 -18 0 1 2 99 -1 1 3 1 -18 0 1 0
And you would have to determine the new starting index for Bishop in this array, and put it into the B and b function definitions instead of 104.
I am not sure whether this would have the desired effect for castlings and e.p. captures, though. (Or indeed how the latter are supposed to work in Alice Chess in the first place.)
What would be a good method (if there is one) to use this to make Alice Chess?
💡📝H. G. Muller wrote on 2022-07-20 UTCIndeed. There is no need to generate anything else there than the castlings. And for castlings the code would know that you cannot do those while in check anyway. So you can simply return the index of the castling moves in legdefs in the second case.
it is not necessary to build the in-check dependence into the move list of the King that is used when the argumet to the K or k function is 0.
I don't understand this part. Is it about the number at the end of the K definition? I had the checked check there because the normal King move (with castling and leaping) had different numbers.
💡📝H. G. Muller wrote on 2022-07-18 UTCFor now I have solved this as follows: when a move is indicated as an initial one, it will still be rejected if the mover is not virgin. But if it is, it will be tested whether the mover is in an array inocheck, which by default is set to (K k). If it is, this will add the origin of the move to the set of e.p. squares. And hence consider it illegal if that square is under attack after the move. If you want to forbid any other piece to use inital moves when attacked, or when your royal does not have the label K, or you have multiple royal types, you could set the inocheck array to contain the types you desire.
As dicussed this can in theory fail in the presence of hoppers. Although it is extremely unlikely that you would ever want to play an initial move designed to get you to safety to stay in the path of a hopper. Anyway, it seems to solve the problem with the game you mentioned, as this now says 'checkmate!' above the board. It is also not possible to have both initial moves that can, and that cannot move out of check on the same piece.
About your implementation of that preset: it is not necessary to build the in-check dependence into the move list of the King that is used when the argumet to the K or k function is 0. This call only has to generate moves with an implied side effect, i.e. a change of the board state not explicitly expressed in the move eneterd by the user. This is used when playing out the moves of the game for the purpose of setting up the current position, to make sure the side effects are properly applied, but where there is no need for testing the (pseudo-)legality of the moves. As this would presumably have been done before the move was allowed to be appended to the game. Normally the only moves that do have side effects are e.p. capture and castling. So there is no need to generate other initial King moves than castling in that case; the extra moves you defined do not have side effects.
Thank you. At first I thought I could just override GameEnd and have it check for check before mate, but then it was announcing Check! every move.
This e.p. trick for detecting moving out of check after the fact unfortunately does not work in general
If I understand this correctly, it should work as long as the game doesn't include hoppers. It does seem reasonable to assume that King cannot normally make special moves to escape check.
Is there a way I could add en passant to a leaping move?
Edit I found another solution that seems to work—setting checked to 1 before GameEnd both post game sections.
💡📝H. G. Muller wrote on 2022-07-16 UTCYou cannot use the variable 'checked' the way your code does (in the functions K and k), because the betza.txt include file does the mate test before the check test (which sets this variable). As a result the variable 'checked' is undefined during the mate test, which apparantly is interpreted as not being in check. So the mate test thinks the King, still in its initial position, can use its initial jumps to escape the check, and hence does not see it as mate.
There currently isn't a good alternative. Perhaps all initial moves of a royal piece should be forbidden when in check. Castling is forbidden when in check, but this is implemented as a property of the castling rather than of the fact that it is defined as an initial move. The mechanism by which this is implemented is that castling creates e.p. squares along the path of the King, including the starting square. And that any move to an e.p. square will always (locust-)capture the royal piece, if that was the last-moved piece. (Otherwise only e.p.-capable pieces would perform the capture.) So what really should happen here is that the initial King moves create an e.p. square on the original King location.
[Edit] This e.p. trick for detecting moving out of check after the fact unfortunately does not work in general: a King could make a leap towards a hopper, and therby activate the hopper for capture to the square it just left. While it would not have been in check by that hopper if it had stayed there. For castlings this cannot happen, as there will also be a Rook in between King origin and any piece that would be standing outside of the Rook. Although a bent hopper might be activated by the Rook. An enemy Grasshopper outside of the Rook would attack the Rook after castling, which could lead to the accusation of having castled through check. Or, when the King would end next to the Rook's original square, to moving through check on its destination square, which would no longer be checked after the castling.
In this game which uses generated game code, it seems like there's a problem with detecting checkmate. If I try playing T f5-d8, it's only check, even though black has no legal moves.
I'm having some problems with this game. First, I can't seem to get the piece images to show correctly. Right now it looks ok at first, but when viewing a game from black's perspective it's all wrong again.
Because you're using the Alfaerie:Many set, which includes some flipped pieces, you need to include a value for $flipped. Since you are not using any flipped pieces in your game, you should set it to the same value as you are setting $pieces to.
💡📝H. G. Muller wrote on 2022-01-18 UTCThat would be too bad. But I don't think anyone but Fergus can fix bugs in Game Courier or the GAME code interpreter.
💡📝H. G. Muller wrote on 2022-01-15 UTCThis error is weird: the error message obviously comes from the GAME code used to automate the preset, from the move parser. But it seems thise is called in an unexpected context: Game Courier tries to feed the game history to the code in the Post-Move sections twice. And the second time the position has already been changed from the initial one to some weird one, which indeed has a Z on g4.
For debugging I added a statement
printr $space
at the end of the Pre-Game section. When I then use the preset in Play mode, and play the given game, the page that complains about the error contains two dumps of the $space array. The first is the initial position (as expected), but the second is
Array
(
[a12] => d
[b12] => l
[c12] => u
[d12] => z
[e12] => o
[f12] => q
[g12] => k
[h12] => o
[i12] => z
[j12] => u
[k12] => l
[l12] => d
[a11] => r
[b11] => m
[c11] => n
[d11] => b
[e11] => a
[f11] => y
[g11] => y
[h11] => a
[i11] => b
[j11] => n
[k11] => m
[l11] => r
[a10] => x
[b10] => i
[c10] => e
[d10] => g
[e10] => s
[f10] => c
[g10] => c
[h10] => s
[i10] => g
[j10] => e
[k10] => i
[l10] => x
[a9] => p
[b9] => p
[c9] => p
[d9] => p
[e9] => p
[f9] => p
[g9] => @
[h9] => p
[i9] => p
[j9] => p
[k9] => p
[l9] => p
[a8] => @
[b8] => @
[c8] => @
[d8] => @
[e8] => @
[f8] => @
[g8] => @
[h8] => @
[i8] => @
[j8] => @
[k8] => @
[l8] => @
[a7] => @
[b7] => @
[c7] => @
[d7] => @
[e7] => @
[f7] => @
[g7] => p
[h7] => @
[i7] => @
[j7] => @
[k7] => @
[l7] => @
[a6] => @
[b6] => @
[c6] => P
[d6] => @
[e6] => @
[f6] => @
[g6] => P
[h6] => @
[i6] => @
[j6] => @
[k6] => @
[l6] => @
[a5] => @
[b5] => @
[c5] => @
[d5] => @
[e5] => A
[f5] => P
[g5] => @
[h5] => @
[i5] => @
[j5] => @
[k5] => @
[l5] => @
[a4] => P
[b4] => P
[c4] => @
[d4] => P
[e4] => P
[f4] => @
[g4] => Z
[h4] => P
[i4] => P
[j4] => P
[k4] => P
[l4] => P
[a3] => X
[b3] => I
[c3] => E
[d3] => G
[e3] => S
[f3] => C
[g3] => C
[h3] => S
[i3] => G
[j3] => E
[k3] => I
[l3] => X
[a2] => R
[b2] => M
[c2] => N
[d2] => @
[e2] => A
[f2] => Y
[g2] => Y
[h2] => A
[i2] => B
[j2] => N
[k2] => M
[l2] => R
[a1] => D
[b1] => L
[c1] => U
[d1] => Z
[e1] => O
[f1] => Q
[g1] => K
[h1] => O
[i1] => @
[j1] => U
[k1] => L
[l1] => D
)
This is neither the initial nor the current position, although it does have some characteristics of the current position.
Perhaps Fergus can shed some light on how the Pre-Game section could be executed twice when entering a single move in Play mode.
I'm having some problems with this game. First, I can't seem to get the piece images to show correctly. Right now it looks ok at first, but when viewing a game from black's perspective it's all wrong again.
Second, there's this error
ILLEGAL: P g4-g6 on turn 1:
There was no P on g4. The piece on g4 is a Z.
Go back with your browser's BACK button, reload the page, and try again.
For diagnostic purposes, here is the full movelist:
1. P g4-g6
1... p g9-g7
2. Z i1-g4
2... a e11-i7
3. P f4-f5
3... a i7-d2; q-dest
4. A h2-e5
4... q d2-i7
5. P c4-c6
5... q i7-i3 // - check! -
6. E j3-i3I have no idea what I did wrong
💡📝H. G. Muller wrote on 2021-05-28 UTCThe betza.txt include file for GAME code generated by the Play-Test Applet now also supports crooked and circular pieces (in general 'custom trajectories'). Even in combination with a p or g modifier.
I just turned on the group write bit for the file. Try it again.
💡📝H. G. Muller wrote on 2021-05-27 UTCI tried to update the betza.txt GAME-code include file, but I get this error message:
Upload of /home/chessvariants/public_html/membergraphics/MSgame-code-generation/betza.txt was allowed but failed! The cause of failure is unknown.
Just to be sure: I can use the word 'resign' as a string literal expression > operand without it being confused for a command? Like
if == resign thismove: resign endif;
Yes, but you should include a semicolon after the second line. Without it, this code would result in an error.
💡📝H. G. Muller wrote on 2020-12-30 UTCJust to be sure: I can use the word 'resign' as a string literal expression operand without it being confused for a command? Like
if == resign thismove: resign endif;
?
💡📝H. G. Muller wrote on 2020-12-28 UTCOK, thanks. This will make life easier, as indeed I would otherwise have had to break from several levels of subroutines.
Some explanation: the error message was from my own parsing routine. My code works by comparing the input move to all legal moves generated in the position before the move, and it needs a complete description of the move to do that. (Not only the basic move, but also optional freedrops or suicides that occur as (possibly mandatory) side effects.) So I don't rely on move parsing as it occurs when you feed a move primitive to GC through a MOVE: prefix, as this would also change the position, but wrote my own parser that extracts all square coordinates and piece labels from all primitives. Which again is called from another 'do everything' subroutine so that users only have to put a single subroutine call in the Post-Move sections. So if the parser doesn't see a hyphen in a move primitive, it exits through die without any of the primitives having been fed to GC.
25 comments displayed
Permalink to the exact comments currently displayed.
That's now fixed. I changed the line
setsystem extralegal #xtl;in betza.txt tosetsystem legalmoves merge $legalmoves #xtl;. Since$extralegaldid not appear in any individual presets using this include file, nothing more needed to be done.