Various technical articles, IT-related tutorials, software information, and development journals
Thursday, May 30, 2019
Exotherm - Mercuric
This morning I got emails saying that a FICS computer account had been created for me. It's named "mercuric", my second choice because "exotherm" wasn't available. (It appears available to me, and I've logged in as guest with it even today, but maybe there's something else going on.) I added the ability to post seeks and set appropriate variables, then uploaded it to my server. It can successfully log in and play games, though it eventually loses connection - I'll need to set up some way to automatically restart it when needed.
Wednesday, May 29, 2019
Exotherm - Evaluator tweaks
I recently adjusted Exotherm's position evaluator a little more. To help it avoid losing in preventable ways in the endgame, I made it value check by rook or queen, which tend to lead to explosions. To encourage it to develop more pieces in the opening, I made it slightly value the possibility of targeting more open squares. I also adjusted the pawn balance evaluator to be less likely to needlessly sacrifice a rook for a pawn.
There's still no updates on FICS's provisioning of a computer account for Exotherm.
There's still no updates on FICS's provisioning of a computer account for Exotherm.
Tuesday, May 28, 2019
Exotherm - Memory conservation
The virtual server that I'll hopefully be able to run Exotherm on has only 1 GB of RAM. I've noticed that Exotherm uses a sizable fraction of that, so if I want my server to be able to continue doing more important things, I'll need to be careful about memory usage. I noticed that the "think" module keeps board objects for all positions in the tree even after they've been evaluated, stopping the GC from collecting them. So I adjusted it to set them to None when no longer needed, allowing the GC to make progress even in the middle of a think if necessary.
Monday, May 27, 2019
Exotherm - Preparing for deployment
My previous attempt at making Exotherm note positions that led to loss worked poorly because the information was rediscovered a half move too late. Today I added similar logic to the part of the bot that relays the decided move to the server. If the evaluator found that the bot is doomed, the outer code records that the previous move the bot made is bad. This measure has no depth limit because it will only add at most one entry per game, so I'm not too worried about storage space.
I also made the bot willing to accept draws in some circumstances. It now keeps track of how many moves have occurred since an explosion or pawn move. When its opponent makes a draw offer, it will accept if no progress has been made for several moves and there is little material still existing.
These are the last changes I wanted to make to Exotherm, so after testing them I sent in my application for a computer account. They've approved the deployment of my engine - now I'm waiting for the username to be approved and the account provisioned.
I also made the bot willing to accept draws in some circumstances. It now keeps track of how many moves have occurred since an explosion or pawn move. When its opponent makes a draw offer, it will accept if no progress has been made for several moves and there is little material still existing.
These are the last changes I wanted to make to Exotherm, so after testing them I sent in my application for a computer account. They've approved the deployment of my engine - now I'm waiting for the username to be approved and the account provisioned.
Sunday, May 26, 2019
Exotherm - Hardcoded responses
After some testing today I determined that Exotherm's new ability to record the moves that led to unexpected certain doom is not working as well as I hoped. It seems like the doom is detected a half-move too late in the very common 1. Nf3 trap. It looks like I would need something more sophisticated for Exotherm to make any progress in the general case. As a temporary measure, I added a configuration section for "hardcoded" responses to recognized positions. Currently I'm only manually configuring 1. ...f6 as the response to the knight threat, but once Exotherm is deployed I would monitor for other repeatable traps.
Saturday, May 25, 2019
Microsoft deprecated the File History API
I was looking back at the File History API that I had worked with previously and noticed that the new header files are saying it's deprecated. FhCfg.h has instructions like #pragma deprecated(IFhConfigMgr) and functions in FhSvcCtl.h are have notes like:
I'm looking at header files from the SDK for Windows 10 build 17134 (version 1803), while the version from build 10240 (version 1507, the original Windows 10) does not have the notices. Weirdly, there does not seem to be any mention of this deprecation in the documentation of those functions nor anywhere on MSDN that I could find by searching.
__declspec(deprecated("FhServiceOpenPipe is deprecated and might not work on all platforms. For more info, see MSDN."))
I'm looking at header files from the SDK for Windows 10 build 17134 (version 1803), while the version from build 10240 (version 1507, the original Windows 10) does not have the notices. Weirdly, there does not seem to be any mention of this deprecation in the documentation of those functions nor anywhere on MSDN that I could find by searching.
Friday, May 24, 2019
The Exotherm draw problem
I'm hoping to deploy Exotherm to the FICS relatively soon. There is a problem I'd like to address first, though. It plays poorly in the endgame and usually thinks it's doing much better than it is. It walks various pieces all around the board without making any progress. I would like to have it accept draws if it detects no progress has been made after some time. Playing it would be much more enjoyable if one didn't have to go all the way to draw by repetition or 50 moves when the bot can't figure out what to do.
Subscribe to:
Posts (Atom)