- Fixed a bug that caused the feature command not being recognized by Winboard, and the first id command not being recognized by Shredder and Chessbase
mediocre_v0.331
Follow the process of creating a chess engine
May 19, 2007
[New Version] v0.331 - Bug fix for Winboard and Chessbase interfaces
Changes:
mediocre_v0.331
mediocre_v0.331
Subscribe to:
Post Comments (Atom)
7 comments:
Hi Jonatan,
I bought Shredder 10.1 recently and I wanted to test Mediocre with this GUI. So this is not Chessbase but Shredder GUI. This is the same GUI than Shredder Classic that can be downloaded freely HERE
and used 30 days.
So I downloaded the exe file for windows that one can find on your blog.
When I install it as a winboard engine, I cannot play with it. I get illegal command as an error.
Ok this is not a big deal, so I decided to install it as UCI engine (Actually I did it first). Then it works, at least I can play against him, but if I set a position (from an epd file) and ask Mediocre to compute, it does nothing. This works with Arena, at least with the java version. When I click to stop the computation (that never started), then it takes sometime before Shredder GUI can stop it.
So I cannot test Mediocre under the Shredder GUI. Ok this is not perhaps so important for you, it works with Arena anyway. But Shredder has a nice feature, it can automatically send all the positions one after another to test to the engine. So a complete test is done completely automatically, you don't need to be in front of the computer. This is why I wanted to use Shredder.
I don't know if you can do something. I don't know if this was working with previous version of Mediocre. I can test it for you if I know where to find the exe of the previous versions.
You can find old executables of Mediocre on the archive site, here is the direct link:
http://mediocrechess.varten.org/mediocreexe.html
The Winboard issue under Shredder seems to be quite common, I've tried running King's Out and some others ad it's been trouble with all of them.
So better run it as UCI there as you said.
I'm not sure what the problem might be with epd positions. Most likely Shredder handles this differently than Arena. I will take a look at it.
If you could send some debug file or so it would be easier to locate the problem.
Polyglot is also good for this kind of tests. For example let's say you want to run the famous WAC test at 5 seconds per position:
polyglot epd-test -epd wac.epd -max-time 5
does the trick (engine configured in polyglot.ini as usual).
Very useful for UCI engines...
Shredder GUI seems to ommit the 5th and 6th field of the FEN (halfmove clock and fullmove number) when sending the EPD string to the engine (which makes somehow sense). I had this problem too. So making those field optional when parsing the FEN should fix this problem.
@genorb: To get the communication between Mediocre and Shredder GUI just write ucidebug.
I got a ArrayIndexOutOfBoundsException at Mediocre.extractFEN(Mediocre.java:313) when sending a EPD.
Hope it helps!
Cheers, Poky.
I have not had time to look into this (exams just around the corner), but with your excellent report it was not hard to find the problem. :)
The halfmoves and fullmoves fields are already optional in the fen-input part of Mediocre so I couldn't quite figure out where the problem was. However to extract the fen-string from the position command in the UCI protocol Mediocre uses the extractFEN()-method (like in the error message you sent).
The problem was Mediocre uses "split" to split the whole command line into parts, which gives an array with the different parts of the command ("position", "fen" "first part of fen", "side to move" etc). It then reassembles the fen part of the command to get a full fen-string.
This is where the problem was, it tried to reach splitString[6] which should keep halfmoves, but since those does not exist the program crashed.
So the actual fen-input was never reached.
This was easily fixed with a few if-statements.
I will include this fix in the next release.
Thanks a bunch!
Hello Jonatan,
First off, thank you for writing this blog. It's been immensely helpful as I am going about starting to write my own chess program for kicks (in C#)! I'm sure this will turn into one of those must read resources down the road for amateur chess programmers like myself for years to come!
Just wanted to point out some possibilities for perhaps cleaner code. In your Make move and Unmake move methods in v 0.331, you're duplicating the boardArray manipulations quite a bit. It might be useful to make a method called MovePiece or something that contains:
boardArray[to] = boardArray[from]; // Set target square
boardArray[from] = EMPTY_SQUARE; // Clear the original square.
Then just call it with the to and from parameters every time you need it. Might make for cleaner code.
Also, I'm not sure if this slows or speeds up the program, but right now the bit operations (such as Move.toIndex(move) and Move.fromIndex(move)) are called many, many times. Why not call them once in the beginning of the methods and store them in local variables? Then just use those variables throughout the method.
Finally, in your Engine class, mateCheck can just call isInCheck. If isInCheck is true, return (MATE_VALUE + ply). Else return the draw value.
Anyway, food for thought. Thanks again for this tremendous resource!
I'm glad you like it. :)
About the makeMove stuff you're probably right. At one point I even think I had something like you suggest. Atleast the 'call once in the beginning'. About making separate methods it would probably make for clearer code and the inline feature of the java compiler should take care of any slowdowns (since the methods would be very simple).
I am going to take a look at the whole make move and move generation once again however, and I'll keep this in mind when doing so.
About the mate check you're obviously right. It only makes for a few lines less code though.
Post a Comment