Comments by HGMuller
OK, I changed the shuffle.txt file accordingly. Perhaps Aurelian can try whether the problem is now solved.
Pretty amazing that this did not appear to cause any problems in Play mode.
Yes, it is from the GAME code. But is seems the GAME code is right about this: Daniel says below that the initial position is all wrong, and indeed contains no royal.
This is a shuffle game, so it calls the general shuffle code in the Pre-Game section. This performs the shuffling, and stores the result in a constant. So that later invocations of the preset will use that same shuffle. A new shuffle is only made when the constant is not defined. This works fine in Play mode.
Can it be that the constant for remembering the initial position gets corrupted when an invitation is accepted?
For reference, below is the basic principle of the shuffling, by the routine ShuffleSetup called from the Pre-Game code:
sub ShuffleSetup: // performs the shuffles described in the above arrays if isconst startshuffle: // shuffle has already been determined setsystem space startshuffle; // retrieve it else: // new game; must shuffle ... // shuffle the initial setup in $space setconst startshuffle $space; // save the shuffle for persistent use endif; endsub;
Doesn't the fact that the code work perfectly in Play mode prove that the problem is not in this code, then?
I have no way to debug other code than what the one the user can provide. As far as I understand GC the only way that after accepting an invitation GC declares a loss would be when the GAME-code executes a resign command without getting any input. I am pretty sure my code doesn't do that. It definitely does not do that when you press Play in the preset menu. How does what happens when pressing Play differ from accepting an invitation?
From the description (both here and of the Sliding General), shouldn't it be a three‐path lame dabbabah?
Well, the description was KtfsF, so I assumed a W as second step was out.
Another enhancement I had considered was to just add the Wazir move to the existing Griffon pattern.
That was the first thing that came to my mind as well, but I was afraid this would make it too strong. IIRC the value for the Griffon I measured was 8.2, and 4 extra moves easily up the value by 2 Pawns, even for a Rook. Just bending a trajectory in another shape is more like adding extra squares at the end of the trajectory: all the normal Griffon move now become more easily blocked. This should partly compensate the effect.
The inequality here doesn't seem to be worse than that between Betza's classical CwDA armies, which can run up to 1.5 Pawn. An Archbishop is only about 0.75 Pawn weaker than a Queen. The KNAD is worth about 1.5 Pawn more than a Queen, but the distant moves here are all lame, which might weaken it more than that. The Griffon is the weakest of the bunch. A possible enhancement of it could be a W-then-R that turns a 90-degree corner, which has a similar move pattern, but also attacks the W squares.
Even if the strengths vary a lot, there is of course no need to play the strongest against the weakest. Or only reserve that for games between players of unequal strength, as a sort of handicap.
Note that the Betza notation used in the article (e.g. FtR) is non-standard, neither original Betza (t[F,R]) nor XBetza (FyafsF). As a consequence it is not entirely clear to me how the Lion moves. I suspect it is the compount of a King, a Xiangqi Elephant, a Xiangqi Horse and a two-path lame Dabbabah (XBetza KaFafsW).
Some additional info: the preset is automated through code generated by the Play-Test Applet, but in 'Play' mode this code appears to work fine. In particular there is no spurious declaration of game end by the Post-Game code sections. I don't know whether it is possible that the provided GAME-code would use a variable name that is also in use by Game Courier for other purposes, and confuses the system.
Well, because of the acclamation then:
Oppulent Chess
OK, I added those to the list.
Some time ago I slimmed down the Quiescence Search of the diagram's AI, because in large variants with many powerful pieces it was still prone to search explosion. (It now unconditionally searches only Low x High captures that capture the last-moved piece, or punish moving away a (soft-)pinned piece; other captures need to consume part of any remaining depth budget.) Because of this diagrams that used impractically long thinking time might now perform acceptably. For instance, after this change I had no problems having the Diagram play Macadamia Shogi against Ai Ai. (But I still don't want to add Macadamia Shogi to the list, because it is not possible to enter the triple capture of the Lion Dog. Even though in practice there probably will never be an opportunity to make such a capture.)
Since this comment is for a page that has not been published yet, you must be signed in to read it.
I think you have to submit drawn as a move. In a rule-enforcing preset you have to make sure the preset would accept that GAME-code command.
As Pritchard once wrote: "it only takes 10 seconds to invent a new chess variant, and unfortunately some people do". We can now extend this thesis with: "it takes only 10 seconds to submit a CVP article, and unfortunately some people do"...
When Cannon captures the Rhino, the text "I win!" appears. But it's not a checkmate situation at all. What error is this?
When you do not explicitly specify a royal piece through a parameter royal=N, the diagram assumes the last piece in the list is the royal one. In this case that is the Rhino. By default the diagram assumes extinction royalty. So when the diagram captures the second Rhino, it assumes it won the game.
Either re-order your piece lines in the diagram definition so that the King is last, or add a line royal=8.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
I think we will need Fergus' help for this. When I use the preset in Play mode it doesn't declare game end during the first few moves. I think that proves that the Post-Game code cannot be responsible for the observed termination.
All I can say is that when I use the link you last gave (with FireFox, or the Android browser on my tablet), and select 'Play' from the menu, I get a different start position as what was initially shown. And when I then go back to the previous page, and press Play again, I get yet another setup. And it gets shuffled in the way that was specified. So the preset appears to be OK.
Perhaps others could try to see if they have the same experience.
It does shuffle for me. What I meant is that you gave two links, to different presets, in this comments topic, and that these use different piece IDs.
Sure, you are welcome to use them. As far as I am concerned, they are public domain. I am happy you like them.
I did.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
You had not given me that link before, so I was looking at another preset. In this new one you forgot the closing parenthesis (and semi-colon) of the shufflespecs array.
Well, I did not see it in the preset (link you gave earlier in this comment thread).
And no, that is not supposed to work, because it seems to use other piece IDs than the preset.
When you try what? I see no change in the preset.
BTW, the GAME-code generation should now also work properly when all pieces in a shuffle groep have a colon prefix.
Ah, I did not really look at the Diagram, just at the preset. You can just add the fourth group to the shufflespecs array, as another triplet. You have to put one piece (e.g. Bishop) in the first element of the triplet, and all the others in the second.
I took your Diagram definition from the page source of your article, and pasted it into the Play-Test Applet to generate GAME code. Indeed it turned out that the two groups for which you wanted symmetric shuffling were not put into the shufflespecs array. The reason appears to be that you put the colon (:) to request symmetric shuffling on all pieces of the group. The GAME-code generation apparently cannot handle that. And I never noticed that, because I tend to mark all the pieces but one with a colon. The last piece then must be placed symmetrically as well, as the only open spaces that are left will be symmetrically positioned. If I removed the colon on one of the pieces in each group in the Diagram's shuffle parameter
shuffle=:B:N:EF,QUT,DI,:LY
then the GAME code gets properly generated:
set shufflespecs ( (F) // shuffleset (B N E) // symmetrized 0 (Q T U) // shuffleset 0 0 (D I) // shuffleset 0 0 (Y) // shuffleset (L) // symmetrized 0 0 // mirror to get black );
(beware the Diagram uses other piece IDs than your preset!). I will fix the JavaScript for GAME-code generation in the Play-Test Applet such that it can also handle the case where all pieces in a shuffle group have a colon prefix. (As the Diagram itself doesn't seem to have any trouble with that.)
25 comments displayed
Permalink to the exact comments currently displayed.
This is a preset where the piece images are redefined through assignment to the system variable $pieces, at the end of the Pre-Game section. Apparently the image displayed on the page is generated before this assignment is processed.