Also, Daniel Zacharias found that if you enter King moves manually, it works fine.
The King's legal moves were highlighted for the first player, but they were not for the second player. After I moved the King manually, it declared check. Considering how your pieces move, this seems inaccurate. All I did was move each King forward to file 6.
He thinks the problem may be in the stalemated subroutine. When I coded this preset, I removed the checkmated subroutine used in my other presets to simplify the code a bit. so that would make sense.
After the two King moves I mentioned, the only highlighted legal moves are to 5j, the space vacated by the King. After each one of these moves, it declared "Checkmate! Black has won!" When I tried other moves I expected to be legal, I could make them, but then it would declare Checkmate again.
Looking at your Post-Game code, I see lines for enforcing the rule against checkmating with a Pawn drop. Code for this should be handled by the stalemated subroutine, because it has to apply to potential moves, not just to actual moves. However, I don't think that code is responsible for the inaccurate estimates of check and stalemate.
Since it declares checkmate only when checked and stalemated both return true, there may be bugs in both, or there may be a bug in a function called by both, such as the definition of a piece move, or there may be a bug in checked, which is also called by stalemated.
Since the checked subroutine shows problems by itself, and it is also called by the stalemated subroutine, it could well be the problem. It works differently than the checked subroutine I have in the fairychess include file. It sets enemies to an intersection between noupper and #bpieces or nolower and #wpieces. However, there are no variables called bpieces or wpieces. There are only constants by these names, and these two constants are sequential arrays. However, noupper and nolower return associative arrays. So, an intersection would not give you the desired result.
I see the same error in your stalemated subroutine. You are trying to find an intersection between an associative array and a variable that does not exist, and the constant with its name is a sequential array anyway.
The King's legal moves were highlighted for the first player, but they were not for the second player. After I moved the King manually, it declared check. Considering how your pieces move, this seems inaccurate. All I did was move each King forward to file 6.
After the two King moves I mentioned, the only highlighted legal moves are to 5j, the space vacated by the King. After each one of these moves, it declared "Checkmate! Black has won!" When I tried other moves I expected to be legal, I could make them, but then it would declare Checkmate again.
Looking at your Post-Game code, I see lines for enforcing the rule against checkmating with a Pawn drop. Code for this should be handled by the stalemated subroutine, because it has to apply to potential moves, not just to actual moves. However, I don't think that code is responsible for the inaccurate estimates of check and stalemate.
Since it declares checkmate only when checked and stalemated both return true, there may be bugs in both, or there may be a bug in a function called by both, such as the definition of a piece move, or there may be a bug in checked, which is also called by stalemated.
Since the checked subroutine shows problems by itself, and it is also called by the stalemated subroutine, it could well be the problem. It works differently than the checked subroutine I have in the fairychess include file. It sets enemies to an intersection between noupper and #bpieces or nolower and #wpieces. However, there are no variables called bpieces or wpieces. There are only constants by these names, and these two constants are sequential arrays. However, noupper and nolower return associative arrays. So, an intersection would not give you the desired result.
I see the same error in your stalemated subroutine. You are trying to find an intersection between an associative array and a variable that does not exist, and the constant with its name is a sequential array anyway.