OK, I see. There is a mismatch between your first-move handling routines and the normal Post-Game section. On black's turn 1 it does your Post-Move 2 (blackInitialHandle), but the normal GameEnd false in Post-Game-2. This is needed because you now want to highlight for white's normal move that will be entered next.
But GameEnd assumes the variables promo, mover and desti (and probably a lot more) to be set by the preceding call to HandleMove, which now was not done. It uses these in a call Promote #player #mover #desti, to test whether the moved piece is allowed to promote at the given destination, and if any promotion piece was specified with the move (#promo) that would be allowed, or whether one would have still to be requested through a promotion screen. This routine now gets confused because the involved values are still undefined.
At the end of blackInitialHandle (after it made the moves) you could put
set many ok 1 promo 0 ori #source1 desti #dest1 mover space #dest1;
to define these variables the way HandleMove would have left them, and prepare the way for proper execution of the following GameEnd.
Currently your code has no provision for positioning the second piece with the mouse; after entering the first move it immediately sends it to the server, so source2 and dest2 will be undefined in the first call to the InitialHandle routines. In GameEnd I handle a similar situation (when the user has entered the first leg of a locust capture) by issuing the GAME-code commands continuemove, return; when #ok has been set to value 2 in the preceding Post-Move routine when it detected part of the move was still missing.
I am not sure how you would have to make sure such an additional move would have to be highlighted; I suppose the list of legal moves for that turn would already have had to consist of move pairs. Probably Fergus can help you with that better.
OK, I see. There is a mismatch between your first-move handling routines and the normal Post-Game section. On black's turn 1 it does your Post-Move 2 (blackInitialHandle), but the normal GameEnd false in Post-Game-2. This is needed because you now want to highlight for white's normal move that will be entered next.
But GameEnd assumes the variables promo, mover and desti (and probably a lot more) to be set by the preceding call to HandleMove, which now was not done. It uses these in a call Promote #player #mover #desti, to test whether the moved piece is allowed to promote at the given destination, and if any promotion piece was specified with the move (#promo) that would be allowed, or whether one would have still to be requested through a promotion screen. This routine now gets confused because the involved values are still undefined.
At the end of blackInitialHandle (after it made the moves) you could put
to define these variables the way HandleMove would have left them, and prepare the way for proper execution of the following GameEnd.
Currently your code has no provision for positioning the second piece with the mouse; after entering the first move it immediately sends it to the server, so source2 and dest2 will be undefined in the first call to the InitialHandle routines. In GameEnd I handle a similar situation (when the user has entered the first leg of a locust capture) by issuing the GAME-code commands continuemove, return; when #ok has been set to value 2 in the preceding Post-Move routine when it detected part of the move was still missing.
I am not sure how you would have to make sure such an additional move would have to be highlighted; I suppose the list of legal moves for that turn would already have had to consist of move pairs. Probably Fergus can help you with that better.