unserializable / monchester Goto Github PK

View Code? Open in Web Editor NEW

4.0 4.0 1.0 661 KB

Monchester, chess engine for CECP interfaces and console

License: GNU General Public License v3.0

Vim Script 100.00%

monchester's People

Contributors

Stargazers

Watchers

Forkers

aasaru

monchester's Issues

CECP: recognize 'rating' (as no-op)

Compiles of the later Monchester versions do not seem to react under lichess-bot. It might be connected to fact that after Monchester 1.0 the CECP error reporting compliance was retrofitted (#10).

Anyhow, the rating command would be simple to handle as no-op without reporting Error ... like CECP compliant error reporting dictates. So do that and see whether the behaviour running under the lichess-bot is restored.

Snippet from the game where lichess-bot & Monchester communication stalled:

2022-07-14 16:27:40,259: <PopenProcess at 0x7f8c86578048 (pid=17575)> << xboard
2022-07-14 16:27:40,260: <PopenProcess at 0x7f8c86578048 (pid=17575)> << protover 2
2022-07-14 16:27:40,261: <PopenProcess at 0x7f8c86578048 (pid=17575)> << post
2022-07-14 16:27:40,261: <PopenProcess at 0x7f8c86578048 (pid=17575)> << easy
2022-07-14 16:27:40,262: <PopenProcess at 0x7f8c86578048 (pid=17575)> << ping 123
2022-07-14 16:27:40,453: <PopenProcess at 0x7f8c86578048 (pid=17575)> >> # Monchester 1.0.1-24-g97c50f4 ~(4943 kN/s)
2022-07-14 16:27:40,454: <PopenProcess at 0x7f8c86578048 (pid=17575)> >> command : # received xboard
2022-07-14 16:27:40,454: <PopenProcess at 0x7f8c86578048 (pid=17575)> >> feature myname="Monchester 1.0.1-24-g97c50f4" name=1 setboard=1 ping=1 debug=1 edit=0 memory=0 usermove=0 analyze=0 colors=0 sigint=0 sigterm=0 done=1
2022-07-14 16:27:40,454: <PopenProcess at 0x7f8c86578048 (pid=17575)> >> pong 123
2022-07-14 16:27:40,457: <PopenProcess at 0x7f8c86578048 (pid=17575)> << name unserializable
2022-07-14 16:27:40,457: <PopenProcess at 0x7f8c86578048 (pid=17575)> << rating 1263 1448
2022-07-14 16:27:40,458: <PopenProcess at 0x7f8c86578048 (pid=17575)> >> Error (unknown command): rating 1263 1448
2022-07-14 16:27:40,458: +++ https://lichess.org/ni9SgJv6/white Blitz vs unserializable(1448)
2022-07-14 16:27:40,460: <PopenProcess at 0x7f8c86578048 (pid=17575)> << level 0 5:0 2
2022-07-14 16:27:40,464: <PopenProcess at 0x7f8c86578048 (pid=17575)> << st 10
2022-07-14 16:27:40,465: <PopenProcess at 0x7f8c86578048 (pid=17575)> << go

Force slight score randomization on default compile for CECP interfaces/bridges that do not send 'random'

Some CECP interfaces or interfaces pretending to be CECP interfaces do not act as XBoard / (Winboard) in the regard that after new command they do not send "random" command as part of initialization string.

For example, this causes Monchester to play deterministically when running under lichess-bot.

Since this 1.0 branch of undead code is meant as fun scholastic engine, not the boring one to beat with once-discovered winning line(s), it is desirable to have the slight score randomization in effect at all times.

Will add a feature define in FEATURE_FORCE_SCORE_RANDOMIZATION in features.h, ON by default. This feature is actually conflicting with DISABLE_SCORE_RANDOMIZATION compile-time define, so give compile-time error, if they are both set at the same time. Completely removing non-deterministic play compile option is not desired, as deterministic behaviour compiles can be useful for testing purposes.

Problem at lichess was reported by Vambo, who perfected beating Monchester 1.0 at Lichess, in its deterministically preferred Nimzowitsch Defense: Woodchuck Variation

[Event "Rated Blitz game"]
[Site "https://lichess.org/nEq7Hwqs"]
[Date "2020.11.20"]
[White "vambo"]
[Black "monchester"]
[Result "1-0"]
[UTCDate "2020.11.20"]
[UTCTime "07:51:15"]
[WhiteElo "1689"]
[BlackElo "1684"]
[BlackTitle "BOT"]
[Variant "Standard"]
[TimeControl "300+3"]
[ECO "B00"]
[Opening "Nimzowitsch Defense: Woodchuck Variation"]
[Termination "Normal"]

1. e4 a6 2. d4 Nc6 3. d5 Ne5 4. Bf4 Ng6 5. Be3 Ne5 6. Nf3 Nxf3+ 7. Qxf3 c6
8. Nc3 b6 9. O-O-O cxd5 10. Nxd5 Bb7 11. Bxb6 Qc8 12. Nc7+ Qxc7 13. Bxc7 e6
14. Bc4 Bc6 15. a3 Bb7 16. Qd3 d6 17. Bxd6 Bxd6 18. Qxd6 Bxe4 19. f3 Bxf3
20. gxf3 Ne7 21. Bxa6 f6 22. Bb5+ Kf7 23. Bc4 Nd5 24. Bxd5 Ra7
25. Qxe6+ Kf8 26. Qc8+ Ke7 27. Qxh8 Kd6 28. Qb8+ Rc7 29. Qb6+ Kd7
30. Ba8+ Kc8 31. Qd6 Kb8 32. Qd8+ Rc8 33. Qd6+ Kxa8 34. Qa6+ Kb8
35. Rd7 Rxc2+ 36. Kxc2 f5 37. Qb7# 1-0

[Event "Rated Blitz game"]
[Site "https://lichess.org/2ELoe2Fq"]
[Date "2020.11.19"]
[White "vambo"]
[Black "monchester"]
[Result "1-0"]
[UTCDate "2020.11.19"]
[UTCTime "15:37:44"]
[WhiteElo "1619"]
[BlackElo "1654"]
[WhiteRatingDiff "+43"]
[BlackRatingDiff "-13"]
[BlackTitle "BOT"]
[Variant "Standard"]
[TimeControl "300+3"]
[ECO "B00"]
[Opening "Nimzowitsch Defense: Woodchuck Variation"]
[Termination "Normal"]

1. e4 a6 2. d4 Nc6 3. d5 Ne5 4. Bf4 Ng6 5. Be3 Ne5 6. Nf3 Nxf3+ 7. Qxf3 c6
8. Nc3 b6 9. O-O-O cxd5 10. Nxd5 Bb7 11. Bxb6 Qc8 12. Nc7+ Qxc7 13. Bxc7 e6
14. Qd3 Bc8 15. f4 Nf6 16. h3 Ng8 17. g4 f6 18. f5 Nh6 19. fxe6 d6 20. Qc4 Ra7
21. Qc6+ Ke7 22. Bxd6+ Kd8 23. Bc7+ Ke7 24. Bd8# 1-0

Cute Chess on Windows: Monchester's connection stalls

A tournament of 500 games between Monchester and MinimalChess ended prematurely on a stalled connection. See logs & screenshot in the attached files.

log.txt
PGN.txt

The tournament used book moves and fast time controls of 10 seconds per game max.

Make 'release' mode the default Makefile target

Dr. Oliver Brausch reported (http://talkchess.com/forum3/viewtopic.php?f=2&t=75718&start=20#p871632):

"Manchester is a most interesting engine and I hadn't tested it before: It compiles easily on both systems and is very stable. But there is still a issue:
It cannot handle fast time controls. It loses many times on a 40/25 time control (25 seconds for 40 moves). It would make it into the second list (candidates with one minor flaw).
As it is CECP protocol, just read the "time 1023" command from the GUI and interrupt the search before this time has passed. I think this is a very important feature for your engine."

That report was somewhat unexpected, since at fixed search-depth 4 I expected Monchester to not be able to play ultra-fast time controls like 1s + 0.1s, but 25s / 40mvs should be alright. The search times at 4 plies, as reported by one lowly 15W i5-5200U CPU @ 2.20GHz laptop:

4:0.044:206603:4696:1.0:rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
4:0.241:1414420:5861:1.0:r1bqkb1r/3n1ppp/p2ppn2/1p4B1/3NP3/2NQ4/PPP2PPP/2KR1B1R w kq - 0 9
4:0.600:2537043:4227:1.0:2kr1b1r/1b3ppp/pq2p3/3nP3/1p1N4/3Q2N1/PPP1B1PP/1K1R1R2 b - - 6 17
4:0.083:403734:4891:1.0:rq5r/3k1p2/pp1p2p1/3p4/P2P3p/1P2PP1P/1R3P1R/1Q1K4 w - - 0 26
4:0.002:3663:2409:1.0:8/4k3/8/6P1/2p5/2P5/2P2K2/8 w - - 1 39
4:0.023:64674:2780:1.0:8/r7/8/5k2/2P2pR1/P1KP1P2/8/8 w - - 8 58

Above is the result of running the command:

./monchester --bench 4 && # standard starting position
./monchester --bench 4 "r1bqkb1r/3n1ppp/p2ppn2/1p4B1/3NP3/2NQ4/PPP2PPP/2KR1B1R w kq - 0 9" &&
./monchester --bench 4 "2kr1b1r/1b3ppp/pq2p3/3nP3/1p1N4/3Q2N1/PPP1B1PP/1K1R1R2 b - - 6 17" &&
./monchester --bench 4 "rq5r/3k1p2/pp1p2p1/3p4/P2P3p/1P2PP1P/1R3P1R/1Q1K4 w - - 0 26" &&
./monchester --bench 4 "8/4k3/8/6P1/2p5/2P5/2P2K2/8 w - - 1 39" &&
./monchester --bench 4 "8/r7/8/5k2/2P2pR1/P1KP1P2/8/8 w - - 8 58"

Suspicion rose that most likely Oliver compiled Monchester in debug mode, where it is much slower (and which is the default Makefile target).

Tests

Did some tests on Ryzen 2700X, including even faster time control (10s/40mvs) to account for CPU clock differences between AMD EPYC 7502P 32-Core where Oliver is running tests.

25s/40mvs

Against Minnow (https://github.com/tm512/minnow, revision dfe1461, 200 games, 25s/40mvs), Monchester did not forfeit any games on time, but Minnow did, 42 games out of 200.

Against OliThink 4.1.3 (https://github.com/olithink/olithink4), compiled with gcc -O3 olithink413.c -o olithink413, its distribution did not include Makefile, it played 1000 games, 25s/40mvs. There were no time forfeits for either side.

10s/40mvs tests

Against Rustic 0.1.0-alpha (https://github.com/mvanthoor/rustic, code of 9th November 2020, 200 games 10s/40mvs) these games did not include in any time forfeits for either engine (Rustic lost some games due to illegal moves reported by Polyglot, it was running in UCI mode, as direct CECP is not supported).

Against Prophet4 (https://github.com/jswaff/prophet4, revision 530f5a9) -- (5000 games, 10s/40mvs) were interrupted after game 1159, where Prophet4 refused to move (crash) and forfeited on time. Before that Prophet4 crash, none of the engines had forfeited any games on time.

This strongly confirms my doubt that Oliver compiled Monchester in debug mode. This is something that is bound to happen to other people who just want to quickly run make, so will go ahead and make release target the default target in Makefile, so that people who like to compile engines from source can get release code build, even when the do not grok README.

Also, update README accordingly.

No functional changes, only compilation and documentation, engine version reported will remain at 1.0.

Linux binaries compiled by me and Windows binaries compiled by Günther are already correctly built in release mode, so no changes are required.

More FEN validation for lenient CECP interfaces

From: https://www.gnu.org/software/xboard/engine-intf.html

Illegal positions: Note that either setboard or edit can be used to send an illegal position to the engine. The user can create any position with xboard's Edit Position command (even, say, an empty board, or a board with 64 white kings and no black ones). If your engine receives a position that it considers illegal, I suggest that you send the response "tellusererror Illegal position", and then respond to any attempted move with "Illegal move" until the next new, edit, or setboard command.

Variant capable interfaces like XBoard are quite lenient on what they allow on the board. Engine however should not process such positions. Besides lack of both kings, one thing that would definitely prevent normal engine play would be the presence of pawns on either 1st or 8th rank, so reject such positions too.

Couple of FENS that will be considered illegal, with pawn on 1st / 8th rank:

8/8/7N/1k3K2/8/8/8/3P4 w - - 0 1
5P2/8/7N/1k3K2/8/8/8/8 w - - 0 1
4p3/8/7N/1k3K2/8/8/8/8 w - - 0 1
8/8/7N/1k3K2/8/8/8/p7 w - - 0 1

CECP 'sd' interpretation only done once per game

CECP 'sd' command handling has been built up too defensively, once decreased limit cannot be increased during the same game anymore, only in new game (CECP new specifies and triggers search depth limit reset):

monchester/main.c

Lines 652 to 665 in b93ca99

 else if (!strncmp(command, "sd", 2) && g_cecp) { 

 intmax_t sd_limit = to_int(command + 2, 1, UINT16_MAX, false, true, NULL); 

 if (!errno) { 

 sd_limit--; 

 if (sd_limit > UINT8_MAX) sd_limit = UINT8_MAX; 

 g_engine_conf.depth_max = (uint8_t) sd_limit; 

 if (sd_limit < g_engine_conf.depth_default) 

 g_engine_conf.depth_default = sd_limit; 

 } else { 

 print_cmd_error(command, UNKNOWN_COMMAND_TEXT); 

 } 

 xfree(command); 

 continue; 

 }

Other questionable stuff here too -- I recall that the sd was not allowed to go over 4 as this is the set limit for 'constant reference strength`. However, this might be too much handholding, might be better to allow going over that for power-users who know what they are doing, without need to perform separate compiles for e.g. testing with slower but (somewhat) better playing Monchester.

EDIT: 19.02.2022

Hmm, it might not be only about handhelding of power users, but also living with GUIs, there is report of Arena using obscene number for sd, see Arena "sd=9999" (talkchess.com 24.02 2009, reported by Richard Allbert)

EDIT: 26.02.2022
At least the sd=9999 does not seem to be sent in Arena anymore: #10 (comment)

In play mode, when single move available from root, play that immediately without further search

When playing and arriving in such situations, just play the move -- do not perform search to further depth. However, when not playing, then continue with analysis up to current depth.

This also gets rid of the occasions when logs say say Estimated node count 0, processed NNN, e.g.

FEN: 8/N1R5/4R3/6p1/3kP3/2b5/2P2P2/q2K4 w - - 0 46 white to play.

# PV: d1e2 a1e1 e2f3 e1e4  404
d1->e2: 404
Estimated node count 0, processed 9022

The reason for that log message is that with only legal moves generated, just 1 move is available and 1 to any power = 1 -- the further arithmetics (multiplication + division to bring estimate within supposed 95% confidence bound) brings this down to 0.

Improve CECP-compliance of error-reporting

Announce errors with prefix, optional description and command name

As leftover from console-only interface 'Unrecognized command' is sent also when speaking CECP

command : xboard
# received xboard
protover 2
feature myname="Monchester 1.0" name=1 setboard=1 ping=1 edit=0 memory=0 usermove=0 analyze=0 colors=0 sigint=0 sigterm=0 done=1
dafadsfds
Unrecognized command

However, most compatible way of CECP is:

Error (ERRORTYPE): COMMAND

given earlier situation, that would be e.g.: Error (Unrecognized command): dafadsfds or Error: dafadsfds or Error (unknown command): dafadsfds, etc

Verify robust command argument parsing

E.g. to_int is used for CECP sd argument parsing and when given in succession, this fails with conversion error announced.

# Monchester 1.0 ~(11826 kN/s)
command : xboard
# received xboard
sdf
Could not convert 'f' to integer.

Expected behaviour would be to announce unknown command error in the same format as described before, e.g: Error (unknown command): sdf Similarly for other imaginable happenings like stx, etc.

CECP: set feature 'debug'

Lo and behold, apparently the debug comments output prefixed by '#' should actually be only sent after setting feature `ďebug=1`` -- https://www.gnu.org/software/xboard/engine-intf.html#9

debug (boolean, default 0)
    If debug=1, it means the engine wants to send debug output prefixed by '#', 
which WinBoard should ignore, except for including it in the winboard.debug file. 
As this feature is added to protocol 2 ony late, so that not all protocol-2 supporting
versions of WinBoard might implement it, it is important that engines check if WinBoard
accepts the feature. If the feature is rejected, engines must refrain from sending the
debug output, or do so at their own risk.

Considering that so far the # debug comments are used whenever running under CECP is recognized, this has been working very well -- bring this in line with the specifications.

From http://hgm.nubati.net/newspecs.html

When an engine sends stuff the GUI does not understand, the result is in principle undefined, but GUI should
make its best attempt to ignore the entire non-compliant line. Valid reasons for not ignoring the line are
that the protocol has been extended to now attach a meaning to the engine utterance, or to treat it as a
different valid command, in order to cater to known engine bugs (like recognizing commands with typos). The
latter is really bad (but alas common) practice: XBoard even takes any line containing the word "Draw" as an
"offer draw" command. When an engine wants to print non-compliant messages (e.g. to aid debugging), it should
better use the debug feature to 'disarm' these message by starting them with '#' to make sure they cannot have
unexpected results. And even this might not protect you when the line contains system error messages like "not
found" or "permission denied"!

This debug feature originated in 2008, post from July "WB protocol for engine comments" has HGM mentioning this as official mechanism from "WinBoard 4.3.13 on".

Yet more FEN validation: reject positions with inactive king attacked

This simple case has not been covered yet, also covers the non-touching kings requirement.

Both kings in check

rnb1kbnr/pp2pppp/3p4/q1p5/Q1P5/3P4/PP2PPPP/RNB1KBNR b KQkq - 0 1

Kings attacking each other

8/2P5/8/8/8/8/1P2Kp2/5k2 b - - 0 1

Engine promotions blocking check or removing checker happened to be bishop-only

E.g. for 8/8/8/7r/8/1K6/3p4/2k1R3 b - - 0 115:

only two bishop promotions are given as valid moves.

115. .. dxe1=B 
        ( 115. dxe1=B Kc4 2. Bg3 Kd4 { 33.65/4 })
        ( 115. d1=B+ Kb4 2. Rh4+ Kc3 { 7.57/4 })

and also:

$ ./monchester --bench 1 "8/8/8/7r/8/1K6/3p4/2k1R3 b - - 0 115"
1:0.000:2:52:1.0-25-gabd4acf:8/8/8/7r/8/1K6/3p4/2k1R3 b - - 0 115

This is due to underpromotion encoding added for 1.0 comparing target squares with promotion encoding to check-blocking checker-removal squares without decoding in mvs_a. Change that comparison to use decoded form.

Improve endgame: king vs king and major piece

One of the annoyances with Monchester 1.0 is that it's narrow fixed 4-depth search without quiescence with added randomization is fine enough to play scholastic level threats and blunders in opening and middlegame, but the endgames suck with such narrow depth and are much more random and dumb than scholastic.

So, providing bit more instructive behaviour without increasing the search depth anywhere (as the 1.0 is planned to remain essentially constant-strength engine), add the evaluation terms for endgames with sole king against king and major piece -- these should be consistently won. Randomization helps, but has loads of trouble when weaker king starts and remains in the middle of the board. And vice-versa, if engine is playing the weaker side, it should not run towards the last files and ranks but provide resistance by trying to remain centralized.

CECP: add handling blocks for '?' and 'rejected' commands

There is no special handling for them needed at the moment, but do recognize these as CECP commands. For '?' as noted in #12 -- silentium. For 'rejected' -- silentium too, e.g. CuteChess 1.2.0 sends rejected even for features that were explicitly turned off. As for more handling, rejected features are all such that actually were requested to be set OFF, no action needed, and only protocol v2 engines send 'rejected' anyway, so they are not to invoke the commands that are not supported by them. So do not produce any blabber for these rejections.

rejected edit
rejected analyze
rejected colors
rejected sigint
rejected sigterm

Full log session from startup of CuteChess:

4 >MCE 0.2.1(0): uci
5 >Monchester 1.0.1-14-g84db4ed(1): xboard
5 >Monchester 1.0.1-14-g84db4ed(1): protover 2
80 <MCE 0.2.1(0): MinimalChess 0.2.1
92 <MCE 0.2.1(0): id name MinimalChess 0.2
92 <MCE 0.2.1(0): id author Thomas Jahn
92 <MCE 0.2.1(0): uciok
92 >MCE 0.2.1(0): isready
93 <MCE 0.2.1(0): readyok
128 <Monchester 1.0.1-14-g84db4ed(1): # Monchester 1.0.1-14-g84db4ed ~(9156 kN/s)
128 <Monchester 1.0.1-14-g84db4ed(1): command : # received xboard
128 <Monchester 1.0.1-14-g84db4ed(1): feature myname="Monchester 1.0.1-14-g84db4ed" name=1 setboard=1 ping=1 edit=0 memory=0 usermove=0 analyze=0 colors=0 sigint=0 sigterm=0 done=1
128 >Monchester 1.0.1-14-g84db4ed(1): accepted myname
128 >Monchester 1.0.1-14-g84db4ed(1): accepted name
128 >Monchester 1.0.1-14-g84db4ed(1): accepted setboard
128 >Monchester 1.0.1-14-g84db4ed(1): accepted ping
128 >Monchester 1.0.1-14-g84db4ed(1): rejected edit
128 >Monchester 1.0.1-14-g84db4ed(1): accepted memory
128 >Monchester 1.0.1-14-g84db4ed(1): accepted usermove
128 >Monchester 1.0.1-14-g84db4ed(1): rejected analyze
128 >Monchester 1.0.1-14-g84db4ed(1): rejected colors
128 >Monchester 1.0.1-14-g84db4ed(1): rejected sigint
128 >Monchester 1.0.1-14-g84db4ed(1): rejected sigterm
128 >Monchester 1.0.1-14-g84db4ed(1): accepted done
Started game 1 of 10 (MCE 0.2.1 vs Monchester 1.0.1-14-g84db4ed)
128 >MCE 0.2.1(0): ucinewgame
128 >MCE 0.2.1(0): position startpos
128 >Monchester 1.0.1-14-g84db4ed(1): new
128 >Monchester 1.0.1-14-g84db4ed(1): force
128 >Monchester 1.0.1-14-g84db4ed(1): level 0 0:10 0
128 >Monchester 1.0.1-14-g84db4ed(1): post
128 >Monchester 1.0.1-14-g84db4ed(1): easy
128 >Monchester 1.0.1-14-g84db4ed(1): computer
128 >Monchester 1.0.1-14-g84db4ed(1): name MCE 0.2.1
128 >MCE 0.2.1(0): isready
129 <Monchester 1.0.1-14-g84db4ed(1): Error (unknown command): rejected edit
129 <Monchester 1.0.1-14-g84db4ed(1): #8:  R N B Q K B N R 
129 <Monchester 1.0.1-14-g84db4ed(1): #7:  P P P P P P P P 
129 <Monchester 1.0.1-14-g84db4ed(1): #6:  - - - - - - - - 
129 <Monchester 1.0.1-14-g84db4ed(1): #5:  - - - - - - - - 
129 <Monchester 1.0.1-14-g84db4ed(1): #4:  - - - - - - - - 
129 <Monchester 1.0.1-14-g84db4ed(1): #3:  - - - - - - - - 
129 <Monchester 1.0.1-14-g84db4ed(1): #2:  p p p p p p p p 
129 <Monchester 1.0.1-14-g84db4ed(1): #1:  r n b q k b n r 
129 <Monchester 1.0.1-14-g84db4ed(1): #-------------------
129 <Monchester 1.0.1-14-g84db4ed(1): #    A B C D E F G H       rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
129 <Monchester 1.0.1-14-g84db4ed(1): Error (unknown command): rejected analyze
129 <Monchester 1.0.1-14-g84db4ed(1): #8:  R N B Q K B N R 
129 <Monchester 1.0.1-14-g84db4ed(1): #7:  P P P P P P P P 
129 <Monchester 1.0.1-14-g84db4ed(1): #6:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #5:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #4:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #3:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #2:  p p p p p p p p 
130 <Monchester 1.0.1-14-g84db4ed(1): #1:  r n b q k b n r 
130 <Monchester 1.0.1-14-g84db4ed(1): #-------------------
130 <Monchester 1.0.1-14-g84db4ed(1): #    A B C D E F G H       rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
130 <Monchester 1.0.1-14-g84db4ed(1): Error (unknown command): rejected colors
130 <Monchester 1.0.1-14-g84db4ed(1): #8:  R N B Q K B N R 
130 <Monchester 1.0.1-14-g84db4ed(1): #7:  P P P P P P P P 
130 <Monchester 1.0.1-14-g84db4ed(1): #6:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #5:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #4:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #3:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #2:  p p p p p p p p 
130 <Monchester 1.0.1-14-g84db4ed(1): #1:  r n b q k b n r 
130 <Monchester 1.0.1-14-g84db4ed(1): #-------------------
130 <Monchester 1.0.1-14-g84db4ed(1): #    A B C D E F G H       rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
130 <Monchester 1.0.1-14-g84db4ed(1): Error (unknown command): rejected sigint
130 <Monchester 1.0.1-14-g84db4ed(1): #8:  R N B Q K B N R 
130 <Monchester 1.0.1-14-g84db4ed(1): #7:  P P P P P P P P 
130 <Monchester 1.0.1-14-g84db4ed(1): #6:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #5:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #4:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #3:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #2:  p p p p p p p p 
130 <Monchester 1.0.1-14-g84db4ed(1): #1:  r n b q k b n r 
130 <Monchester 1.0.1-14-g84db4ed(1): #-------------------
130 <Monchester 1.0.1-14-g84db4ed(1): #    A B C D E F G H       rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
130 <Monchester 1.0.1-14-g84db4ed(1): Error (unknown command): rejected sigterm
130 <Monchester 1.0.1-14-g84db4ed(1): #8:  R N B Q K B N R 
130 <Monchester 1.0.1-14-g84db4ed(1): #7:  P P P P P P P P 
130 <Monchester 1.0.1-14-g84db4ed(1): #6:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #5:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #4:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #3:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #2:  p p p p p p p p 
130 <Monchester 1.0.1-14-g84db4ed(1): #1:  r n b q k b n r 
130 <Monchester 1.0.1-14-g84db4ed(1): #-------------------
130 <Monchester 1.0.1-14-g84db4ed(1): #    A B C D E F G H       rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
130 <Monchester 1.0.1-14-g84db4ed(1): #8:  R N B Q K B N R 
130 <Monchester 1.0.1-14-g84db4ed(1): #7:  P P P P P P P P 
130 <Monchester 1.0.1-14-g84db4ed(1): #6:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #5:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #4:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #3:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #2:  p p p p p p p p 
130 <Monchester 1.0.1-14-g84db4ed(1): #1:  r n b q k b n r 
130 <Monchester 1.0.1-14-g84db4ed(1): #-------------------
130 <Monchester 1.0.1-14-g84db4ed(1): #    A B C D E F G H       rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
130 <Monchester 1.0.1-14-g84db4ed(1): #8:  R N B Q K B N R 
130 <Monchester 1.0.1-14-g84db4ed(1): #7:  P P P P P P P P 
130 <Monchester 1.0.1-14-g84db4ed(1): #6:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #5:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #4:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #3:  - - - - - - - - 
130 <Monchester 1.0.1-14-g84db4ed(1): #2:  p p p p p p p p 
130 <Monchester 1.0.1-14-g84db4ed(1): #1:  r n b q k b n r 
130 <Monchester 1.0.1-14-g84db4ed(1): #-------------------
130 <Monchester 1.0.1-14-g84db4ed(1): #    A B C D E F G H       rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
134 <MCE 0.2.1(0): readyok
134 >MCE 0.2.1(0): go wtime 10000 btime 10000
135 <MCE 0.2.1(0): info string Search budget set to 249ms!
154 <MCE 0.2.1(0): info depth 1 score cp 0 nodes 20 nps 1538 time 13 pv g2g4
166 <MCE 0.2.1(0): info depth 2 score cp 0 nodes 59 nps 1966 time 30 pv g2g4 a7a6
167 <MCE 0.2.1(0): info depth 3 score cp 0 nodes 575 nps 18548 time 31 pv g2g4 a7a6 b1a3
178 <MCE 0.2.1(0): info depth 4 score cp 0 nodes 1639 nps 39975 time 41 pv g2g4 a7a6 b1a3 a6a5
209 <MCE 0.2.1(0): info depth 5 score cp 100 nodes 17888 nps 248444 time 72 pv c2c4 d7d6 d1b3 h7h6 b3b7
355 <MCE 0.2.1(0): info depth 6 score cp -100 nodes 70773 nps 323164 time 219 pv c2c4 b7b6 d1b3 c8b7 b3a4 b7g2

Move generator exposes() does not use e.p. as check control atkexp() does

There is a bug with checking exposure from e.p. capture, it is bound to very rare (such exposing capture is unlikely to be scored as best move) and so far has has not been reported to occur in real games, nonetheless it can be reproduced with Monchester 1.0/1.0.1 when using the position 8/8/8/8/3kpP1R/8/6K1/8 b - f3 0 1

where white has just done f2f4 pawn push and e.p. capture e4f3ep for black is not legal and should be excluded from the move generator by the exposes().

Oversight is only present in exposes(), more critical atkexp() already handles this correctly, so handling can be lifted from there, somewhat more succinctly.

Yet more FEN validation: reject also positions with more than 16 pieces for the side

In #2 some cases of illegal positions that cannot be handled were made to be rejected. Reject also positions with more than 16 pieces for the side, as engine is not written to support more than 16 pieces for a side.

rnbqkbnr/pppppppp/3pp3/8/8/3PP3/PPPPPPPP/RNBQKBNR w KQkq - 0 1
rnbqkbnr/pppppppp/3pp3/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
rnbqkbnr/pppppppp/8/8/8/3PP3/PPPPPPPP/RNBQKBNR w KQkq - 0 1

	else if (!strncmp(command, "sd", 2) && g_cecp) {
	intmax_t sd_limit = to_int(command + 2, 1, UINT16_MAX, false, true, NULL);
	if (!errno) {
	sd_limit--;
	if (sd_limit > UINT8_MAX) sd_limit = UINT8_MAX;
	g_engine_conf.depth_max = (uint8_t) sd_limit;
	if (sd_limit < g_engine_conf.depth_default)
	g_engine_conf.depth_default = sd_limit;
	} else {
	print_cmd_error(command, UNKNOWN_COMMAND_TEXT);
	}
	xfree(command);
	continue;
	}