Comments/Ratings for a Single Item

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).

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. That would confirm the reported behavior of empty. But it seems to be intended.

The empty command doesn't seem to be working as it should,

I'm trying to create a new preset, and when using the empty command in the pre-game, the pieces end up captured.

I just tested it in Chess, and it works as it should. When I ran the following code, it removed White's King and the Queen-side Rook from the board, and it printed K. If it were working the same as capture, it would have printed R.

capture e1;
empty a1;
echo $lastcaptured;

Fergus,

The empty command doesn't seem to be working as it should,

I'm trying to create a new preset, and when using the empty command in the pre-game, the pieces end up captured.

Then I checked one of my old presets (below), which used to work, and realized that the empty command has the same incorrect behavior:

https://www.chessvariants.com/play/pbm/play.php?game%3DAjax+Orthodox+Chess%26settings%3DAlfaeire

I have updated movepiece.js again. In case you want to use one-click moving when there is more than one move available, what you can do next has become a bit more intuitive. When it turns out that all matching legal moves start with movement by the same piece, and this was not the first piece clicked on, the clicks array is modified to include a click on that piece as the first click. Also, the only spaces that get highlighted are those that can disambiguate the move further. One consequence of this is that you can sometimes click on a space twice in a row to move a piece there.

Thanks to misremembering what was stored in the clicks array, the showNextLegal() function was not handling drops, and the showAllLegal() function was picking up the slack, which was causing the move options requester to pop up for drop moves. I stopped this by fixing showNextLegal() to handle drops correctly.

BTW, since you seem to synthesize the move texts from the square pairs given to setlegal, which you will have to do for backward compatibility, it might be better to extend the capabilities of setlegal to also accept multi-leg moves, so that there is a unified way to submit moves for highlighting. E.g. you could add to the specs that when the (only) argument of setlegal is an array, it will treat it as a multi-leg move. (You can still distinguish that from the other formats, which always have to start with a square.) The array could then be interpreted as a sequence of (from, to) pairs for each of the legs, from which a move text would be generated by concatenating them, using hyphens and semiclons as separators where appropriate. E.g.

setlegal (c6 e5 e5 d4 Q dest);
setlegal (e2 e7 @ e8 N e6);

I have extended setlegal to treat an initial array and any subsequent array after a first array as a multi-part move. So far, this works only with coordinates, not with pieces. Also, it specifies a path. So, setlegal (c6 e5 d4) would result in "[piece notation] c6-e5; e5-d4". I might change it to something simpler, like what you're suggesting, since it would make it easier to include pieces.

I have also extended it to add strings to the $extralegal array. This lets you construct any legal move you like as a string. Now that variables can be included in strings when enclosed in braces, this should prove an easy way to add legal moves.

Finally, legal moves are now being validated. After all legal moves have been assigned, they are run through a filter to make sure they are well-formed.

But you do that when the opponent is on move. Otherwise nothing would be shown anyway. When we say 'opponent' in these discussion, we mean the opponent of the side that is on move in the displayed position. Not necessarily that of the player who is looking at the page.

In normal usage, a game typically has two players, and each player is the other player's opponent. According to the variable names used in Game Courier, $player is the player whose turn it is to move, and $opponent is the other player. In this specialized usage, only the player's moves are ever shown, and the opponent's moves are never shown. More precisely, only the current player's moves are ever available to be shown, and the attacks the opponent could make are not available to be shown.

When a player moves, $player and $opponent switch values, and that player can then see the moves available to his opponent up until his opponent moves. It would probably be even more useful to show attacks from the opponent when it is not that opponent's turn, but that would take additional programming, and it would be incompatible with another useful feature I just added, which is the ability to capture an opponent's piece in one click if there is only one legal move to its space.

In hindsight, I would like to undo the use of $player and $opponent as variables, because they have hindered my ability to program multi-player games. But at this stage, it would require a lot of reprogramming.

I often click the opponent piece to review what moves it can do. This is quite useful in chess with different armies, or the zebra, because the zebra moves are different from game to game.

But you do that when the opponent is on move. Otherwise nothing would be shown anyway. When we say 'opponent' in these discussion, we mean the opponent of the side that is on move in the displayed position. Not necessarily that of the player who is looking at the page.

Since it took less work, I moved the requester to its own function, selectMove(), and I used it in three places in movePiece().

I often click the opponent piece to review what moves it can do. This is quite useful in chess with different armies, or the zebra, because the zebra moves are different from game to game.

I can see little reason for clicking an opponent piece or empty square without the intention to move there with fewer clicks

That's what I was thinking.

In case of ambiguity this means the order of the first two clicks would be swapped.

This occurred to me while I was while trying to sleep last night, and I just programmed it to do that.

Now that it does that, I think I want to combine clicking the first time and clicking subsequent times for legal moves. Right now, they are currently handled separately, and a first click does not pop up the requester for multiple move options. Alternately, I may make put the requester in its own function and call it from different places.

But it will not work when you click on one of your own pieces to see its legal moves. In that case, it will display the legal moves even if there is only one, and it will not play the move automatically.

That sounds indeed like the best way to handle it. Personally I always feel a bit unnerved when an own piece that I click suddenly jumps away, because I often just click different pieces to switch on the highlights for what they can do, while thinking. So it is good that this will never happen. OTOH, I can see little reason for clicking an opponent piece or empty square without the intention to move there with fewer clicks. In case of ambiguity this means the order of the first two clicks would be swapped. Additional clicks (which should be a pretty rare requirement anyway) can then be made in strict order, the highlights always showing what the options for the next click are.

BTW, I would still consider it an improvement when one could select a different piece to move from the currently selected one, by just clicking it, rather than having to deselect first. Unless the other piece is highlighted as a valid destination for the selected one. (Of which the most common case will probably be a click on your own Rook to indicate a castling that would be ambiguous when indicating the King destination; virtually no variant has true friendly capture.) Treating a click on a non-highlighted own piece in a game that highlights will thus virtually never be an attempt to illegally enter a friendly capture, which makes the popup asking to confirm that this is what you want a bit silly. Better just treat it as if the user selected 'cancel' on that popup, resetting the move-entry state, and recursively calling movepiece for the same square as if it was a first click.

I was interrupted when I was writing before, and I just now remembered something I wanted to include. By using showNextLegal(), the code can tell that a piece has no legal moves of its own, and by using showAllLegal(), it can then tell how many legal moves there are to that space. It is through using both together that one-click moving to a space occupied by an enemy piece is made possible.