Reporting errors in UCI

[niel5946]

Hi everyone

I am currently trying to figure out a way to embed my neural network binaries into the generated executables for Loki, but there is a problem: The incbin library doesn't work with MSVC, which means I have to configure an option that, given a filepath, loads a network file, in UCI.
The network should not be used if no binary has been loaded. Regardless of whether the inclution of it failed with gcc or if there hasn't been given a filepath in MSVC-compiled executables.

Therefore, I am wondering what to do if the user presses the "Use LNN" option before specifying a net-file to load (for MSVC builds). Should I report an error to UCI? Should the program's execution just stop?

I have looked at this guide for UCI, but I can't find anything about erroneous user-inputs.

One idea might be to just not give the "Use LNN" option if the executable has been compiled on MSVC, but that isn't really optimal IMO.

What would your suggestions be?

Any help will be much appreciated

[Ras]

Should I report an error to UCI?

What's standard practice is using the "info string freetext" way to provide feedback. The GUI can display that to the user in the engine info area. I'm using "info string error (description)" for that.

Should the program's execution just stop?

That wouldn't be helpful for the user.

However, there's one thing to consider: if you go to the engine specific options of the GUI and do some stuff there, and you click OK, it is up to the GUI in which order it will transfer the settings. So if you have a feature that needs two settings, and the second setting doesn't work before the first setting is configured, you may run into trouble if the GUI decides to first transmit the second setting and then the first. This becomes less likely if you put the first feature before the second one in the initial feature announcement, i.e. as reply to "uci", but you shouldn't bet on that.

[phhnguyen]

1) info string is the standard way to send messages to users. You may send error strings via cerr too (similar to LcZero).
2) Options in UCI may be sent in any order. However, you may solve your dilemma easily by checking and loading when receiving both involving options. For example the pseudo-code:

Code: Select all

func loadNetwork(path)
{
  if path == empty || path == loadedPath || not use_LNN
     return;
  
  loadedPath = path
  realLoadData()
}

if receive option use_LNN
   loadNetwork(option_path);

if receive option LNN_path
   option_path = path
   loadNetwork(option_path);

The other solution is that you load your network whenever receive commands "ucinewgame" or "go". A few centiseconds delaying is almost nothing to worry.

3) Send error strings then stop/crash itself is the best solution whenever the engine gets any critical condition. If your engine manages to run, the major number of users/testers won't bother to find what problem your engine has. They will assume everything is fine and continue to use it. If it stops or crashes from the beginning, they may find and solve the problem quickly. Once the Stockfish team has discussed a similar issue (continue or stop) and their choice is to stop whenever Stockfish can't load the NNUE file.

[niel5946]

Thank you both for your answers

I created a flag in my net class which gets set when a net is loaded. This is because I can then use that as the condition for the "Use LNN" option. I then do the following:
- At startup, a net is loaded from the embedded binary. This doesn't happen for MSVC builds though.
- If the user opts to load their own net, this can be done through the UCI.
- If a net hasn't been loaded (MSVC default), Loki outputs an error to the GUI if the user tries to use LNN.

I think this solution is the most optimal. Additionally, I took care to order the options in hopes of avoiding what you mentioned about which order the GUI sends informations in.