IMO it would be better to somehow mark the default value, e.g. It seems stupid (and a source of error) to have to repeat a value that was already given in the list before. The only thing I have doubts about is the -default in the -combo control. WinBoard would then use these options (when the user triggered this from a menu) by sending: Using 'var' as separator seems a very bad choice '-var' would already give a much better readability, but IMO '///' would be much clearer.įeature option="EGTB cache size -spin 0 8 4"įeature option="style -combo patzer /// very good /// world champion -default very good"įeature option="book -string C:\books\big.bin" But I guess there is something to be said for a multi-character separator, as it reduces the likelihood you would want this separater to occur as (part of an) argument. This coud be done by preceding each of them with 'var', as UCI does, but it would seem much more natural to me to separate them with a single reserved character unlikely to occur in the arguments. So the text that follows has to be parsed into individual values. Only for type combo there seems an issue: this has a variable number of text arguments, which could be space-containing. Type button does not seem to need additional information at all (unless I misunderstand what it does). For type string everything that follows (except the frirst space) can be nothing else but default value. Similarly, type check needs only a default, and could be followed by a single number 0 or 1. That makes the min, max and default keywords totally redundant in this option.
#Deep shredder 11 uci program size plus
The leading '-' plus the fact that there are only 5 types makes the type easy to recognize by the parser, and everything before it can automatically be identified as option name (in case it contans spaces).Īs for the 'additional info': I was told that for type spin in UCI the min, max and default parameters are mandatory. as UCI does just seems redundant: you need a reserved word anyway (type), so you might as well reserve spin and combo directly. Calling them 'type spin', 'type combo' etc.
![deep shredder 11 uci program size deep shredder 11 uci program size](https://i.paste.pics/9cef900727ed05358c0768edf5f61a86.png)
Where '-type' would be one of '-check', '-spin', '-combo' etc. And if keywords would be needed, I think it would be better if they were recognizable, e.g.
![deep shredder 11 uci program size deep shredder 11 uci program size](https://www.hiarcs.com/images/LoadEngineH11.jpg)
Why require keywords to specify a name or type is following, if a name and type have to be lways present? The order in which they come can identify them more efficiently.
![deep shredder 11 uci program size deep shredder 11 uci program size](https://content.syndigo.com/asset/53321c90-5aeb-4c1a-a5a9-feb892beb5d3/1800.jpeg)
The UCI syntax seems too silly to use, though. check, spin), and additional information depending on the type. The text string describing the option would then define the name of the option, the type (supporting all UCI types, e.g. This way of doing it does not break compatibility with older GUIs they would simply reject the feature. Where the only thing special compared to other features woud be that this feature can be sent multiple times and will then all be remembered (in stead of just the one that was sent last. Considering what has been said there, my current preference is to use the WB feature command to send the option to the GUI as a text string, as
#Deep shredder 11 uci program size full
The discussion did not come to a full conclusion yet. Some time ago we did discuss this possibility in another thread.