Comments/Ratings for a Single Item

There seems to be something weird with the "won" command.

I have now fixed this. See the comment below.

The correct game was this one:

https://www.chessvariants.com/play/pbm/play.php?game=Petteia+-+Dmytro+Variation&log=j_carrillo_vii-halfer-2020-283-953

Seems to be fine now. Thanks.

It was showing that your opponent had won, yet you had entered the won command. So, I fixed that. It now makes use of the $players variable if available. This gets set when an invitation is accepted, and it keeps a permanent record of who moved first, which makes it easier to tell which player entered the command.

Fergus,

I must be going crazy... :-(

Now this game:

https://www.chessvariants.com/play/pbm/play.php?game=Petteia+-+Dmytro+Variation&log=j_carrillo_vii-halfer-2020-283-953

(the game whose moves I couldn't see before) is showing that my opponent won the game. This game is another one where I ended the game with the "won" command.

I issued the "won" command as white, but the log shows that my opponent (black) won.

There seems to be something weird with the "won" command.

Below the page source section with the problem:

Apologies Fergus, gave you the wrong link.

The correct game was this one:

https://www.chessvariants.com/play/pbm/play.php?game=Petteia+-+Dmytro+Variation&log=j_carrillo_vii-halfer-2020-283-953

But I just checked again and now the log is there. It was weird. last time I checked there were only two lines in the log, White to play and Jose Carrillo won the game.

And I saw it as well in the page source.

Seems to be fine now. Thanks.

And thanks for correcting the winner in the other comment I submited.

Cheers!

So I could write something like

def BadZone == 9 rank #destination =origin =destination =locustsqr =dropsqr =droppedpiece;

to get a function called with 5 parameters, and only testing if the second is on rank 9?

First, a matter of vocabulary. Function definitions have parameters, but function calls have arguments. An argument is a value passed to one of the parameters of a function. This will test whether the fourth argument from the right is a coordinate on rank 9, which would be the tenth rank. As long as you include five arguments in your function call, it will be the second argument from the left. If you had only four arguments, it would test the first one from the left. If you had three or less, that parameter would not be assigned a value. I know it's a bit counter-intuitive, but it's what comes from evaluating functions in reverse order, as Game Courier does.

Also, something went wrong with this game, which also just ended with the "won" command:

https://www.chessvariants.com/play/pbm/play.php?game=Petteia+-+Dmytro+Variation&log=j_carrillo_vii-halfer-2020-285-568

Are you sure you gave me the link to the correct game? This one doesn't include the won command in it.

Now it shows that my opponent (who resigned) won the game.

That's now been corrected.

Fergus,

Also, something went wrong with this game, which also just ended with the "won" command:

https://www.chessvariants.com/play/pbm/play.php?game=Petteia+-+Dmytro+Variation&log=j_carrillo_vii-halfer-2020-285-568

I'm trying to view the moves to replay the game, and now I can't see any of the moves.

It just show the starting board without any of the moves played.

Thanks in advance.

Thanks Fergus.

Now that the "won" command is working (and because by opponent had resigned to the game, while the won command didn't work) there was a strange behavior that affected the result for this game:

https://www.chessvariants.com/play/pbm/play.php?game=Latrunculi+XXI&log=j_carrillo_vii-cvgameroom-2020-281-060

Now it shows that my opponent (who resigned) won the game.

Can you please correct the result for this game? Thanks again.

To summarize, I fixed it.

Fergus,

I'm not sure I understood your response.

Does the won command don't work anymore when entered as a move?

How are we supposed to claim a win when we checkmate in a preset that does not enforce the rules?

It would make more sense for the "won" command to work as a move than the "lost" command. For losing a game we have the alternative to "resign" command, but what is the alternative when we win by checkmate and we should claim a win immediately, rather than ask the opponent to resign a checkmated position?

I have now a problem with the "won" command.

This problem went deeper than the won command. Thanks to a bit of restructuring I had done to speed up Game Courier, it was not properly handling any commands entered as moves except for a few that were handled earlier, such as resign, lost, and drawn, but not won. I corrected it to handle commands entered as moves. I set it up so that resign, lost, and drawn are not affected by the global ban on all commands, though they may be banned individually. I commented out the code for using them earlier, and I modified the code in the commands section.

How sure are you that you changed it back to what it was?

I used Ctrl-z all the way back in Notepad++.

It could also be that FireFox was updated, and is not so forgiving as a previous version anymore.

It hasn't been updated since I began running it earlier today. I just tried it in other tabs, and it is working. Maybe I went to the wrong tab. The one that wasn't working turned out to be for I-Chess, not Chess.

So, I added some documentation for it in the area you quoted from.

To make sure I understand this: the formal parameters of the function will have to be written at the end of the function, each prefixed with '=', in the order the corresponding actual parameters will appear in the function call? And the function call will then 'eat away' always that number of parameters from the stack, whether they are used or not? So I could write something like

def BadZone == 9 rank #destination =origin =destination =locustsqr =dropsqr =droppedpiece;

to get a function called with 5 parameters, and only testing if the second is on rank 9?

How sure are you that you changed it back to what it was? Did you safe the old version, and moved it back?

This kind of thing usually happens to me when I accidentally made some unintended changes (e.g. drag-drop something because of a mouse glitch without noticing it, or leaning on the keyboard), and then reverting the intended changes then of course doesn't help. Under Linux I now use git for version control, so there I can always revert to any previous version. (And more importantly, just look at the diff with such a version, to see if anything untoward happened.)

I am afaraid that debugging it again is the only alternative.

[Edit] It could also be that FireFox was updated, and is not so forgiving as a previous version anymore. I know that I initially had uploaded the JavaScript for the Interactive Diagram with a PNG extension. This worked for a long time on FireFox, but at some point it stopped working, and it would only consider scripts in a .js file.

While not working in Firefox, it is working in Vivaldi. Strange.

While looking into this, I wrote some additional code. Game Courier stopped working properly, and since I could not see any problem in the new code, I just undid all changes, but the problem persisted. Since I have edited only one Game Courier file today, and I changed it back to what it originally was before any problems began, I'm not sure what the problem could be.

Hi Fergus,

I have now a problem with the "won" command.

I just use the "won" command in this game:

https://www.chessvariants.com/play/pbm/play.php?game=Latrunculi+XXI&log=j_carrillo_vii-cvgameroom-2020-281-060

but the game continued.

I asked my opponent to resign, while I sort out what is happening to the "won" command.

Thanks Fergus.

This worked for me.

setsystem originalpieces currentpieces;

Do I have to need to add an include file for "empty" to work the way it used to?

The empty command works the way it always has. The only difference from before is that the captured pieces display is a relatively new feature. If you don't want the pieces to show up in the captured pieces display, you have two options. You can write code that will set the capturedpieces system variable to what you want it to display. Or you could modify the value of originalpieces after you modify the board at the beginning of the game, then allow the usual default behavior for creating the captured pieces display. To do that, just include this line of code after your code for modifying the position:

setsystem originalpieces currentpieces;

I have just been waging a battle with this rule. This really is an extremely troublesome property of GAME code; is it really necessary to treat functions so sloppily? I understand that you somehow have to know how many arguments a function call has to delete from the stack. But why does it care if the earlier arguments are actually used to compute the function result? It should be able to just ignore them.

There is now a new way to pass arguments to a function. I thought I had documented this, but I don't see where. So, I added some documentation for it in the area you quoted from. I also removed one error message, changing it to do nothing when a variable assignment in a function has nothing to assign to it. This change allowed functions to use default values for parameters.

With 'captured' Jose might not refer to $lastcaptured, but to the places displayed next to the board. I understood that GAME Courier just calculates those as the difference between initial and current pieces, irrespective of how the missing pieces disappeared.

Yes, that's the default behavior. The displayed captured pieces can be controlled by the code, though.

That would confirm the reported behavior of empty. But it seems to be intended.

Yes, the empty command empties the coordinates passed to it.

I just added those same lines to my code, and the result was the same, "empty" captured.

/play/pbm/play.php?game%3DPetteia+V2%26settings%3DSet8q

Doesn't seem to work. I end up with 4 captured pieces.

alias S CI s ci D ~C d ~c;
empty a4;
empty a5;
capture e1;
empty a1;
echo $lastcaptured;



Do I have to need to add an include file for "empty" to work the way it used to?

The highest numbered placeholder should not exceed the number of different placeholders that you use. So, for example, if you use #4 as a placeholder, you should also include #3, #2, and #1.

I have just been waging a battle with this rule. This really is an extremely troublesome property of GAME code; is it really necessary to treat functions so sloppily? I understand that you somehow have to know how many arguments a function call has to delete from the stack. But why does it care if the earlier arguments are actually used to compute the function result? It should be able to just ignore them.

I have an application where I want to make it possible for a user to supply a function that could veto a normally valid pseudo-legal move generated by the library code, e.g. because it lands outside a confinement zone as in Xiangqi, or captures a piece type it should not be able to capture (e.g. the Jianggi Cannon x Cannon ban). To this end the library code has to call that function from some appropriate place, and it passes all the available information about the move to it, because there is no telling what kind of conditions the variant imposes. So it passes origin, destination, optional locust-capture square all to the function. But in individual cases the decision might require one some of the items (e.g. just the destination). It is really inconvenient having to include dummy operations on all the unused arguments. It completely mystifies a function that a user of the library would have to supply (and is bad for efficiency). Currently I work around it by writing something like

def BadZone cond 1 fn Edge #1 join #0 join #2 join #3 #4;

where the entire join club is just there to produce a dummy result that is never used (but cannot even be parenthesized to suppress its evaluation, as then the trick doesn't work anymore).