Comments by FergusDuniho

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.

I made some more fixes to the King's two-space leap in the subroutines for moving the King. They now give informative messages about particular reasons why an illegal move is illegal. Since I used restore to check whether the King was in check, I went back to checking whether the destination space was empty.

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.

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

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.

As a test, I temporarily undid it, but the problems with these two logs remained. Each involves a Pawn moving twice on the same turn. I'll look into it further.

It specifically involves a Pawn moving one space forward after moving two spaces forward. Any other moves by the same Pawn are okay, and it's okay to move any other piece I've checked twice in a row.

The problem seems to be due to the ep1 variable being set. Since a Pawn's normal double move sets this variable, it is set when the Pawn is moving forward a second time, and it tries to evaluate it as an en passant move, which it isn't.

It is now fixed by adding the condition and != #ep1 #from to each line checking whether the move is an en passant move. This indicates that if the move is coming from the space previously marked as #ep1, it is not an en passant move.

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.

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.

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.

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.

One more issue has come up. Suppose that a player makes a first move that leaves him with no legal second move. Does this end his turn like a checking move would, or does it end the game in a draw? Pritchard says in Popular Chess Variants, "A player who is not in check and cannot complete his turn is stalemated." This suggests the latter, but he could have said it more explicitly if that is what he meant. Is there any consensus on how being unable to move on the second move should be handled?

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

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.

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.

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

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:

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?

Is there any French speaker here who can provide an accurate English translation of this? Google translate is not good enough to make it clear.

Les échecs marseillais sont une variante du jeu d'échecs où chaque joueur joue deux coups à la suite. En plus des règles du jeu normales, les joueurs doivent respecter les règles suivantes :

• Un joueur en situation d'échec doit parer l'échec au premier de ses deux coups.
• Si un joueur fait échec au roi au premier coup, il perd la faculté de jouer son deuxième coup.
• Si après avoir joué son premier coup, un joueur se trouve dans une situation où il lui est impossible de jouer un coup légal, il est déclaré pat.
• La prise en passant doit être effectuée au premier coup sauf si deux prises en passant sont possibles. Dans ce dernier cas, les deux prises en passant peuvent être effectuées à chacun des deux coups.
• L'avance de deux cases des pions depuis leur position initiale ne peut pas être considérée comme un coup double (avance de deux fois une case). Donc le joueur peut jouer ensuite son deuxième coup.

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.

Here are some optimized versions of the B and b functions:

def B 
== #0 c1 
and flag wccanconvert 
or and == #0 g1 flag wgcanconvert
and checkleap #0 #1 1 0
and empty #1 
or and checkride #0 #1 1 1 or color #0 nor flag wcmustconvert flag wgmustconvert;

def b
== #0 c8 
and flag bccanconvert 
or and == #0 g8 flag bgcanconvert
and checkleap #0 #1 1 0
and empty #1 
or and checkride #0 #1 1 1 or not color #0 nor flag bcmustconvert flag bgmustconvert;

These do the regular Bishop move first, because that's what the Bishop will do most of the time. This can be done when neither mustconvert flag is set or when the Bishop is on the opposite color from the one it starts from. So, if a White Bishop is on a dark square (color = 1), or a Black Bishop is on a light square (color = 0), it can move as a Bishop. Testing for color #0 is quicker than testing for == color #0 1, and testing for not color #0 is faster than testing for == color #0 0, though they are a little bit more obfuscated. With regular Bishop moves out of the way, the function uses a series of breaking conditions to test whether a conversion move is possible. It first tests for conditions common to both conversion moves, testing for the less expensive one first. Also, given that these functions will frequently be used in testing whether a Bishop is attacking a King, including empty #1 as the first condition of the conversion move saves it from the trouble of checking for anything else when used for that purpose. It then tests whether it is legally converting from the g square, and if not, it uses a series of breaking conditions to test whether it is legally converting from the c square.

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.

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.

I got some new ideas for how to make it easier for non-programmers to make programmed presets. I have abandoned fairychess1.txt in favor of fairychess.txt, which I'm using with the fairychess Chess preset. Instead of using functions with the names of piece labels, it uses functions with the names of pieces. Instead of defining functions with the names of piece labels, someone using this include file would just set varables to the names of pieces. These variables would be used as references to the functions. The main things left to do are to add functions for more pieces and to write some documentation and a tutorial on how to use it.

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.

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.

I didn't. I modified one script to make the appropriate adjustment when someone opens a log with Game Courier.

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.

It's not so much that it was based on code for Chess. Rather, it was based on code that had been adapted to handle en passant for initial pawn moves that are longer than two spaces. Since this game allows pawns unlimited double-moves instead, en passant had to be handled differently. Either way of handling en passant is compatible with Chess, but en passant has to be handled differently in Omega Chess than in Metamachy.

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 left out a semicolon when I updated the timeleft.php file earlier. So I fixed that and changed the time it discounts for the latest interruption to 6 hours.

Yesterday, I was issued a personal challenge that was automatically accepted. Wasn't given the option to decline invitation. Perhaps something to look into.

If this happens again, report the specific log and leave it alone, so that I can investigate it.

To quote from what I already wrote:

The other function has the same name with a capital L at the end

It looks like you named them correctly.

You shouldn't need to call them directly.  They are called from the Checked function if I recall correctly.

In the chess include file, they are used in the stalemated and checkmated subrroutines. To test for checkmate or stalemate, these subroutines calculate every possible legal move. When no legal moves are found, each of these two subroutines will return true. When any legal moves are found, they will return false. But instead of stopping with the first legal move, they will continue to calculate all legal moves, so that an array of legal moves can be created for use in displaying legal moves. To find all the legal moves for a piece, it checks whether each piece can make a legal move to each space that falls within its range of movement. That second function is used to create an array of destination spaces to check for legal moves to.

Zillions-of-Games will do things differently. It uses a single movement definition to calculate where a piece may legally move. Instead of knowing how a piece moves, the chess include file for Game Courier relies on knowing how to check whether a move was legal and on knowing which spaces it is worth the trouble to check for a legal move to. Although this requires two functions instead of one, the two functions will normally be simpler.

I found a link to All the King's Men in a guide by David Howe. Unfortunately, it just gives the name and description with no further information.

Using the bash shell in Windows 10, I did a grep search on every issue of Variant Chess, and I didn't find any mention of Banshee. I did another search for Nightrider just to make sure I was doing it correctly, and I got a list of results. Since Jelliss's page is dated even later than Betza's and Paulowich's use of the piece, it's still unknown whether the piece goes back any further than Betza's game in 1995.

It doesn't look like you've done anything to change how castling works, and by default, the rook will move to the other side of the King when castling. Note that changes to variables set in the include file should be made after it has been included. Otherwise, the values set in the include file will overwrite the values you've already set.

I have removed $countextrasas from the system variables. It was not used in any settings file, and I could not figure out what it was for. My comments on it were not informative enough. I commented out the code that used the variable, since it appeared to be useless.

The hyphen is in Spider-rider to separate the two adjacent r's.

I have added to the fairychess include file the Shogi and CWDA pieces that weren't already in it.

There are two levels of caching. One is browser caching, and the other is caching at the DNS/CDN level. The latter is handled by Cloudflare, and it reduces the server load quite a lot, which keeps this site quicker and more stable. I am able to control caching through page rules, but my free Cloudflare account gives me only three page rules. I have two rules right now. One disables caching for pages with a .php extension, and the other enables caching for the drawdiagram.php script, which is used for graphics. I can purge the cache for individual pages as needed, but I need to be asked to do that for a particular page. Complaining about caching in general will not help.

I cannot control Cloudflare through scripts on this site. I have one page rule left. I could use it to disable caching on your script or on the directory it is in.

I set the rule to bypass the cache for https://www.chessvariants.com/membergraphics/MSinteractive-diagrams/betza.js. There might be a way to purge the cache with a script, but I have not studied the Cloudflare API well enough to know how to proceed with that, and I don't know anything about using Curl. I normally just log in to Cloudflare's website and do it manually from there. I have also just increased the caching time from 4 hours to 3 days, so that HTML pages will stay up when the server goes down.

As I mentioned to you not too long ago, the script used to draw this picture is cached by Cloudflare. Also, the previous diagram had ranks broken into two rows and looked really bad.

Server load rarely gets very high, and the rare peak of high server load does not correlate with the site going down. So, even though tables could also work, I'm not worried that using single images will increase the load too much. Also, it has been simple enough to replace various JavaScript diagrams with generated images, because I could reuse the FEN string from the JavaScript with only occassional modifications.

Since the userid is limited to 16 characters, and ChessVariantDemos has 17, I could not make the change. Note that you have two different IDs on this site, though both are presently the same for you. These are the personid, which is limited to 32 characters, and the userid. The userid is the handle that you use to sign in, and it is also used when you play games on Game Courier. The personid is used to identify you when you post comments or contribute content. This site was using personids before userids were ever a thing here, and the original personids were based on a person's name, such as DavidHowe or FergusDuniho. Userids were meant as shorter handles for signing in. I could change your personid to ChessVariantDemos, though one based on your name would be preferable.

I have updated the presets on this page to use the new fairychess settings file, which uses the new fairychess include file. I tested it on several completed games, and I tested illegal moves. It seems to be working fine. The advantage of this new settings file is that it will refer to pieces by name, and it will include a description of how a piece moves when it makes an illegal move. I changed the default graphics for this settings file, and I have left the old settings file alone. If you want to compare the old one with the new one, you will find the old one at

https://www.chessvariants.com/play/pbm/play.php?game=Chinese+Chess&settings=GB-set