Comments/Ratings for a Single Item

Could you please specify what the software "says"? Since the preset was edited using HG Muller's Play-Test Applet, we're going to need him to help us. I hope he finds out about this message.

Hi Carlos. Note that I tried to mouse-move my knight:

The error message says:

SYNTAX ERROR IN USER INPUT n f7-d6 on turn 9:

compose_move: #to is not a valid coordinate

Go back and try again.

Thank you Kevin. Playing the game using the "PLAY someone at the same location" resource, I actually find said message. I don't know if the bug is related to the fact that the following alert appears at the top of the page:

Your FEN Code has fewer ranks than are indicated in Rank Labels.

EDIT: I just corrected the discrepancy in the Rank Labels so the alert has disappeared but the bug remains.

@HG:

Could you please take a look at the problem before mentioned in this comment thread? Thanks in advance!

@Fergus: Although this preset is automated with GAME code generated by the Play-Test Applet and the betza.txt include file, I don't think that is the problem here. This error message is not anywhere in that code, and I also do not have or refer to any routine compose_move. There is a routine in betza.txt that uses #to as a local variable, but it doesn't try to create a move out of that before passing its value to other routines, under another name.

The error message sounds a bit like Game Courier is already rejecting the move before it would pass it to any user-supplied GAME code for vetting. Do you recognize it as anything that Game Courier could print?

I could not try anything out myself; if I follow the link to the preset page, it doesn't allow me to enter any move; if I click the highlighted destination square it just reverts to the (unhighlighted) original position. Probably because I am not one of the players.

I could not try anything out myself; if I follow the link to the preset page, it doesn't allow me to enter any move; if I click the highlighted destination square it just reverts to the (unhighlighted) original position. Probably because I am not one of the players.

Thanks for answering, HG. I was waiting for an answer from Fergus to your question. Apparently he didn't see it. What you are referring to is somewhat strange, since anyone who accesses the Sissa Chess preset must be able to reach the critical position in which the bug arises using the "MOVE pieces by yourself" resource, carrying out the following movements:

1. P e2-e4     P e7-e5
2. P d2-d4     P e5-d4
3. Q d1-d4     N b8-c6
4. Q d4-a4     P f7-f5
5. P e4-f5      P d7-d5
6. Q a4-i4      N h8-f7
7. S f1-d5      N c6-e7
8. Q i4-a4      S d8-c6
9. S d5-c5

Checking all the possible legal moves of the Blue side one by one, I found that the software rejects all but two: 9... B c8-d7 and 9... P b7-b5.

Curiously, both moves fall on the a4-e8 diagonal, with which the mystery of what causes the bug becomes more acute.

Does this give you any clues about what's going on?

OK, that helps. And I found a much shorter game that evokes the same error:

1. e4 d5

2. Sxd5 Nb6

3. Sc5

Then 3. e5 crashes the preset. There is some unexpected behavior here, in that setting 'to' to a nonexisting element of an array sets it to #to, instead of an invalid value, like it makes the variable disappear altogether. But I should be able to solve this now.

The error message says:

SYNTAX ERROR IN USER INPUT n f7-d6 on turn 9:

compose_move: #to is not a valid coordinate

When a variable has not been assigned a value, it is sometimes treated as a string literal of the named variable. So, what we have here is the variable named to without any value assigned to it. See where #to appears in the code, and make sure it has been assigned a value, and that that value is a valid coordinate.

Indeed, this is exactly what happened. I had a statement

set to elem #k #tosqrs;

and through a bug elsewhere k had gotten the value -1. So this must have set to to the string value "#to". This was passed through many other variables, finally ending up as the destination operand in a move command. This apparently calls compose_move internally, which produced the error message.

Ultimately I could trace the source of the error to the variable that held the range of the leg of a move not being declared as local in a my statement, so that the recursive call that happens for two-leg moves (such as those of the Sissa) spoiled it for the earlier instance. Turned out I had declared the variable in the my statement as 'range', while the code in the routine consistently used 'rng' instead.

I think it should work now that I changed the declaration to rng. In my test position it no longer complains.

The bug has been fixed. Thank you very much HG and Fergus.

Symmetric Sissa is a nice compliment to this original CV with the use of Sissas.

I think this piece caled Sissa is great, but I would remove acute angles (45 and 315 degrees) and only keep obtuse angles (135 and 225 degrees). 

I would also remove the rule that both moves have to be of the same length. This will create a new piece that can make an absolute mess on the chessboard.