This continuemove can be very useful, as my move parser already recognizes composit moves of the type x-y; y-z as a locust capture of the piece at y as a side effect of the over-all move x-z (i.e. x-z; @-y). I have one problem that interferes with this, however:
In the Shogi variants (e.g. with the Chu-Shogi Lion) it usually happes that if x-y; y-z is legal, then x-y by itself is also legal. So if the user enters x-y you don't know whether you have to invoke continuemove for a second leg, or whether he is already done. I see that Adam DeWitt solved this problem by always using continuemove in this case, and having the user type pass in response to it if he did not want a second leg. But this kind of defeats the purpose of not having to type.
Would it be possible to have the move-entry form appear with the move field already containing the text 'pass'? (Or perhaps with an arbitrary text passed as argument to continuemove?) Then the user would only have to click the 'Play' button if he did not want to enter more legs. And if he does want to play another leg, he can click the board, to make piece ID plus origin square replace the text.
(This would also require a small change in the way the JavaScript click handler works in that case, as currently it seems to prepend the piece+square info of the board click to the text contained in the move field. I suppose this is done for 'reverse entry', where you click the destination first. But it could make an exception for the text 'pass', and always erase that from the move field when the board is clicked. Or only do the prepend thing when the current text starts with a hyphen.)
Another thing:
When I try to print something (for debugging purposes, using print or printr) in the Post-Game sections, it does not seem to show up anywhere. Unless I ask the browser for the page source. Then the output of the print statements appears in the header of the HTML page; FireFox furthermore complains about the </HEAD> and <BODY ...> tags (by displaying them in red), which it apparently does not expect in the place they are now.
Yet another issue:
I am trying to implement promotion now, and I managed to get askpromote present a menu of possible piece choices. But when I then click one (say a Rook), my move parser flags the resulting move as illegal, because the promotion is added as R-dest with the literal string 'dest' rather than a square name. Do I misunderstand the format of promotion 'moves'? When I have GAME Courier perform the move it seems to understand this format, and I can of course have my move parser expect it. Would it also be what the user types if he enters the move by hand?
Oh, and when a Pawn is in the askpromote menu, and I select it, nothing happens when I press 'Play'. (This could be because I am in an infinite loop.) I can imagine that it dislikes adding a no-op promotion move 'P-dest', but how else could it be indicated that I want to defer promotion? Not in all CVs Pawn promotion is mandatory everywhere in the zone.
[Edit] I can confirm that the include with a path name works; I have made a new preset that tries it out, after uploading a betza.txt file to the membergraphics directory of the Play-Test Applet. This preset was made by straight copy-pasting of the GAME code produced by the Applet, after specifying the promotion choice (Lion is forbidden, so the default would not work), setting up the initial position, and redefining the Lion move (which in the Applet's table does not have the locust capture of the Chu Shogi Lion; perhaps I should add such a Lion in the table). It doesn't enforce the Lion-trading rules (yet), and the current betza.txt file doesn't test for game end yet.
This continuemove can be very useful, as my move parser already recognizes composit moves of the type x-y; y-z as a locust capture of the piece at y as a side effect of the over-all move x-z (i.e. x-z; @-y). I have one problem that interferes with this, however:
In the Shogi variants (e.g. with the Chu-Shogi Lion) it usually happes that if x-y; y-z is legal, then x-y by itself is also legal. So if the user enters x-y you don't know whether you have to invoke continuemove for a second leg, or whether he is already done. I see that Adam DeWitt solved this problem by always using continuemove in this case, and having the user type pass in response to it if he did not want a second leg. But this kind of defeats the purpose of not having to type.
Would it be possible to have the move-entry form appear with the move field already containing the text 'pass'? (Or perhaps with an arbitrary text passed as argument to continuemove?) Then the user would only have to click the 'Play' button if he did not want to enter more legs. And if he does want to play another leg, he can click the board, to make piece ID plus origin square replace the text.
(This would also require a small change in the way the JavaScript click handler works in that case, as currently it seems to prepend the piece+square info of the board click to the text contained in the move field. I suppose this is done for 'reverse entry', where you click the destination first. But it could make an exception for the text 'pass', and always erase that from the move field when the board is clicked. Or only do the prepend thing when the current text starts with a hyphen.)
Another thing:
When I try to print something (for debugging purposes, using print or printr) in the Post-Game sections, it does not seem to show up anywhere. Unless I ask the browser for the page source. Then the output of the print statements appears in the header of the HTML page; FireFox furthermore complains about the </HEAD> and <BODY ...> tags (by displaying them in red), which it apparently does not expect in the place they are now.
Yet another issue:
I am trying to implement promotion now, and I managed to get askpromote present a menu of possible piece choices. But when I then click one (say a Rook), my move parser flags the resulting move as illegal, because the promotion is added as R-dest with the literal string 'dest' rather than a square name. Do I misunderstand the format of promotion 'moves'? When I have GAME Courier perform the move it seems to understand this format, and I can of course have my move parser expect it. Would it also be what the user types if he enters the move by hand?
Oh, and when a Pawn is in the askpromote menu, and I select it, nothing happens when I press 'Play'. (This could be because I am in an infinite loop.) I can imagine that it dislikes adding a no-op promotion move 'P-dest', but how else could it be indicated that I want to defer promotion? Not in all CVs Pawn promotion is mandatory everywhere in the zone.
[Edit] I can confirm that the include with a path name works; I have made a new preset that tries it out, after uploading a betza.txt file to the membergraphics directory of the Play-Test Applet. This preset was made by straight copy-pasting of the GAME code produced by the Applet, after specifying the promotion choice (Lion is forbidden, so the default would not work), setting up the initial position, and redefining the Lion move (which in the Applet's table does not have the locust capture of the Chu Shogi Lion; perhaps I should add such a Lion in the table). It doesn't enforce the Lion-trading rules (yet), and the current betza.txt file doesn't test for game end yet.