Comments/Ratings for a Single Item

OK, I see what the problem is. The diagram assumes by default that the symmetry is 'mirror', while I thought it would assume 'none'. When symmetry=mirror, when setting up the initial position it automatically places a black piece opposit to every white piece it places. So that you only have to specify the locations of the white pieces. This can overwrite any black piece it placed before. If the position was really symmetric, that would not matter, because it would be the same piece. But otherwise it depends on the order the pieces are placed which black pieces are overwritten, and which not.

The Applet should have included symmetry=none in the HTML description of the diagram when the 'asymmetric' checkbox is ticked, to suppress this behavior. I will make the Applet do that, but you can fix your existing diagram by just adding this line.

As for the castling: the default move for a King (as it is specified in the piece table) is KisO2 (or on wider boards KisO3 or KisO4). The isOn means castling with n King steps. I you don't want castling, the King would have to have just K as move. There is no non-castling King in the table, so you would have to alter its move. The Applet does allow you to alter the default move of a piece; for many pieces there even isn't a valid default move. E.g. I would not know how an Ox moves. (Perhaps there should be a separate non-castling King in the table, as this seems a case that would be frequently needed, just like there is also a shatranj Pawn without double push. But then I could not start with two Kings on the board, as they might be the wrong type of Kings...)

These are just some dummy messages for forcing Carlos' comment off the page. Problem is that his comment contains a link to the betza.js script without a ?nocache=true suffix, and it appears after the article. So the loading of the cached script this causes overwrites the updated script loaded in the article. Which contains a new feature essential for making the generation of GAME code work...

dummy 2

dummy 3

dummy 4

OK, thanks; issues of symmetry and castling have been fixed.

I have a question about labeling pieces: I see that 4 are prepended by a + sign [tokin, promoted lance, promoted knight and promoted silver], could the applet handle IDs prepended by an asterisk (*)?

The only thing the diagram uses the piece IDs for (apart from printing, for which they could be anything), is to check which promotions are allowed, by testing whether the ID occurs in promoChoice. When I wrote the code for that I imagined piece IDs would always be single characters, so I did not take the trouble to require any separator characters between piece names in promoChoice. E.g. for Chess I it would just be NBRQ . It just looks whether the piece ID is a sub-string of promoChoice. This is why multi-character Ids can give problems, expecially when mixed with single-character Ids. If all IDs were two characters, and they were separated by spaces (or whatever punctuation) in promoChoice, there would not be any problem. Only if the ID of one piece would be a sub-string of that of another it could be confused, and even then it is only a problem if you want to allow promotion to the long name, but not to the short name.

In Shogi variants promotion is usually controlled by promoOffset, which defines a fixed promoted form for each promotable piece. In that case promoChoice is ignored, and there never can be a problem, no matter what the piece IDs are. This is why the Shogi custom of indicating promoted pieces with a + prefix to the unpromoted ID is never harmful.

Using a * or ! as prefix in a piece ID is the most problematic of anything you could do, because these symbols have a special meaning in the promoChoice string: a *L there would mean you can promote to L, but only if you have an L in hand (usually because it was captured before). Other prefixes (e.g. #L) would probably be harmless, as long as you don't want to use them to distinguish an L from a #L, and want to allow choosing a #L but not an L.

Thanks for answering. Actually, I was only interested in what is related to printing, that is, how the movements are described and listed suitable to be read by anyone. I am not concerned if a pawn can not be promoted to a piece whose label includes a special sign.

I have noticed that currently, when copying and pasting the applet's HTML code into a webpage, only is displayed an empty board, piece images are not uploaded. Is this because of a bug? Or did you temporarily put a lock on it so that your work on the GAME code table-driven move generator is not affected?

The applet that I'm posting on Sac Chess, since several days ago I already had it stored in another point of the cyberspace.

Oops, my bad. Because we now have anti-aliased Alfaerie pieces on this website, I had changed the HTML for the diagram it prints to use those, instead of the old ones. But I forgot to change the graphicsType from gif to png.

This is fixed now. To fix it in diagrams you already made, just change 'gif' into 'png', and they should work.

OK, don't worry and thanks!

Checking Stalemate is a win doesn't seem to generate any extra stalemate code. Also, the stalemate options aren't mentioned on the interactive diagram page. I'm guessing I just need to add stalemate=win?

You have to press the 'Apply' button to make anything you changed above the diagram take effect. Then it would add stalemate=win. (In fact any setting other than draw would have the same effect.)

I suppose I could attach handlers to the checkboxes that trigger on a state change. But there are also text entries there, and for those it usually leads to trouble when you don't wait until the user is done typing.

The Diagram would not make the exception that stalemating with a lone King is a draw. But this seems a silly rule anyway. The only practical case I know where a bare King delivers stalemate is in defending against promotion of a Rook Pawn, preventing the supporting King to step away from the edge. But that only works if the strong side chooses to stalemate himsef by pushing the Pawn. You cannot force him to do that. The rule is as pointless as an extra rule that a checkmate in KNNK would count as a draw in orthoChess.

Here's a bug - the code it generates doesn't show any piece graphics. I think it is because the pieces have .png after the image name. When I remove the extensions, it works. I think maybe it is because it also includes graphicsType=png, maybe resulting in it looking for "pawn.png.png"?

Indeed. This crept in when I changed the diagram on the page from using the renderer (which requires the piece name without extension) to using the on-site PNG image files; the internal names used in the diagram already have the graphicsType extension on them, and when creating the HTML code for display I was just copying them from that table. I fixed it now.

The feature that allows you to dump the rules of the diagram as GAME code for creating rule-enforcing presets now seems to be at a stage where it could start to be useful. The code in the include file now would handle most CVs satisfactorily. Support of all the moves that can be described in XBetza and handled by the Interactive Diagram should be no problem, except for the Imitator. It now also tests for checkmate and stalemate, the 50-move rule, and repetitions. It can handle all the promotion rules that the Applet can be configured for. (I.e. piece-type-dependent zone depth, deferral, and promotion to captured pieces only.) Shuffling of pieces to get a start position also works.

There are some minor issues; testing for repetitions does ignore the virginity flags. The GAME-code implementation has a flag for every board square, but for any given CV most of the flags would be irrelevant, because the piece on that square (if any) would not have any initial moves defined on it. It is a bit of a chore to figure out which flags are relevant. This seems mostly a cosmetic problem, though; in virtual every variant the only relevant flags would be for castling and e.p. capture, and repetition loops in which you have those rights in the first occurrence, and then destroy them in the loop are very rare, and usually deserve to be draws anyway. Who cares if they are 2-fold or 3-fold repeats? Having the server declare a draw is a violation of FIDE rules anyway; these only say that the players can claim a draw in those situations.

Other things I have not implemented yet:

• Testing the highlighted moves for legality; currently all pseudo-legal moves are highlighted.
• Recognizing passing through check as illegal.
• King baring as a winning condition.
• Creation of e.p. rights by oblique lame leaps (Betza n on a W or F).
• Imitators.
• Crooked and circular pieces (Betza z and q).

All of that can be added through updating the GAME code in the include file, and would not affect operation of this Applet.

There is a bug in the rule-enforcement subroutines. The code won't allow any piece to be moved - it just exits with the error message "You cannot move opponent pieces." Luckily, tweaking the cond statement that controls this exit point should fix it easily. When using cond its important to know that it will evaluate the second and third operands before the first operand unless they are encapsulated in parentheses. I'm only guessing here, but I think if you change cond #player islower #mover isupper #mover to cond #player (islower #mover) (isupper #mover) it should work as intended.

The code won't allow any piece to be moved - it just exits with the error message "You cannot move opponent pieces."

This is weird, because all the test presets I made that use the betza.txt include file work fine. I agree that cond is treacherous, and that it would be good defensive coding practice to always enclose its last two arguments in parentheses; this code was from before I knew that, though. But in this case it should make no difference, because islower and isupper have no side effects. So it is perfectly fine to evaluate both of these, and then just take the result indicated by the first operand and discard the other. So the parentheses should make no difference.

Can you give me the URL to the case where you encountered this behavior?

As an afterthought: are you sure you called HandleMove with the correct argument (false | true) for the section you put them in? If you would have inadvertantly swapped that, this would evoke the behavior you report. You aren't by any chance trying to make the first move for 'black' (i.e. the player that handles the lowercase pieces)?

I simply recreated my game Yangsi in the applet, clicked on the button for showing the Game Code, and copied the code into a makeshift preset for it. When I tried to move a piece, the program exited with the error message "you cannot move opponent pieces." I tried it as normal and after swapping the Post-Move sections, but the error persisted.

Both presets I can (indirectly) reach through that link work fine for me.

Those presets were made long before this Play-Test Applet was a thing. What I meant in my last comment was that I recreated the setup and rules of Yangsi in the Play-Test Applet, clicked Start Position, clicked Game Code to get the code, and edited the Yangsi preset to make a fake preset using that code. After that, I tested the fake preset, and after moving a piece, the error showed up.

Well, as long as I don't have a link to that preset, there is nothing I can do about it. All presets I made that link to that same code work fine. (At least they did until the JavaScript was changed; now only moves without side effects work). I never get the error message you mention, unless I am indeed moving a piece of the opponent.

Here's a preset I made using code from the Play-Test Applet:

Yangsi

I just tried it out in solitaire mode. It displayed legal moves by White's pieces, but whenever I tried to move a piece, it gave the error message "you cannot move opponent pieces."

Tick "Do not include moves in code".

I guess I should differentiate the error message between moving opponent pieces and empty squares.