Comments by FergusDuniho

I found the site down this afternoon and booted it back up. Since the last move had been made almost four hours ago, I modified Game Courier to take off four hours from any move interrupted by this downtime.

I found the site down this morning, and when I booted it back up, the last log was over 18 hours ago. So, I modified Game Courier to take 19 hours off the time for any move interrupted by this downtime.

That's now fixed. The original code was based on Chess, which didn't allow en passant from multiple ranks. I replaced the requirement that the capturing pawn cannot move into or beyond the enemy's pawn rank with the requirement that the capturing pawn must be moving from the same rank as the double-moved pawn just moved to.

Can you show me a sample game that ends in a position in which an illegal en passant is allowed?

Note that what you did doesn't actually extend anyone's time. It just affects what is seen on the Logs page. The time that is left for any game is determined by Game Courier through calculations that involve the values of the various time control parameters, which are all stored in individuals logs, not in the database.

To save on server load, the Logs page bases its calculations of time left on pre-calculated figures stored in the database. In the old days, it used to load every logs file and use the same algorithm as Game Courier itself used. But this increased the server load so much that we got kicked off of shared hosting and had to put this site on a VPS. The downside to not doing this is that when the site is down for some time, the Logs page reports inaccurate calculations of how much time is left. Because it can now be inaccurate, the Logs page is no longer in the business of ending games with expired time. That is left up to Game Courier itself, which remains more accurate than the Logs page.

The first thing I did after getting the site back online was modify Game Courier to add 11 days to any game interrupted by the downtime.

In line with what I was talking about earlier, I've begun work on a new include file called fairychess1. It is designed to work with the Abstract1 and Alfaerie1 piece sets, which include images of the same pieces. I noticed that these sets included the Vao without the Cannon, which seems pointless. I don't want to break old games, but I might consider replacing the Vao in these sets with some other piece. I still have to adapt copies of the Pawn code for Berolina Pawns, but the others were easy enough to do.

Game Courier originally started out without any support for rule-enforcement. It offered a way to play games by email by generating diagrams from FEN strings that could be included in URLs. When I started working on what became GAME Code, I started with commands for automating some tasks, such as moving captured Shogi pieces off the board. In time, it became a programming language with the ability to be used for rule-enforcement. Because of the way that the language was added into Game Courier, it always remained optional rather than required. Besides that, some games could be too complicated to program, and using Game Courier just as a dumb board server would allow them to be played despite that. It also turned out that some people were a lot more interested in creating and trying out new variants than they were in programming, and they went ahead and created lots of presets without any programming.

As a programmer, my own preference has been for programmed presets. H. G. is also a programmer and might feel similarly as I do about the advantages of having programmed presets. I do want to make it easier to create programmed presets, but I also consider it important to still allow unprogrammed presets. This precludes the option of putting default code in presets. However, it could be helpful to have a GAME Code include file that includes default functions for a wide variety of common pieces. Another thought is to write new include files to require some values to be set before they are included. By require, I mean they would exit with informative error messages if any of these values were not already set. This would give programmers who include them reminders about what values might need to be set differently than for Chess.

This would still require some willingness to do programming, but it would at least make it easier.

We have had some very active non-programmers making presets. While this page won't tell you which are programmed, you can go to /play/pbm/settings.php to get some idea of that. If interested programmers want to program games that haven't been programmed yet, that would be very helpful.

These look like they will work, but they could be optimized better. They repeat the same operations multiple times, and they don't evaluate the most common type of move first. Also, the first or in each, which is the one to be evaluated last, is unnecessary.

I don't know exactly what the issue is (and there could be more than one) but part of it seems to revolve around the fact that the rules for Bishop moves are complicated, and I've codified them nicely in subroutines "B" and "b", but the architecture seems to want the 1-line fn defs, which don't seem to support if-then-else, and my attempts to have a def B pass off to a gosub B doesn't seem to work either.

I tried out your Symmetric Chess preset. The conversion rule seems to be enforced correctly, but conversion moves are not displaying as legal moves, and when a Bishop must convert, it is incorrectly displaying illegal moves as legal. As you correctly surmise, this is because you do not have the b and B functions defined.

While functions do not support if-then-else, as such, they do support cond, which works like the ? and : operators. They can also use and, or, nand, nor, onlyif, and unless. You can look at the functions for other divergent pieces, such as the Pawn or the Cannon, for examples of how to handle this. Here are some examples from chess3. If you understand the logic behind these, you should be able to figure out how to handle the Bishops conversion rule.

def C cond cond empty #0 capture (not empty #1) (checkhop #0 #1 0 1) (checkride #0 #1 0 1) and #1;

def P
remove var ep
and < rankname #1 var bpr
and < rankname var ep rankname #1
and == filename var ep filename #1
and checkleap #0 #1 1 1
or and checkride #0 #1 0 1 == rankname #0 var wpr
or checkleap #0 #1 0 1
and empty #1
or and islower space #1 checkleap #0 #1 1 1
and <= distance #0 #1 var fps
and > rank #1 rank #0;

Remember that Game Courier evaluates functions from right to left, and many of the logical operators will work with either one or two operands. In the Pawn example, the logical operators are normally taking only one operand. When and receives a lone true value, it lets the function continue silently, but if it receives a false value, it returns a false value and exits. When or receives a lone false value, it lets the function continue silently, but if it receives a true value, it returns a true value and exits. If you still need more help, just ask.

Aside from trying to reconstruct the original Marseillais Chess, I would like to propose a game I might call Simplified Marseillais Chess, which is designed with programming it in mind. It would follow the rule of Balanced Marseillais Chess of giving White only one move at the start of the game, it would allow en passant capture only of a Pawn moved on the last part of a player's turn, it would have a turn end with one move if there were no legal moves to follow it, and it would work with normal stalemate and checkmate on a player's first move. I think those are the main differences from regular Marseillais Chess. Is there anything I have overlooked?

One more question remains. While the rules seem to allow for second-order stalemate when the King is not in check, what about when the King is in check? Should this count as checkmate or stalemate? From the understanding that checkmate is check plus stalemate, we could argue that check plus second-order stalemate is also checkmate. Or, we might argue that the ability to escape check, even if no follow-up move is possible by any means of escaping check, constitutes only stalemate. Here's an example:

Here's an example of what I'm calling a second-order stalemate. Black is not in check but has only one legal move.

For the sake of testing some endgame positions as I write the code, here is a game where I played both sides just to get a stalemate position.

I think I figured out how to interpret the rule in a way that uses stalemate but avoids the problem of letting a player deliberately move into stalemate. This is the interpretation that if a player does not have any combination of two legal moves, the game ends in stalemate at the very beginning of his turn. I could do it like this. After checking for regular check and stalemate in the Post-Game sections, I could try out the available legal moves to see if any are followed by legal moves, stopping as soon as I find at least one. For this, I would use a subroutine that returns false as soon as one legal move is found and does not take the time to go through all possible moves and calculate a list of legal moves. Since there are plenty of legal moves when lots of pieces are on the board, and a position without any combination of two legal moves would be most likely in a position with few pieces left, there should not be a heavy computational load for doing this.

I don't know if the interface already commits the user to the first move after he entered it. If not, and he can still take it back, you don't really have to do anything.

This comment popped up while I was writing my last one. The interface does not commit a user to a move until it is complete.

Whatever he does for the second move will be rejected as illegal, so sooner or later he will decide to try another first move.

That's how it currently works. A player without any legal move on his second move is unable to proceed and must go back and make a different move to complete his move. The problem comes in when a player has only one legal move, and that puts him in a position without any more legal moves. In that case, the player is unable to move at all, and all he can do is resign or wait for the clock to time out. I would rather have something cleaner than that.

Using the Zillions-of-Games version of Marseillais Chess by Young-Hyun Joo, I moved pieces until I got a position where one side used the first move to move into a position with no second move. When I tried to move again, it declared the game a draw.

While I generally don't like the idea of a player being able to draw a game by stalemating himself, it is also a difficult thing to do until the endgame, and giving each player two moves should normally allow the player who is ahead to force checkmate all the more quickly. So, in this game, it may mitigate the greater advantage of the player who is ahead and give the player who is behind greater hope of being able to draw the game without really making the game too drawish.

This rule comes from a reading of Pritchard, and given how he mangled all of my games that ended up in the revised version of his Encyclopedia, I don't trust him. But he is also the only source I have. I would like to find the article written by Fortis, but it may not be on the web. Since I don't have a serious objection to it, and since it is computationally less expensive than some other options, I'll probably go with it unless someone has a more authoritative historical source than Pritchard.

Checking how en passant works in the same Zillions script, it works as I have programmed it except that it allows the capture of two pieces when a piece has moved to the space a pawn just passed over with its double move. I suspect that if capturing two pieces at once were allowed, this would have been mentioned explicitly in the rules. My interpretation is that since en passant means "in passing," the idea is that an en passant capture happens during the pawn's move and not after another move. In that case, the new piece would not yet be on that space when the en passant capture actually happens, and a double capture would not be possible then. Given this, a pawn who captured by en passant on that space should itself be captured, leaving the piece that moved to that space still standing. But this would overcomplicate the game, and it is easier to say that moving the piece there caused the enemy pawn to lose its chance to capture by en passant but compensated for this by giving it another piece to capture. So, I don't support allowing double captures.

I hadn't thought of that interpretation, but it is more computationally complex than the ones I was considering. It would involve testing a position for legal moves, then trying out each legal move and testing it for legal moves until at least one legal move is found. Also, I normally handle checking for stalemate in the Post-Game sections to minimize its computational cost, but if a move were to be illegal if it had no follow-up move, the code would have to check for double levels of stalemate in the Post-Move sections, and that would significantly raise the computational load of the code.

The two interpretations I was considering were to allow only one move when no second move is legally available or to end the game in a draw when a second move is not available. Another alternative would be to end the game as a loss for the player who does not have a second move available. This would discourage players from deliberately stalemating themselves just as well as making it illegal would, and it could be done with far less computational complexity.

What I cannot imagine is that the original inventor would have thought it reasonable to allow e.p. capture

1. when the capturing Pawn has not seen the other one move past it
2. when the Pawn that moved is no longer there
3. when the e.p. square gets occupied

That's all reasonable, and what I've coded for Game Courier is in conformity with it. The first one is already handled by the rule that en passant is not allowed on the second move unless the player is making two en passant captures. This prevents a player from using his first move to move a Pawn into position to do an en passant capture. (Note that a Pawn that was already in the position to do this could just capture the double-moved Pawn normally and then use its second move to go to the space the now captured Pawn had passed over, reaching the same position without using en passant.)

The second is handled by setting the ep1 variable to false whenever a player moves the same Pawn again. Since ep1 would store the position of the previously moved Pawn if the last move were a Pawn move, it checks whether the second move is from that location.

The third is handled by checking for a normal capture before checking for other types of Pawn moves. If the move is a normal capture, it never gets to the code for en passant. If it's not a normal Pawn capture, then the move was to an empty space. By the time it reaches the elseif clause for en passant, it has already been determined that the space is empty.

So if the player moved a pawn two spaces and the placed a piece on the square passed over you would allow capture of both with a single move? 

The way it is coded, that would not happen. The first thing it checks for is an ordinary diagonal capture. If the move involves one, that's what it does, and it doesn't get around to checking for an en passant move.

I have started to look at the thread you provided a link to, and I will continue to look at it tomorrow.

The earliest source I can find is Pritchard's 1997 Encyclopedia, which is the source Hans originally used to write this page. It says "En passant is legal if the opponent moved a pawn two squares on either of his moves but the capture must be made at once. However, if the opponent made two two-square pawn moves, both pawns can be taken e.p. This last rule is credited to Alekhine by F. Palatz in an article on the subject (LEC Sep 1928)." LEC refers to L'Echiquier. Notably, Alekhine is not one of the inventors, and how the game should handle en passant might be something that the original inventors didn't think of. It is also unknown whether the game was invented by Fortis or by de Queylar. It has been attributed to each one, but its origins are murky.

Regarding one of the alternative rules, it says "The game was sometimes played with alternative rules: a check on the first move was illegal and a player could not capture e.p. if the pawn had been moved in the first part of the player's turn." It's very possible that Fortis and de Queylar invented similar games with slightly different rules that eventually got conflated together.

The rule that Greg Strong and H. G. Muller propose has the advantage of being the simplest to program. It works with code that has already been written for Chess. Of course, the original inventor of the game would not have had this in mind, since programming games was not an option when it was invented. However, the rules as initially described above can be programmed, and that's what I have done in Game Courier. The only issue with them is that they need emendation for a Pawn that moves twice on the same turn. If we keep those rules, then en passant capture should be impossible in this instance, or it should be allowed for the Pawn on its new space. I have the former programmed right now, whereas the latter would be trickier to program.

I changed it to allow en passant only when the Pawn's double move is a player's second move, and I confirmed that this change did not break any past game. But as I was rewriting the rules, one more thing occurred to me. Suppose a Pawn's double move done on the first move puts a King in check, thereby ending the turn without a second move. If this check could not be ended with an en passant capture, this could allow a King to be checkmated in a position that would not be checkmate in Chess, and this would violate the intention behind the game.

So, I think we have to exclude the rule that en passant is allowed only when a Pawn makes a double move on the second move of the turn. This could be replaced with the rule that en passant is allowed only when the double move was the opponent's last move, or it could be replaced with the rule that en passant is allowed only when the Pawn that made a double move didn't make another move after it. For the meantime, I'll change it back to the latter.

While fixing a bug in the Game Courier code, I came across a situation that is not clearly covered by the rules. Suppose a Pawn makes its usual first-move double move, then it moves forward one more space on the same turn, so that it moves a total of three spaces forward. Can it be captured by en passant if the opponent has a Pawn in the usual position? On the one hand, it has made a double move, and a Pawn that makes a double move can normally be captured by en passant. On the other hand, it is no longer on the space it moved to when making its double move, and if the player had wanted to, he could have moved the Pawn forward one space, then captured the Pawn that was in a position to capture it by en passant if it had made a double move.

For now, I have written the code to forbid en passant capture in this situation. Does anyone know if there is any precedent for allowing en passant capture in this situation?

It was preserving the value of $pastmoves after prepending it to the value of $moves, which caused it to be prepended again with a double move. To fix this, I set both $pastmoves and $_POST["pastmoves"] to the empty string after prepending its value to $moves. I had to set the latter to it, because I was using a function called copyformdata(), which recreates the form data from the previous form.

Show me the series of moves that led up to the position in Extra Move Chess that revealed this problem.

Looking at your code, I found continuemove in the Post-Game sections, and I found askpromote in some of your subroutines. These are the only parts of your code that I would expect to be able to update the moves the player entered. I'm not sure that continuemove works properly in the Post-Game sections. At least I've been using it in the Post-Move sections instead. In the Post-Game section, you're asking it to continue a move that has already been completed, and that may be a problem. But I would have to experiment with it to say for sure. Unfortunately, looking at my code for it doesn't give me any insight into what to expect.

se 3f-4e; se 3f-4e;

This might be what is illegal. You are making the same move twice in a row. When you repeat the same move you just made, the se piece has already moved from 3f, and that space should now be empty. 

I just made some more fixes to how the King's two-step leap is handled in the stalemated subroutine, so that only legal moves are displayed.

With en passant, the bpr variable for Black's Pawn Rank had the wrong value. For the King's two-space leap, it was checking whether the destination was empty, which works only for potential moves, rather than checking whether a capture had been made. I have fixed these now, and you can test whether anything is still not working.

Although I haven't got a response to my ticket, and the host still says "Virtual server not found", things do appear to be working again.

As far as I can tell, there is a problem with the server. It is somehow partly online and partly offline, and it is also affecting my blog, which has its own domain. I have submitted a ticket about this to the hosting service, and they will hopefully do something about it.

Testing again. The host says " Virtual server not found ", but pages are showing up, and I was able to log in. I haven't been able to move in Game Courier all day. I get 520 errors when I try to, but I've seen that other people have moved today.

Testing.

That's now fixed. The settings file was an old one with some obsolete settings. It had $orientation set to "White", but setting this variable is no longer allowed when creating a new preset. I changed its value to "auto", which is the default. I'm now going to look into how I still use this variable.

That was indeed the problem. You castled by moving your Rook to the King's space, which was done as a Rook move, but castling this way did not include any code for updating the variable storing the King's position. There was an add command for moving the King, but it needed to be followed by a set command that otherwise looked the same. I have now added the appropriate set commands, and you can now capture the Bishop with your Pawn.

Sunday is March 3rd.

I have made good progress toward making a rule-enforcing preset for Metamachy. The last thing to do is to enable Black to place pieces before White moves. Game Courier is not currently set up to allow anyone to do anything before the first player moves. One way to handle this would be to give the first move to Black, but this would involve inverting the board, switching the sections coding for each side, and listing White as the second player in the movelist. I would rather avoid all that, but that means working out a way to allow the second player a pre-game move.

The second link is wrong. It contains the string "{$userid}" instead of the value of the $userid variable. From what page are you getting this link?

This hasn't happened to me. Keep track of the page you were on when this happened, and get back to me with this. Also, make sure the problem is not simply that it is not currently your turn in any game.

The rule is borrowed from Xiangqi, but since that game doesn't include the Immobilizer, appealing to it alone cannot resolve this question. I think the usual rule in Xiangqi is that Generals may not occupy the same file with nothing in between them. But when it comes to programming Xiangqi, the simplest way to code for this is to give each General the power to capture the enemy General as a forward-moving Rook. Since they cannot move into check, this never actually results in one capturing the other, and it functions the same as a ban on occupying the same file with nothing in between.

Since the Immobilizer comes from Ultima, we might look to that game to resolve this question. Can a King occupy a space adjacent to an immobilized King in Ultima? More generally, does an Immobilizer eliminate the checking power of a piece or simply its powers of movement? Our page on Ultima does not address this issue, but Pritchard does in Popular Chess Variants. He writes, "An immobilized king can be mated by its rival moving next to it." Using this as a precedent, it looks like the Immobilizer does eliminate the checking power of a piece, and this would allow an immobilized king to be checked by the enemy King.

However, the one thing that could be said against this interpretation is that Glenn Overby writes in the "Rules of Play":

The King may never be on the same file/column as the enemy King, if there are no pieces of either color in between them.

My point here is that it is being described as a rule of the game, not simply as a description of how the King moves. This rule might be understood to override the ability of the Immobilizer to rob a piece of its checking powers. Ultimately, this may be something for Glenn Overby to rule on.

I'm interested. I was also thinking about going with Metamachy instead of Perfect 12. It seems to be a more recent evolution of Perfect 12. Perfect 12 does not appear in the "Chess Variants on very large boards" section of Cazaux's website, and that section begins with the statement "I consider that these variants are now surpassed by METAMACHY." So, I expect that he favors it over Perfect 12. Although he does not list it in his Favorites section, we have already done Shako as you mentioned, and the other two were for design contests with unusual board sizes. There is already a bare preset for this game, but I could make one that enforces the rules.

Isn't it too early to cancel the tournament from a lack of interest? I haven't even seen a call to sign up for it yet. At present, I have just been waiting for the final lineup of games to take shape.

In the one with the infinite loop, there are complicated piece functions for the G and A pieces, and the N function has some more code in it. One of these functions might be at fault. I would recommend that you get the second one working, then introduce these functions back into the script one at a time and see what happens. I do not think that anything in the post-move code is involved in the infinite loop, since it happens before I have the opportunity to make a move. But to rule that out, you could try deleting the post-move code temporarily to see if it makes a difference.

When I try to use the first preset, it repeats "Please report any bugs or errors to Fergus Duniho" on the screen endlessly. In looking more closely at the code, I see that they are not the same. I guess I was not using the Compare plugin properly. I've tried it again, and this time it is showing differences. But I have not determined what is causing this infinite loop.

When I tried to move a Pawn in the second preset, I got the error "Call to P subroutine got misrouted."

Looking at your code as it is displayed below the error message, I do not see a P subroutine defined anywhere. So, it appears to be calling a subroutine that is not defined in your code. Looking at the code you have written in your pre-game section, you have include chess3 commented out. This is the include file that would have the P subroutine defined in it. So, including it should eliminate this error.

Returning to the code displayed below the error message, this code is properly indented, and anywhere the indentation seems incorrect, you may find an error. On line 85, you have an endif without a semicolon after it. You have the same error on line 114.

By doing automated comparisons with the Compare plugin for Notepad++, I determined that the code in these two presets are the same. Although you say that they display legal moves, they do not. They presently lack any post-game code, but that is where code for recording the legal moves should go. What errors in particular have you been seeing?