Comments/Ratings for a Single Item

More serious is that when I try to play a distant Lion move beyond the Pawn (e.g. l d6-e4) it does not immediately accept the move, but still wants me to choose between the simple move and "l d6-e5; l e5-e4", highlighting both e4 and e5 to make that choice. This is a consequence of the "any order" policy, rather than using the order of entry of clicks 2 and 3 to distinguish between the shooter and the multi-mover case.

For me that issue is still important enough to prefer my own adaptation of the JavaScript.

I had a different issue with the any order mechanism for selecting moves. When I clicked on one of my own pieces in Fusion Chess, it would show both that piece's moves and any fusion moves to that space by another piece. This could be confusing, and I decided it would be better to just show the moves for the piece clicked on. To accomplish this, I rewrote showLegal() to require that the steps of a move be entered in order. When the same space is clicked twice, this signals that moves with more steps should not be accepted, and that the move's final destination must be the space that was clicked on again. This is useful for selecting a shorter move from longer continuations of the same move or for selecting a move that returns to its origin.

Since this would not work properly with moving pieces by clicking on the destination first, I removed that capability. It will now only show where the piece clicked on can move to. It will no longer show which pieces can move to a particular space.

You mean showLegal() in the JavaScript.

Yes, I have made the correction now.

I modified setLegal() slightly to leave out piece notation when parsing a move string.

You mean showLegal() in the JavaScript.

I modified showLegal() slightly to leave out piece notation when parsing a move string. So, the only steps it considers are coordinates and piece notation concatenated with an * for drops. I also modified it to strip out forward slashes, which are used for inline comments. These two modifications are useful because of a trick I came up with for writing fission moves in Fusion Chess. I realized I could write the remaining part of the fission move as a comment, and even though it was a comment, this would allow a player to make a fission move by clicking on the origin space for the third click. After all, there is nothing in setLegal() that distinguishes between real moves and comments. In this case, the comment helps reveal something about the move that distinguishes it from the standard move. Since clicking on a space twice works only when all steps in a move have been used up, I had to eliminate piece notation as steps. This is fine, since they play no role in narrowing down legal moves.

A minor inconvenience is that the text editor for the 'Rules, written in HTML' field in the Edit screen for presets starts in WYSIWYG mode, which strips the HTML of any existing content of that section from everything it doesn't know, in particular script tags, before you even get a chance to see it. If it would start in 'Source Code' mode, as it does in the submission for for member-contributed articles, the original content would be respected, and people that do not want to use any special HTML there can still easily switch to to WYSIWYG.

Okay, it now opens in Source mode.

More serious is that when I try to play a distant Lion move beyond the Pawn (e.g. l d6-e4) it does not immediately accept the move, but still wants me to choose between the simple move and "l d6-e5; l e5-e4", highlighting both e4 and e5 to make that choice.

That's not very serious. In most cases, the move that captures a piece will be more desirable than the move that doesn't, and the player may appreciate the reminder that he can capture the Pawn while moving across its space. Also, some players may find it more natural to first click on the final destination, and then to click on the space where a piece may be captured en route. Since the exact same move will be entered no matter which order the spaces are clicked on, there is no need to enforce a certain order of mouse clicks on the players.

Would it be possible for an editor to rename the file /membergraphics/MSgame-code-generation/movepiece.txt to movepiece.js?

This is done.

A minor inconvenience is that the text editor for the 'Rules, written in HTML' field in the Edit screen for presets starts in WYSIWYG mode

Thanks, I meant to report this.  This edit field should start in HTML mode if there is already content so existing content doesn't get trashed.

I will delay removing them until tommorow, since H.G. currently has code that is using them.

OK, thanks, I have grabbed them now from movepiece.js so I can put them in an adapted script if needed.

I tried the new JavaScript in Mighty Lion. If the Lion captures an adjacent Pawn (l d6-e5) by clicking the latter twice, the move is submitted, but the Post-Move code does ask for a second leg because no pass was appended. Based on the reasoning in the previous comment, this should be considered as a flaw of the Post-Move code, though; it should just have accepted the move. Then this would have worked fine.

More serious is that when I try to play a distant Lion move beyond the Pawn (e.g. l d6-e4) it does not immediately accept the move, but still wants me to choose between the simple move and "l d6-e5; l e5-e4", highlighting both e4 and e5 to make that choice. This is a consequence of the "any order" policy, rather than using the order of entry of clicks 2 and 3 to distinguish between the shooter and the multi-mover case. Highlighting e4 and e5 here would have been desirable for the Forest Ox (a shooter, which would have indicated that by specifying the move as "l d6-e4; @-e5", requesting click order d6-e4-e5). The Lion is a multi-mover, though, and should have required d6-e5-e4 for taking the Pawn, while d6-e4 should already have been an unambiguous expression of the desire to not take the Pawn.

For me that issue is still important enough to prefer my own adaptation of the JavaScript. In connection with that I have some questions:

• Currently the JavaScript array legalMoves[] is still on the Game Courier pages, and my adapted version, as well as some JavaScript embedded in the page that decides what the "How to move pieces" section should say still test for its presence. But since the new movepiece.js does not refer to it at all, I suppose it is scheduled for removal. Is it safe to assume that all future scripts will define legalList as null for presets that do not show legal moves, and that I should test that?
• Would it be possible for an editor to rename the file /membergraphics/MSgame-code-generation/movepiece.txt to movepiece.js? Once the name exist I will be able to update it in the normal way. Then I could make presets that want to use it just contain the link to that file. As it is I would have to put the entire script in the page itself. And these are non-cached pages, typically loaded many times during a game.
• A minor inconvenience is that the text editor for the 'Rules, written in HTML' field in the Edit screen for presets starts in WYSIWYG mode, which strips the HTML of any existing content of that section from everything it doesn't know, in particular script tags, before you even get a chance to see it. If it would start in 'Source Code' mode, as it does in the submission for for member-contributed articles, the original content would be respected, and people that do not want to use any special HTML there can still easily switch to to WYSIWYG. I do like that text editor very much; even in source-code mode it is very helpful in indenting HTML tags and JavaScript, pointing out imbalanced tags and such. But that switching to WYSIWYG mode can lose you so much source definitely is a risky feature of it.

One interpretation is that an incomplete move is being allowed, and a continuation will be required on the next step. The second interpretation is that it is a complete legal move by itself. The third interpretation is a mishmash of the first two. It is that it is an incomplete move as written, but adding pass as the second part will make it a complete legal move.

The way I look at it is that it is a legal move by itself, but that pass sometimes has to be added to 'complete' it, as a kludge to tell that to the GAME code and prevent the infinite loop. And this problem is self-inflicted, by a mismatch between the GAME code and the JavaScript. With the enhanced JavaScript there never is a need to submit incomplete moves. But with the old JavaScript it could not be avoided (other than by typing) that a spurious (partial) move would be sent after entering the first leg, and the GAME code would have to be prepared to deal with that, using continuemove to ask for a second leg, with the risk for an infinite loop if there was none. Even in that setting adding of the pass could have been avoided by having the GAME code set a 'constant' that would enable it to distinguish between runs without or after a continuemove, like $answered allows it to distinguish between a run before and after deferring a promotion choice.

So perhaps I did indeed adopt a cumbersome solution; the logical one would be to simplify the Post-Move code to consider simple moves always complete, and never use continuemove on them. That would exclude interpretation 1, and thus also 3. As it is now I am using one kludge (in the JavaScript) to work around another (in the Post-Move GAME code). As long as the old JavaScript is still around, though, I don't want break my GAME code for working with it.

From the POV of the JavaScript there still will have to be some way the user can indicate whether he is done entering the move, when the legalList indicates that there is an optional continuation. Clicking the last-clicked square a second time (and hence making sure it is highlighted) is the natural way to indicate that. It is the only click that cannot possibly indicate the location of a new side effect.

I have made a major update to movepiece.js. It can now highlight the proper spaces for the subsequent parts of multi-part moves. In general, players may click spaces in any order, and it will narrow down the legal moves to those that include all of the spaces clicked on. In the event that a shorter move is part of longer multi-part moves, or a multi-part move returns to its destination, clicking on a space a second time will indicate that this space must be the final destination of the move. Clicking on the same space twice will deselect a move only when it is the second click. To cancel a move beyond that point, you can click the Cancel button on the requester that lists multiple move options.

It now uses a single showLegal() function instead of the two functions showLegalTo() and showLegalFrom(). I will delay removing them until tommorow, since H.G. currently has code that is using them. One of the main differences from H.G.'s code is that it will not arbitrarily add "pass" to a move. It works with the legal moves provided to it in legalList, and it does not make any assumptions about there being other legal moves outside this list. Another difference is that it should handle multi-part moves with any number of different coordinates. H.G.'s code can handle multi-part moves with up to three different coordinates.

In the event that a third or later click results in no legal move, it will try to submit the move it has constructed. If this is an exact match for a legal move, it will automatically submit it. If it is not, it will ask the player if he wants to submit it. This allows a player in Fusion Chess who is prompted with both a standard move and a fission move, for example, to play the standard move by clicking the board again.

So even now that I know that the $extralegal moves are used for highlighting, by studying the JavaScript, I still have the dilemma of whether to push a move a-b simply as a-b, or as a-b; pass. I now solve that by letting the JavaScript highlight the destination of the first leg also as possible destination of the second leg to select a move without side effect, and have it add the pass to the move just before submitting it, when that move gets selected by a third click.

This is a kludge that I wish to avoid. If the legalList includes a move by itself, and it includes that same move as the first part of multi-part moves, but none of these have pass as the second part, there are three possible interpretations of this, and it does not know how to rule between them. One interpretation is that an incomplete move is being allowed, and a continuation will be required on the next step. The second interpretation is that it is a complete legal move by itself. The third interpretation is a mishmash of the first two. It is that it is an incomplete move as written, but adding pass as the second part will make it a complete legal move. For the first two interpretations, it would not be appropriate to add pass. It is only for the third, which happens to be the case for games your applet has programmed, where it would be appropriate to add pass.

If you would add a move option with pass as the second part of the move, the player could choose that immediately, which would bypass the need for the player to complete the move on the next page.

But it was not possible to pass a pass option to setlegal, one could only pass the first leg. I didn't know the moves in $extralegal were also used for highlighting; I thought they were just for the auto-completion. One problem is that at the moment a move without side effects is generated, there is no way knowing whether the same move with side effect will be generated later. And it would look silly to write every simple move as a 2-leg move with pass as second leg, especially if it happened in a game where there even aren't any multi-leg movers.

So even now that I know that the $extralegal moves are used for highlighting, by studying the JavaScript, I still have the dilemma of whether to push a move a-b simply as a-b, or as a-b; pass. I now solve that by letting the JavaScript highlight the destination of the first leg also as possible destination of the second leg to select a move without side effect, and have it add the pass to the move just before submitting it, when that move gets selected by a third click. And I refrain now from using setlegal on moves with side effects.

That moves for $extralegal must be in standard format is indeed an extra obstacle for the programmer (although I think I got it right). This is why I proposed to use setlegal also for multi-leg moves, so that it can generate the standard format. What holds for simple moves holds to an even larger degree for multi-leg moves.

I'm working toward something that will do that, but I need to be able to test it with Mighty Lion Chess.

If you clone the Mighty Lion preset by saving it to another settings file, you won't copy the JavaScript with it. You can then use it to test your own JavaScript. Same with Odin's Rune Chess.

I had this idea about moving the piece with JavaScript.

I have plans down the line to make Play mode AJAX-driven. If that works out, it could be applied to the other modes. But I have more immediate things to work on right now.

The Mighty Lion and Odin's presets now use a slightly adapted version of movePiece JavaScript routine, which does take care of the highlighting after the list with remaining moves opens: it first clears all the highlights for the first leg, and then applies highlights to the destinations of a second leg, or to the squares where there are side effects. A third click on the board can then be used to select any of those, and submit the move (if it then is unique and legal).

I'm working toward something that will do that, but I need to be able to test it with Mighty Lion Chess.

Do all moves have to be written in $extralegal, to get them in the legalList?

No, moves set with setlegal are converted to text format for legalList.

It seems the highlighting now is done completely on the basis of legalList, and that legalMoves is no longer used for any other purpose than to switch on the highlighting, by testing it against null.

That was an oversight. I have now changed that to legalList, so that the legalMoves array is no longer used for anything.

The Applet GAME code used to push some partial (first-leg-only) moves with setlegal (because there was no way to include the side effect there), just to make sure that the destination would be highlighted and available for clicking. (After which it would use continuemove to inquire about the side effect.) But this backfires now, because the JavaScript thinks these moves would be legal by themselves, leaving ambiguity when there is in fact none after the second click, and needlessly asking for a third.

I have already brought up this problem and its solution with you, but you ignored what I said. If you would add a move option with pass as the second part of the move, the player could choose that immediately, which would bypass the need for the player to complete the move on the next page. If you like, you could even remove the option that includes the move by itself without pass. Then the player would have to make a choice before continuing to the next page.

If I can rely on highlighting in the future being purely done from $extralegal, I can refrain from writing anything to $legalmoves.

Using $legalmoves ensures that everything will be written in a standard format. If you use only $extralegal, you should keep your notation standardized. For a standard move, this means the piece notation, a space, the origin coordinate, a hyphen, and a destination coordinate with no extra spaces. For a drop, this means the piece notation, an asterisk, and the destination coordinate. For a free drop, just replace the asterisk with a hyphen. Note that if you use aliases, the piece notation is the alias, not the label used as a key in $pieces.

since you seem to synthesize the move texts from the square pairs given to setlegal, which you will have to do for backward compatibility, it might be better to extend the capabilities of setlegal to also accept multi-leg moves, so that there is a unified way to submit moves for highlighting.

I'll think about that, but first I have to work on what I mentioned at the top.

And for something completely different:

I had this idea about moving the piece with JavaScript. In HTML-table or ASCII-art mode that would not be a problem. But it seems you have already overlayed the images that are used in JPG/PGN/GIF mode with an individually addressable set of (entirely transparent) empty squares, for the purpose of using their border as highlights. It should be possible to replace these images on the origin and destination square of the first leg by opaque ones of an empty square and a piece. It doesn't really matter if these had a deviating background color compared to the square they cover; this could be seen as a form of highlighting of the first leg, while the normal highlights now indicate possible destinations for the second leg.

The Mighty Lion and Odin's presets now use a slightly adapted version of movePiece JavaScript routine, which does take care of the highlighting after the list with remaining moves opens: it first clears all the highlights for the first leg, and then applies highlights to the destinations of a second leg, or to the squares where there are side effects. A third click on the board can then be used to select any of those, and submit the move (if it then is unique and legal).

I am a bit confused about how things work now. Do all moves have to be written in $extralegal, to get them in the legalList? Or do you somehow convert the moves submitted by the GAME code through setlegal to text, and add these to $extralegal to make the legalList? It seems the highlighting now is done completely on the basis of legalList, and that legalMoves is no longer used for any other purpose than to switch on the highlighting, by testing it against null. The Applet GAME code used to push some partial (first-leg-only) moves with setlegal (because there was no way to include the side effect there), just to make sure that the destination would be highlighted and available for clicking. (After which it would use continuemove to inquire about the side effect.) But this backfires now, because the JavaScript thinks these moves would be legal by themselves, leaving ambiguity when there is in fact none after the second click, and needlessly asking for a third.

If I can rely on highlighting in the future being purely done from $extralegal, I can refrain from writing anything to $legalmoves.

BTW, since you seem to synthesize the move texts from the square pairs given to setlegal, which you will have to do for backward compatibility, it might be better to extend the capabilities of setlegal to also accept multi-leg moves, so that there is a unified way to submit moves for highlighting. E.g. you could add to the specs that when the (only) argument of setlegal is an array, it will treat it as a multi-leg move. (You can still distinguish that from the other formats, which always have to start with a square.) The array could then be interpreted as a sequence of (from, to) pairs for each of the legs, from which a move text would be generated by concatenating them, using hyphens and semiclons as separators where appropriate. E.g.

setlegal (c6 e5 e5 d4 Q dest);
setlegal (e2 e7 @ e8 N e6);

would translate to "c6-e5; e5-d4; Q-dest" and "e2-e7; @-e8; N-e6", respectively. That would relieve the GAME code from constructing the text by itself.

Since enforcing and showing legal moves usually requires some separate code, there can sometimes be a discrepancy between the legal moves that are enforced and the legal moves that are shown. Players are allowed to purposely enter moves that are not shown as legal as a way of getting around this when it happens.

Indeed, I already thought this would be the purpose of the popup. The code in the betza.txt file could also suffer from such a discrepancy, because I am using a shortcut for testing legality of the moves to be highlighted, different from a full king capture test used on the move that is played, and there could be cases I overlooked where the shortcut is not entirely accurate. At the moment this is certainly the case for the anti-trading rules, (but that would cause illegal moves to be highlighted, not the other way around), and moves of an imitator (where the shortcut doesn't take into account yet that the move will be altered because of the one we want to test for legality).

Another thing I ust noticed:

The 'menu' page for a preset used to highlight moves for a piece that you clicked. (But you could not click a destination; then they simly went off again.) This no longer works, because there is no 'messagearea' on that page. Not that it would be useful to have one. But perhaps you should make the JavaScript test whether getElementById returns null, and make execution of the code that accesses it conditionally dependent on that, for otherwise it crashes the script.

The new behavior came about from the different way that it now handles legal moves. Instead of constructing the move, it searches for a matching legal move and sets the move to the matching legal move. But when no legal move was found, it would not set it to anything. I have now changed it to construct the move before looking for a match among the legal moves. If it finds a single match, it will overwrite the constructed value with the the match it found. But if it doesn't find a match, it will keep the constructed value. Since enforcing and showing legal moves usually requires some separate code, there can sometimes be a discrepancy between the legal moves that are enforced and the legal moves that are shown. Players are allowed to purposely enter moves that are not shown as legal as a way of getting around this when it happens.

Basically you should be able to do this on any preset that hilights moves, but you could use Mighty Lion Chess. Select Move or Play. Click e2 (highlights on e3 and e4 come on). Click e5. You get a popup that complains this is not highlighted as legal, and asks if you want to play it Anyway. Click OK. The problem now is that it doesn't submit the requested "P e2-e5; it submits "P e2-".

Now it is a perfectly valid stance that you don't ever want to send "P e2-e5", because the highlghts give a strong indication that it will be illegal (and in this case it certainly is). But why the popup, then? Sending "P e2-" is not what the wanted to play, and is most certainly illegal. Better just ignore clicks on non-highlighted squares completely, in that case.

If the JavaScript is doing something wrong, tell me in precise detail how I can replicate what you are doing and see the same results.

Sure, but there is no way the code could know what the error is if the JavaScript doesn't relay what square the user clicked. As far as the code is concerned, it gets an empty string, so of course that is not a valid square. How could it know the user tried to expose his king?

Now, however, when I want to step into check with my King, it complains "is not a valid square", instead of the expected "This exposes your royal to check".

Since these messages are from your own code, this is a matter for you to figure out yourself.

I noticed some behavior that seems to be new, and it doesn't seem intentional. Before, when I clicked a non-highlighted square as destination, I got a popup to ask whether I was sure I wanted to play an illegal move, and when I confirmed that, it submitted the move. I do this often to test whether the error messages my generic code gives are working and understandable. Now, however, when I want to step into check with my King, it complains "is not a valid square", instead of the expected  "This exposes your royal to check". Turns out the move that is submitted was "K c4-", i.e. the click on c3 (where I would be in check) had been ignored completely. (Except that it cause submitting of the move.)

Can we get a GAME-code command or variable that would enable the program to 'tick' this option under program control?

I wasn't sure it would work, because it goes into effect during the construction of the program, which happens before its execution. But when I tested it in solitaire mode, it did work. The system variable is called omitmoves, and you should set it to true. I recommend testing whether it will continue to work in logged games.