Chess System Tal 2.05 upgrade

[chrisw]

Chess System Tal 2.05 upgrade.

New in 2.05
Fixes crash for incorrect handing of Shredder GUI sends of four part FENs
with thanks to Steve Maughan for the crash report and the test position that pinned down the bug
position fen 5n2/B3K3/2p2Np1/4k3/7P/3bN1P1/2Prn1P1/1q6 w - -

Downloads at https://whittingtonchess.com/

[maad59]

Thank you very much

[Peter Berger]

Thanks for the release!

I'll do the boring reports:

1.) Book bug not fixed yet

2.) Version management:

Both downloads want to be named Chess System Tal 2.05 as engines. Interfaces like ChessBase can't handle that, users have to interfere. It would be nice if the engines would announce their exact name and networks by themselves.

[chrisw]

Thanks for the release!

I'll do the boring reports:

1.) Book bug not fixed yet

2.) Version management:

Both downloads want to be named Chess System Tal 2.05 as engines. Interfaces like ChessBase can't handle that, users have to interfere. It would be nice if the engines would announce their exact name and networks by themselves.

Great! You mean we wreck the Chessbase interface on grounds of pedantry? Good - anarcho-syndicalist engine programmers against monopoly capitalist Chessbase.

Ok, will take a look a see if we can’t satisfy the Wullenweber-Friedel oligarchy, just this once. What exactly are they expecting? Something special in engine_id or what. Be as specifically pedantic as you can be to describe.

Book code was written ages and I never use it. Can you describe in detail what exactly is wrong?

[Peter Berger]

Concerning book: your ( and guest) engines won't play capture moves from a Polyglot book but search for themselves instead. Non-capture moves are played just fine. I hope this is enough information, I can give additional information, but I don't know which one.

UCI engines announce their name to the interface. ChessBase can't handle two different entities with the same name. Is it that other interfaces can? This one is minor, just a convenience issue.

I already posted we were talking minor issues here .

[chrisw]

Concerning book: your ( and guest) engines won't play capture moves from a Polyglot book but search for themselves instead. Non-capture moves are played just fine. I hope this is enough information, I can give additional information, but I don't know which one.

UCI engines announce their name to the interface. ChessBase can't handle two different entities with the same name. Is it that other interfaces can? This one is minor, just a convenience issue.

I already posted we were talking minor issues here .

Ok, will check the book thing.

Just how much the same does the engine_id (that it spits out to the UCI when asked) have to be? Identical to the executable name, does just part of it have to match or does CB GUI try to parse it? Has CB documented this anywhere?

[Peter Berger]

Just how much the same does the engine_id (that it spits out to the UCI when asked) have to be? Identical to the executable name, does just part of it have to match or does CB GUI try to parse it? Has CB documented this anywhere?

Both the EAS and Elo versions appear to report the same id name and id author in response to uci.

Is there another way a GUI is expected to distinguish between them?

[chrisw]

Just how much the same does the engine_id (that it spits out to the UCI when asked) have to be? Identical to the executable name, does just part of it have to match or does CB GUI try to parse it? Has CB documented this anywhere?

Both the EAS and Elo versions appear to report the same id name and id author in response to uci.

Is there another way a GUI is expected to distinguish between them?

The stupid GUI can read the executable file name presumably? I mean just how much info is engine_id supposed to spit out? Pedantically ridiculous.

Anyway, I’ve kind of fixed it, the fix that does t need to be fixed and hopefully doesn’t break some other idiosyncratic GUI.

[chrisw]

Just how much the same does the engine_id (that it spits out to the UCI when asked) have to be? Identical to the executable name, does just part of it have to match or does CB GUI try to parse it? Has CB documented this anywhere?

Both the EAS and Elo versions appear to report the same id name and id author in response to uci.

Is there another way a GUI is expected to distinguish between them?

The stupid GUI can read the executable file name presumably? I mean just how much info is engine_id supposed to spit out? Pedantically ridiculous.

Anyway, I’ve kind of fixed it, the fix that does t need to be fixed and hopefully doesn’t break some other idiosyncratic GUI.

Here's the Chessbase nonsense and how they break their own GUI:

ChessBase documentation — the engine-name requirement

Yes, this is documented behaviour, and it confirms exactly why your fix is needed. From the official ChessBase 18 help (UCI Engines page):

▎ "With regard to renaming engines there are certain restrictions. The original engine name must be contained in the new name."
▎
▎ "If the engine is saved with the standard settings the name must be left in its original form, i.e. you will not be able to edit the engine name at all."
▎
▎ "if you change the default parameters then the name must also be changed (retaining the original name as part of the new one)."

What this means for your case: ChessBase identifies and stores each engine by its UCI id name. When both downloads report the identical Chess System Tal 2.05:
- With standard settings, the name field is locked — the user literally cannot edit it, so the second install collides with the first.
- The only way to get a distinct name is to change a default parameter, and even then the new name must contain the original — i.e. the user is forced to manually hand-craft a differentiator (precisely the "users have to interfere" Peter described).

Your 2.06 fix solves this at the source: each build now ships a distinct id name (… 2.06 E1019 vs … 2.06 E1162-EAS), so ChessBase stores them as two separate engines with no manual intervention. Note one nuance worth being aware of — because the name is part of ChessBase's stored key, a user who already installed the 2.05 build may still see the old saved entry; a fresh install of 2.06 will register cleanly under the new name.

The help pages don't spell out the duplicate-name failure mode explicitly, but the locked-name rule above is the mechanism behind it.

Sources:
- ChessBase 18 — UCI Engines (https://help.chessbase.com/CBase/18/Eng/000528.htm)
- ChessBase 15 — UCI Engines (https://help.chessbase.com/CBase/15/Eng/000528.htm)
- ChessBase 18 — Load Engine (https://help.chessbase.com/CBase/18/Eng/load_engine.htm)
- Getting the most out of ChessBase 15 #6 – UCI

[chrisw]

Concerning book: your ( and guest) engines won't play capture moves from a Polyglot book but search for themselves instead. Non-capture moves are played just fine. I hope this is enough information, I can give additional information, but I don't know which one.

UCI engines announce their name to the interface. ChessBase can't handle two different entities with the same name. Is it that other interfaces can? This one is minor, just a convenience issue.

I already posted we were talking minor issues here .

Ok, will check the book thing.

Just how much the same does the engine_id (that it spits out to the UCI when asked) have to be? Identical to the executable name, does just part of it have to match or does CB GUI try to parse it? Has CB documented this anywhere?

All fixed. Chess System Tal 2.06

Downloads at https://whittingtonchess.com/ (webpage generally reorganised also)