Comments/Ratings for a Single Item
Okay. The preset is now correctly shuffling the different setups. However, the bishops conversion rule is not working properly.
I'm testing two presets:
The conversion rule is failing on both.
I edited the #1 recently from the source code corresponding to the interactive diagram that HG inserted on the page that shows the game rules.
I edited the #2 several years ago directly from the Play-test applet.
Now then,
the #1 says in the Post-Move 1:
gosub HandleMove false;
and in the Post-Move 2:
gosub HandleMove true;
while the #2 says in the post-Move 1:
gosub HandleMove false;
if == B #mover and not flag #ori:
set wstart cond checkleap #ori #desti 0 1 1 2;
endif;
and in the Post-Move 2:
gosub HandleMove true;
if == b #mover and not flag #ori:
set bstart cond checkleap #ori #desti 0 1 1 2;
endif;
How and why did this difference arise? Why does the conversion rule fail on both presets?
Whenever you try to establish a new setup, the same position appears, which clearly indicates that the shuffle function is not actually working.
The problem was with my new code. I had to begin the for loop at 0 instead of 1, and that fixed it.
Whenever you try to establish a new setup, the same position appears, which clearly indicates that the shuffle function is not actually working.

OK, I changed it to simply use this new 'shuffle #dark' (and similarly in 3 other place), and now Carlos' preset appears to work again.
Since I did not change anything to the shuffle.txt include file for ages, it is likely that it stopped working because Fergus changed something.
I don't see any include file by that name.
Do you have any idea why the GAME-code line
eval merge #dark "shuffle"; // to shuffle all the remaining
This is using the eval command to turn the result of the expression merge #dark "shuffle"
into a command. In test code that just assigns this to a variable, I get a copy of the #dark array without the keyword shuffle in the array. I suppose the intention was to pass the contents of the #dark array as arguments to the shuffle command, as it would not take an array as an argument.
The word shuffle was placed in quotation marks to prevent it from being evaluated as a function, but it appears this no longer works. When I tried the spelling shuphle, merge returned an array that included the word. While putting it in quotation makes did not work, this code did work:
eval merge #dark join "shuf" "fle";
Using some recent changes to the language, this code would also work:
shuffle {list #dark};
And I have now modified the shuffle command so that this works:
shuffle #dark;

Since I did not change anything to the shuffle.txt include file for ages, it is likely that it stopped working because Fergus changed something. So
@Fergus:
Do you have any idea why the GAME-code line
eval merge #dark "shuffle"; // to shuffle all the remaining
stopped working? It is so long ago I wrote this that I don't recall anymore what it was supposed to do, but I guess the merge operator was supposed to cook up a GAME-code statement 'shuffle ARRAYOFSQUARES', that should then be executed by the eval. In order to shuffle the pieces on those squares.
The error message in Carlos' preset:
h1 f1 b1 g1 e1 c1 a1 is not a valid expression
suggests that the second operand (the literal string "shuffle") is somehow ignored.
@HG
I need your help to fix this preset that was coded using the Play-test applet: Cetina Random Chess. Originally it was fine but something happened that ruined it. The software warns:
Syntax Error on line 977h1 f1 b1 g1 e1 c1 a1 is not a valid expression, because h1 is not a recognized piece, coordinate, command, or subroutine.
Thank you before hand for your attention.
Thank you!

This is indeed something that cannot be done through the Applet, but which can be specified in the HTML for an Interactive Diagram. With the promoChoice parameter you can specify several 'promotion sets', separated by slashes. For each piece that promotes you can then specify a morph parameter to indicate where it promotes, and a digit 1-9 would indicate which of the extra promotion sets should be offered as choice there. (For the first set the square in the morph value should be set to *.)
In this Play-test applet I haven't found out how to promote multiple pieces to different promotions. How would an HTML-Code for Variants such as Shogi look like?

Is that possible?
I am afraid not. The applet serves two purposes: act as an 'electronic chess board', where a single player (or a pair sitting before the same computer display) can see and manipulate the entire board, or to play against an AI. But the AI handles two-player zero-sum games with complete information. For games where (a different) part of the game state is hidden for each player, like in your variant, you would need a completely different type of AI. Conventional chess engines are completely useless for that.
This is an interesting page and I am still digesting the information. I was hoping to use this applet to test my chess variant. It is a version of dark chess combined with chess 960 influence.
I could not yet figure out whether I can use the applet the create the following version:
- Board size and pieces are as in regular chess.
- The starting position has only the pawns for both players.
- The first move is to place your pieces in the first (or last) rank in any order. (Unlike in chess 960, there are no restrictions whatsoever. You can even have two same colored bishops.)
- This is a version of dark chess. You can see only the part of the board that your pieces can "see". A piece can see all squares directly around it and all squares it could move to as if no own pieces would be in the way. That means that a queen can see in the 8 directions until its view is blocked by an enemy piece. (The enemy piece is seen, but not beyond.) Based on this definition a knight in the center can see the 16 squares. The king has special seeing ability. The king can see much more than other pieces. It can see everything a queen would see that is on a square a king can move to. Note that this does not imply that the king cannot move onto an attacked square. For example, if the white king is on E1, and black has a bishop on F3 and a knight on G4, the king cannot see the night. If other pieces of white cannot see the night either, then the white king may decide to move to F2 and be captured.
- The goal is to capture the king. No stalemate.
- No castling.
- No double pawn move or en passant.
- 50 move rule applies.
In the starting position you only see some of your opponents pawns as they block your view. This means you do not see where your opponent's king or other major pieces are when you start.
The two players see different parts of the board and so this is best suited for computer play (or two board and arbiter is needed), hence I hoped to model it with this applet.
Is that possible? Thanks a lot!
Please, tap here, use this to learn about
and sorry, but I’ll have no access to my laptop next several days.

Try to refresh the browser cache. I suspect you still have an old version of betza.js there, which still requires the deflection angle to be fully specified with directional modifiers (fs).
What is a Hexmaster?
What the rock is with bent riders? They bend on 90 degrees instead of 45!
And it is on my Windows laptop with Edge! while on iPhone with Safari it works fine...
how to encode Hexmaster to not earn too much lines of code for legs which go out from board and wich have no use but they exist to be unable to copy on phone for making Game Courier preset, so I used to use my laptop which fails to enable Oracle correctly?..
in other words, please shorten the notation of Hexmaster to match the 8x10 board.
Acording to the rules of the game, first white has to place it's two gating pieces behind. Then black his two. I got stuck while trying to do both move in the same turn. I have tried using continuemove, but I get into infinite loops no matter what I had done.
The only thing I am still in doubt about is whether the current betza.txt include file on which the PTA-generated code relies tests for a move being the final one in a safe and reliable way. Because it uses mln for the test rather than turn.
I have just added thismovenum and maxmovenum. These will return $mline[$mln]->movenum and $mline[$maxmln]->movenum. It's likely that maxmovenum will be returning the same value as movenum, which returns $movenum, but using it will add clarity to your code.
No matter I have made some progress!
It is definitely not that easy.
One thing is that when I try to make the move to a1 (for example), which would be an eligible brouhaha square I get an error saying that said move it is not even a pseudo legal move. By the way for now I have disabled the brouhaha squares and left the whole board intact (meaning no ----). But I could not comment the set brouhaha instruction in the pregame code.
Another thing is that the regular moves of all pieces are still displayed despite the fact that they are not legal anymore (i have setsystem the legalmoves array to () or even to null).

If I understood Fergus correctly all that is needed to do it is compare the value of turn instead of mln. Like
if == 1 turn: ... // code for first prelude step elseif == turn 2: ... // code for second prelude step else: gosub HandleMove true; ... // code for performing the gating if needed endif;
The only thing I am still in doubt about is whether the current betza.txt include file on which the PTA-generated code relies tests for a move being the final one in a safe and reliable way. Because it uses mln for the test rather than turn. But that would affect every preset automated through the PTA, and I have never encountered a case where it did not work.
@Fergus & @ H.G.
So basically it can't be done yet!
if == 0 $mline[$mln]->movenum:
That is mixing GAME Code with PHP. GAME Code does not support classes with properties or write out array elements with brackets, and it doesn't provide read access to $mline. But you can use the value of turn
with your knowledge of which side you're concerned with to determine where you are in a game.

OK, so the betza.txt code, which thus aims to test for whether the move is the one that was just entered, would work fine even in the presence of comments?
And the code to test for whether we are in prelude should look like
if == 0 $mline[$mln]->movenum:
?
25 comments displayed
Permalink to the exact comments currently displayed.
Fergus & HG:
I just checked a third preset called Cetran Chess 1 (which is essentially identical to the ones mentioned before) and it turns out to be working perfectly fine. This one has the following code in the Pre-Game section that those ones lack:
So there is no problem to solve anymore and therefore I am infinitely grateful to you both.