They cannot. Only some commands evaluate expressions, and gosub does not. Use #player instead.
I first had used #player , but then I noticed that the preset only allowed entry of moves for white, even when it said it was black's turn to move. Black moves were always rejected (by my ParseMove code) with the complaint that he wasn't moving his own piece. I figured that this was because #player was statically dereferenced in the Pre-Game section (where the ParseMove code is inserted), where white is on move.
[Edit] OK, I have got it working. But I don't understand why! The problem could be traced to the following:
When the formal parameter player is passed as false in the subroutine call, the output is
false
var player=
#player=
as expected, as GAME code's default representation for true and false as the result o an expression appears to be 1 and the empty string, respectively. However, when the subroutine is called with arument true, it prints
true
var player=
#player=1
The value of var player is apparently not dependent on the actual value stored in player. Why is that? I understood that var is supposed to be more accurate than # in this respect.
Another issue: I get the error message solved
BANNED INPUT: P e3-e5; e5-e6 on turn 1:
You may not enter more than 4 move primitives in a move in this game.
Indeed I did setsystem maxmove 4. But how does it figure this input is more than 4 move 'primitives'? I count only 2 moves... Is each piece or coordinate a 'move primitive', and should I really set maxmove to 9 to allow one move, one promotion, one suicide and one freedrop?
This was due to continuing the loop over the partial moves after exploding thismove continued indefinitely, because there was no var in front of the loop index in the while condition. It is just that the error message is a bit confusing.
Great, that will be very helpful.
I first had used #player , but then I noticed that the preset only allowed entry of moves for white, even when it said it was black's turn to move. Black moves were always rejected (by my ParseMove code) with the complaint that he wasn't moving his own piece. I figured that this was because #player was statically dereferenced in the Pre-Game section (where the ParseMove code is inserted), where white is on move.
[Edit] OK, I have got it working. But I don't understand why! The problem could be traced to the following:
When the formal parameter player is passed as false in the subroutine call, the output is
as expected, as GAME code's default representation for true and false as the result o an expression appears to be 1 and the empty string, respectively. However, when the subroutine is called with arument true, it prints
The value of var player is apparently not dependent on the actual value stored in player. Why is that? I understood that var is supposed to be more accurate than # in this respect.
Another issue: I get the error message solved
Indeed I did setsystem maxmove 4. But how does it figure this input is more than 4 move 'primitives'? I count only 2 moves... Is each piece or coordinate a 'move primitive', and should I really set maxmove to 9 to allow one move, one promotion, one suicide and one freedrop?
This was due to continuing the loop over the partial moves after exploding thismove continued indefinitely, because there was no var in front of the loop index in the while condition. It is just that the error message is a bit confusing.