Comments by FergusDuniho

You should set your random values to constants, not to variables, since the same random values have to be re-used throughout a game. The setconst command will assign a new value only if the constant's value is not already on record. Unlike variables, constants will get stored in the log. If a constant's value was written to the log at an earlier time, it will be retrieved and reused instead of setting the constant's value again.

Would editing the settings change the seed?

Not usually, but it could change the order that random numbers are generated in, the range of random numbers, the number of random numbers, or how random numbers are used. Using the same seed preserves things only so long as everything else regarding random number generation and usage remains the same. Since we cannot count on PHP continuing to use the same randomization algorithm, it is best to store the final result in a constant and to use that.

My game against the interactive diagram. I played White and won.

1. f5 Nh7 2. Nh4 Ng5 3. e4 Cf7 4. Nc4 Rag10 5. g4 Nc7 6. Bf4 h6 7. Ng6 Nce6 8. Nge5 Nxf4 9. Cxf4 Ch8 10. h4 Nf7 11. Nxf7 gxf7 12. Cxh6 Rg7 13. Rjg1 Rg8 14. g5 Cg7 15. Cxg7 Rxg7 16. f6 Rg6 17. d4 Rjg10 18. e5 R6g8 19. Bf5 d7 20. Rg3 e6 21. fxe7 Bxe7 22. Rf1 Rg7 23. Nb6 Bxa3 24. Nxa8 Be7 25. Rgg1 R10g8 26. Ra1 Qe8 27. Nc7 Qd8 28. Ra9 Ke10 29. Rxf9 Kxf9 30. Nd5 Ba3 31. Qa2 Be7 32. Qa9 Kg10 33. Ra1 Rg9 34. Qa10 Kf9 35. Ra9 Ke8 36. Qc10 Rd9 37. Qe10 Re9 38. Rxe9 Qxe9 39. Qxc8 Bd8 40. Bxd7

Is there any way to replay past games with the interactive diagram?

I think the main problem is the random setup. When you randomize the setup, you have to take measures to keep it the same throughout the game. This used to be done by reusing the same seed. But ever since a change in PHP's randomization algorithm screwed this up, the preferred method has been to store the random factors or results in a constant. If the relevant constants exist, use the values already stored in them. Use random values only on the very first time, set the constant values immediately, and then just use the constants.

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.

Since my copy of Mighty Lion Chess wasn't handling en passant capture, I updated it to the latest code. After doing so, I was unable to move pieces by clicking on them. This was so both in the code I was testing and in the already-tested stable code. On investigation, I found out that the list of legal moves included the move "zzz,rlbqkbnrpppppppp32PPPPPPPPRLBQKBNR,4". This was screwing things up. Please limit the use of the list of legal moves to properly formatted moves.

In case you need to pass other data to JavaScript, I have just added the command setjsvar. Use this like you would set. It will store values into an associative array keyed to the variable names, and after the program runs, it will write JavaScript variable assignments. It will write numeric values as is, put quotation marks around strings, and JSON encode arrays. It will write the assignments before the legalList assignment, so that you cannot use it to overwrite this variable.

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.

In the past, if I clicked on an opponent piece at this time, I could see the legal moves that he/she could do on his/her turn.

That ability has been restored. The code was referencing a new element that didn't exist on the preview page, and that was causing the movePiece() function to crash.

More serious is that when I try to play a distant Lion move beyond the Pawn (e.g. l d6-e4) it does not immediately accept the move, but still wants me to choose between the simple move and "l d6-e5; l e5-e4", highlighting both e4 and e5 to make that choice. This is a consequence of the "any order" policy, rather than using the order of entry of clicks 2 and 3 to distinguish between the shooter and the multi-mover case.

For me that issue is still important enough to prefer my own adaptation of the JavaScript.

I had a different issue with the any order mechanism for selecting moves. When I clicked on one of my own pieces in Fusion Chess, it would show both that piece's moves and any fusion moves to that space by another piece. This could be confusing, and I decided it would be better to just show the moves for the piece clicked on. To accomplish this, I rewrote showLegal() to require that the steps of a move be entered in order. When the same space is clicked twice, this signals that moves with more steps should not be accepted, and that the move's final destination must be the space that was clicked on again. This is useful for selecting a shorter move from longer continuations of the same move or for selecting a move that returns to its origin.

Since this would not work properly with moving pieces by clicking on the destination first, I removed that capability. It will now only show where the piece clicked on can move to. It will no longer show which pieces can move to a particular space.

Okay, I see we were talking about different things. I have now added a line to set clicks to [] after the code you quoted.

You mean showLegal() in the JavaScript.

Yes, I have made the correction now.

It was hanging at the clearBorders function. This function used a for of loop, which iterates through the values of an array. When I changed it to the older style that matches for in C or PHP, it worked. However, it did display legal moves, and the showLegal() function also uses for of loops. Maybe it just had a problem with using that kind of loop with an array of HTML elements. Anyway, it seems to be the only thing I had to change. Since I was already planning on it, I also removed showLegalFrom() and showLegalTo() while updating this function.