Re: On-line engine blitz tournament September

[Joost Buijs]

Works perfectly with jshriver's adapter.

Folkert, thanks for the info!

Each time we encounter incompatibilities they will be fixed. I still have a copy of ChessPartner somewhere in a backup, so I will test that one locally.

[jshriver]

Works perfectly with jshriver's adapter.

I've done some updates and pushed a new release v2.1.5 which now includes a GUI. I've tested it and have not had any issues, but feel free to let me know if there are any. Be mindful of the new config changes. GUI: "Yes" to enable it. Tested it in Linux and Windows and both worked well, I dont have access to a Mac.

https://github.com/jshriver/icsdrone-rs

Cheers!
-Josh

[flok]

Works perfectly with jshriver's adapter.

I've done some updates and pushed a new release v2.1.5 which now includes a GUI. I've tested it and have not had any issues, but feel free to let me know if there are any. Be mindful of the new config changes. GUI: "Yes" to enable it. Tested it in Linux and Windows and both worked well, I dont have access to a Mac.

https://github.com/jshriver/icsdrone-rs

Looks pretty! I love it!
Suggestion(!): mark moves in the movelist maybe with a different color or so if they're from the openingbook.
Connecting with gui mode takes slightly longer than in the tui, is that correct?

Oh and a resign button for painful positions like this would be cool



Noticed a strange error:



and here the score is negative but the graph looks positive:



And maybe include the score and time used in the pgn?

Like:

Code: Select all

10. Qc2 {+0.59/9 0.271s, n=642321} O-O {-0.87/11 0.276s, n=665731}

It takes a bit for the openingbook to load (1.7 GB), that is visible in the tui but not in gui - in the gui it looks like it is connecting to the peer but taking long.

Last suggestions: filter the empty "fics%" lines in the gui and add a timestamp (milliseconds) in the logging window.

[Bart Weststrate]

Works perfectly with jshriver's adapter.

I've done some updates and pushed a new release v2.1.5 which now includes a GUI. I've tested it and have not had any issues, but feel free to let me know if there are any. Be mindful of the new config changes. GUI: "Yes" to enable it. Tested it in Linux and Windows and both worked well, I dont have access to a Mac.

https://github.com/jshriver/icsdrone-rs

Cheers!
-Josh

Joshua there is a "bug" that breaks the uci covention: is sends fens in stead of [position startpos] move move move... so the engine never can detect a draw by repeating position. Remember that a uci engine is stateless where a winboard engine is not.

According to Claude:

Bug: engine never sees real game history, breaks its own repetition detection/avoidance

Every turn, the bot sends the engine only the current position as a bare FEN, with no move list: self.engine.set_position(&fen, &[]).await?; in app.rs's handle_style12.

A FEN has no memory of earlier positions. UCI engines detect threefold repetition using the move list given via position fen <X> moves <m1> <m2> ... — that's how they build their own Zobrist-key history. Since the bot always sends an empty move list, the engine has no idea it has seen any of the game's earlier positions; every turn looks like move one of a brand-new search.

Observed symptom: a rated blitz game where White (our engine) had a kibitzed advantage of roughly +1.00 pawn, then shuffled a knight/rook/queen and let the game end in an avoidable threefold-repetition draw (full PGN included in the file). This isn't the engine "choosing" a draw — each turn it independently re-derived the same shuffling move with zero awareness the position had already occurred, because it was never told.

Root cause: the code's own comment calls this deliberate — "simpler than the original's incremental SendMovesToComputer/SendBoardToComputer bookkeeping." That simplification is the bug; the original's incremental tracking is what gave the engine real history to reason about.

Suggested fix: track real UCI moves since game start (or since joining mid-game) and send position fen <base_fen> moves <m1> ... <mN> every turn instead of a bare current FEN, watching for FICS takebacks (truncate/overwrite, don't append). pgn.rs's record_move already has this exact truncate-and-resync pattern for SavePGN, just keyed on SAN — same approach applies. One wrinkle: style12's last_move_verbose field isn't UCI notation and needs translating (promotions need the piece suffix; castling needs the king squares reconstructed since style12 gives no squares for O-O/O-O-O).

---
For what it's worth, I already applied this exact fix to our local build, so your bot plays correctly now — this report is just to get it fixed upstream too.