H. G. Muller wrote on Fri, Aug 21, 2020 11:13 AM UTC:
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.
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.
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.
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.