Well, backward compatibility comes at a price. If there would be some other way to do this that could also work (protover 3? Older engines that don't know about version 3 will just continue to send stuff in the version 2 format, which the GUI should be able to deal with, engines that do can send the new stuff if they're running on a protocol 3 GUI and refrain from doing it if they're running on a version 2 GUI).hgm wrote:As for the situation in 10 years, I think it would be exactly the reverse from what you worry about. The (optional) extension from 4 to 7 leading numbers would find its way in the specs, of course, and in 10 years no one would remember that it ever had been any different. By specifying that it could only be done after a feature, we would be stuck with another 'must have' feature forever.
I see them more as the engine telling the GUI "I support these options", or "I can tell you these things." If it's just about telling the GUI what it can send back, why are there "accept" and "reject" messages?It also seems kludgy use of the feature mechanism: features are intended to tell the GUI what it can send to the engine, not so much to control what an engine can send to a GUI. To control engine behavior there are engine-defined options.
As it is at the moment I always ignore those: I tell the GUI that I support setboard. If it accepts that, fine (but what do I care if it tells me so?), if it doesn't… well, I don't have "edit" so there isn't much I can do about it either way. So what's the point?
With that specification, all my engines will report table base hits, starting with 1 hit at the first move, 2 hits at the second move, 40 hits at move 40 and so on.I would be inclined to extend the specs for Thinking Output as follows:
proposed specs extension wrote:An arbitrary number of space-separated integers can be inserted behind the 4 obligatory integers and the PV, in which case the PV field is assumed to start behind the last tab character before any non-numeric token. The last number before the PV will indicate EGT hits in this case. When there are distinct numbers in positions 5 and later, they will represent selective depth, engine speed (in knps), hash-usage (0-99, in percent), CPU load (0-99, in percent), respectively. This list can be expanded in the future.
So that will still break backward compatibility. Of course, I write the numbers as "1. e4 e5", "1. … e5 2. Nf3" and presumably I would write TB hits as " 1 ", but I don't think this is a safe assumption in general.