Banksia GUI still very buggy

Moderators: AlexChess, TedSummers

Post Reply
pham
Site Admin
Posts: 106
Joined: Sun Oct 03, 2021 3:08 pm

Re: Banksia GUI still very buggy

Post by pham »

When an engine is time out, BSG will wait for a period of that margin before ruling the game. If the engine could return a result within that period, the game could be continued, otherwise it will be terminated and that engine will be ruled as a loser (forfeited by timeout).

Margins can help to avoid some delays/lagging between network or communicating between engines and chess GUIs or solve the problem with some engines use all allowing time for calculating and no time left for communicating/lagging.

For standard timers, that extra period is still counted (subtracted from time lefts).
RubiChess
Posts: 14
Joined: Sun Dec 19, 2021 11:54 am

Re: Banksia GUI still very buggy

Post by RubiChess »

Two more problems (tested with latest 0.58 but also in older releases)
1. In settings / general the "score in white view" option isn't an option anymore but seems to be part of the radio button group. Means: If you enable "score in white view", neither "pawn unit" nor "centipawn" are selected. And if you select one of them, "score in white view" gets disabled again. This is probably not intended.
2. If you run an analysis of a game (like 10 seconds per move) the eval graph isn't updated. You have to move the banksia window or resize (or close/opn) the score graph dock to get the latest eval dots. Tested under Windows 10.

Regards, Andreas
pham
Site Admin
Posts: 106
Joined: Sun Oct 03, 2021 3:08 pm

Re: Banksia GUI still very buggy

Post by pham »

Thanks. All those bugs are fixed for the next release.
RubiChess
Posts: 14
Joined: Sun Dec 19, 2021 11:54 am

Re: Banksia GUI still very buggy

Post by RubiChess »

Long time no bug report... here it comes:
Banksia sends "isready" after setting the options but it doesn't wait for the engines answer "readyok". Instead it directly sets the position and starts the game.
Option setting can take some time (e.g. setting the hash needs clearing the momory which takes some time) and exactly for this the synchronisation via isready/readyok should be used. See https://backscattering.de/chess/uci/#gui-isready

Here is a log of a tourney that uses concurrency 7 so in the very first round 14 engines including setting their options are started in parallel. This results in losing more than 4 seconds on the first move:

Code: Select all

5.15:09:50 RubiChess current Clang> uciok
5.15:09:50 RubiChess current Clang< setoption name Hash value 256
5.15:09:50 RubiChess current Clang< setoption name Move_Overhead value 10
5.15:09:50 RubiChess current Clang< setoption name Ponder value false
5.15:09:50 RubiChess current Clang< setoption name Threads value 1
5.15:09:50 RubiChess current Clang< isready
5.15:09:50 RubiChess current Clang> info string Allocation of memory uses large pages.
5.15:09:50 Komodo 14.1 64-bit< ucinewgame
5.15:09:50 RubiChess current Clang< ucinewgame
5.15:09:50 RubiChess current Clang> info string Allocation of memory: Large pages not available for this size. Disabled for now.
5.15:09:51 RubiChess current Clang< position fen r1bqk1nr/pppp1ppp/2n5/2b1p3/2B1P3/5N2/PPPP1PPP/RNBQK2R w KQkq - 0 2
5.15:09:51 RubiChess current Clang< go wtime 300000 btime 300000 winc 1000 binc 1000
5.15:09:54 RubiChess current Clang> readyok
5.15:09:55 RubiChess current Clang> info depth 1 seldepth 2 multipv 1 time 1 score cp 20 nodes 36 nps 27341 tbhits 0 hashfull 0 pv b1c3
Post Reply