Hello Ludii developers,
I'm working on a refactored version of Kriegspiel (chess) designed for a constrained and AI-ready user interface, and I've encountered some very persistent and critical bugs that appear to be related to the core engine's state management and expression evaluation. These issues are making it impossible to correctly arbitrate the game, especially concerning illegal move tracking.
The core objective of my refactoring is to provide the player with a filtered list of pseudo-legal moves (geometrically correct and not previously attempted and declared illegal in the current turn), while the engine acts as an umpire, declaring moves legal or illegal based on the true, hidden board state. I've performed extensive debugging and logging within the Ludeem code, and my findings strongly suggest fundamental inconsistencies in how Ludii's engine handles certain values and expressions, especially within moveAgain contexts after illegal moves.
The primary issues observed are:
RememberValue Failure:
Problem: The RememberIllegalMove macro (which uses (remember Value ...)) is designed to add a failed move attempt's ID to a player's blacklist (IllegalMovesP1/P2). However, the value actually stored by RememberValue is often incorrect. It frequently stores -1, or an ID from a previous illegal move, or a value that doesn't match the one passed to it.
Evidence from Logs: My logs show instances where (set Var "IllegalMoveID" (+ (* (#1) 100) (#2))) correctly calculates the Move ID (e.g., 1625), but the subsequent (remember Value ... (var "IllegalMoveID")) stores a different value (e.g., 3526 or the ID of the previously attempted illegal move). This was consistently observed even when breaking down the calculation into multiple set Var steps, indicating a deeper issue with set Var and remember Value themselves. For this reason the UI's blacklist is ineffective, allowing players to repeatedly attempt the same illegal move, and the AI cannot learn from its failed attempts correctly.
General Inconsistency of (last From) / (last To) and Arithmetic Evaluation:
Problem: The values of (last From) and (last To) appear to be unstable or "stale" when accessed in specific contexts (especially within (then ...) blocks after an illegal move and moveAgain), leading to incorrect results from arithmetic operations like (+ (* ...)).
Evidence: Debug logs show that while (last From) and (last To) might appear correct when simply note-d, using them in calculations for set Var results in unexpected values (-1, or previous move's coordinates). This was demonstrated even after trying to store them in intermediate set Var variables.
To easily reproduce the bug:
Start a new game with the provided Ludeem code.
As Player 1, attempt several illegal pawn diagonal captures (e.g., try moving your pawn from A2 to B3, then to C3, etc., where there are no opponent pieces). These moves are geometrically correct for capture but are illegal because no piece is present.
Observe the debug notes. The note "DEBUG: Contents of 'IllegalMovesP1' after addition:" will clearly show that being added to the blacklist is the ID of a previous illegal move attempt in that same or previous turn, instead of the ID of the current illegal move. This highlights the handling of parameters inconsistency.
I'm attaching the full Ludeem code for my Kriegspiel variant (it is a text because github doesn't allow .lud uploads). Any help or insights from the developers would be greatly appreciated. Thank you!
Kriegspiel2.lud.txt
Hello Ludii developers,
I'm working on a refactored version of Kriegspiel (chess) designed for a constrained and AI-ready user interface, and I've encountered some very persistent and critical bugs that appear to be related to the core engine's state management and expression evaluation. These issues are making it impossible to correctly arbitrate the game, especially concerning illegal move tracking.
The core objective of my refactoring is to provide the player with a filtered list of pseudo-legal moves (geometrically correct and not previously attempted and declared illegal in the current turn), while the engine acts as an umpire, declaring moves legal or illegal based on the true, hidden board state. I've performed extensive debugging and logging within the Ludeem code, and my findings strongly suggest fundamental inconsistencies in how Ludii's engine handles certain values and expressions, especially within moveAgain contexts after illegal moves.
The primary issues observed are:
RememberValue Failure:
Problem: The RememberIllegalMove macro (which uses (remember Value ...)) is designed to add a failed move attempt's ID to a player's blacklist (IllegalMovesP1/P2). However, the value actually stored by RememberValue is often incorrect. It frequently stores -1, or an ID from a previous illegal move, or a value that doesn't match the one passed to it.
Evidence from Logs: My logs show instances where (set Var "IllegalMoveID" (+ (* (#1) 100) (#2))) correctly calculates the Move ID (e.g., 1625), but the subsequent (remember Value ... (var "IllegalMoveID")) stores a different value (e.g., 3526 or the ID of the previously attempted illegal move). This was consistently observed even when breaking down the calculation into multiple set Var steps, indicating a deeper issue with set Var and remember Value themselves. For this reason the UI's blacklist is ineffective, allowing players to repeatedly attempt the same illegal move, and the AI cannot learn from its failed attempts correctly.
General Inconsistency of (last From) / (last To) and Arithmetic Evaluation:
Problem: The values of (last From) and (last To) appear to be unstable or "stale" when accessed in specific contexts (especially within (then ...) blocks after an illegal move and moveAgain), leading to incorrect results from arithmetic operations like (+ (* ...)).
Evidence: Debug logs show that while (last From) and (last To) might appear correct when simply note-d, using them in calculations for set Var results in unexpected values (-1, or previous move's coordinates). This was demonstrated even after trying to store them in intermediate set Var variables.
To easily reproduce the bug:
Start a new game with the provided Ludeem code.
As Player 1, attempt several illegal pawn diagonal captures (e.g., try moving your pawn from A2 to B3, then to C3, etc., where there are no opponent pieces). These moves are geometrically correct for capture but are illegal because no piece is present.
Observe the debug notes. The note "DEBUG: Contents of 'IllegalMovesP1' after addition:" will clearly show that being added to the blacklist is the ID of a previous illegal move attempt in that same or previous turn, instead of the ID of the current illegal move. This highlights the handling of parameters inconsistency.
I'm attaching the full Ludeem code for my Kriegspiel variant (it is a text because github doesn't allow .lud uploads). Any help or insights from the developers would be greatly appreciated. Thank you!
Kriegspiel2.lud.txt