Author |
Topic: Arimaa Engine Interface (AEI) (Read 21573 times) |
|
Janzert
Forum Guru
Arimaa player #247
Gender: 
Posts: 1016
|
 |
Arimaa Engine Interface (AEI)
« on: Oct 9th, 2008, 7:55pm » |
 Quote  Modify
|
Pretty much ever since I mentioned that OpFor uses a rewritten interface to the gameroom that allows it to run continuously during the game and ponder on the opponents move I have also been promising to release it. There have been been a few reasons I kept putting it off. The biggest reasons are, zero documentation and pretty ugly code. Unfortunately both of those are still completely true. I've decided though to get it out there so people that are interested can at least take a look at it.
So with the caveat that this is not something anyone is likely to currently find instantly or easily usable or even understandable the code can be viewed at http://bazaar.launchpad.net/~janzert/+junk/aei/files or if you have bazaar installed you can get the branch with "bzr branch lp:~janzert/+junk/aei".
A couple things that will probably help anyone that does try and look at it now. AEI is based mostly on UCI (Universal Chess Interface or specification download). Also that gameroom.py started as and still pretty much is a straight transliteration of the 'bot' perl script, from the arimaa gameroom interface scripts, to python with AEI added in rather than calling a getmove engine.
Hopefully fairly soon I can get some documentation and maybe a sample engine written. In the meantime if anyone does look at it and has any question feel free to ask and I'll try and explain it; maybe it'll help me get real docs written.
[Edit: Ahh, forgot to mention short term plan is to get some documentation, medium term is add some sort of example engine and long term is for a GUI client that uses AEI for playing bots and also will connect to the gameroom]
Janzert
|
| « Last Edit: Oct 9th, 2008, 8:16pm by Janzert » |
 IP Logged |
|
|
|
Polyfractal
Forum Senior Member
Arimaa player #3241
Gender:
Posts: 27
|
|
Re: Arimaa Engine Interface (AEI)
« Reply #1 on: Oct 10th, 2008, 12:45am » |
Quote Modify
|
Thanks for this, it looks really useful. I may try to use it for my project. I've been digging through your code and a lot of it seems to make sense as far as layout (I think I have a general handle on how it operates). If I do use it I can help document as I figure things out. 
My current system is fragile and cumbersome to use. My getMove program has to check and see if my main bot engine's thread is running, spawn if not, then communicate with the bot engine through a state file. The bot engine meanwhile must continually poll the state file for updates. If something goes wrong somewhere, both threads can be in trouble due to the fragile communication method.
This seems like a much more elegant solution. Will it be allowed for tournament play?
|
|
IP Logged |
|
|
|
Janzert
Forum Guru
Arimaa player #247
Gender:
Posts: 1016
|
|
Re: Arimaa Engine Interface (AEI)
« Reply #2 on: Oct 10th, 2008, 8:22am » |
Quote Modify
|
Great, glad to hear it makes sense to someone besides myself. Anything you come up with I'm sure would help in writing the docs even if it's as simple as the times you had a hard time understanding what was going on.
Yes, Omar has allowed this to be used in the computer championship. It's actually the only interface OpFor has ever used. I had initially planned to write a layer similar to what it sounds like you are currently doing. But I really didn't like the idea of the extra layers and how kludgy the whole idea seemed. Happily Omar allowed the direct interface.
Janzert
|
|
IP Logged |
|
|
|
aaaa
Forum Guru
Arimaa player #958
Posts: 768
|
|
Re: Arimaa Engine Interface (AEI)
« Reply #3 on: Oct 10th, 2008, 9:37am » |
Quote Modify
|
Another disadvantage with having a program instance for each move that I haven't seen mentioned, is that it makes it hard to get a profile from it on a whole-game basis.
on Oct 10th, 2008, 12:45am, Polyfractal wrote:| My getMove program has to check and see if my main bot engine's thread is running, spawn if not, then communicate with the bot engine through a state file. |
|
I myself did some tentative experimentation with the intent of figuring out whether such an approach might work, but I ran into the problem that I couldn't get control to be returned to the bot script until not only the getMove program would finish, but also everything it has spawned in the mean time. I'm not exactly an expert on concurrency, so I might have missed something (possibly basic) here.
|
|
IP Logged |
|
|
|
Polyfractal
Forum Senior Member
Arimaa player #3241
Gender:
Posts: 27
|
|
Re: Arimaa Engine Interface (AEI)
« Reply #4 on: Oct 10th, 2008, 9:51am » |
Quote Modify
|
Indeed. My bot scripts creates an additional "stats" log file that it dumps to, containing its own internal state and other statistics. It works, but it is irritating and another file to look after.
Regarding threading, there is a way to asynchronously spawn threads. This is a nonblocking call and returns control directly to the original program. I don't have my code handy at the moment but I can post the function later when I get home. Granted, this is for Windows, but I would assume there is a similar method for Linux.
The problem with this, however, is that the bot thread is entirely independent and not owned by any other process. If something goes wrong, it will continue to spin its wheels with no governance. My getMove program has to therefore keep an eye on the bot thread and terminate it if there is any errant behavior.
All in all, a kludgy system that makes me sad. 
Janzert: I noticed there is a "match" script. Does that mean AEI can play local games against two different bots?
|
| « Last Edit: Oct 10th, 2008, 10:16am by Polyfractal » |
IP Logged |
|
|
|
Janzert
Forum Guru
Arimaa player #247
Gender:
Posts: 1016
|
|
Re: Arimaa Engine Interface (AEI)
« Reply #5 on: Oct 10th, 2008, 8:25pm » |
Quote Modify
|
Yes, match.py will run a set of games between two engines. Also analyse.py, simply feeds a given position to an engine to think about. Both of these a very basic scripts that just barely get the job done (e.g. the command line to run an engine and any options to send to it must be set by editing the script itself). Hopefully they'll be expanded into easier to use and more flexible forms in the future.
Since I'm mentioning the purpose of those two I may as well list what each file is for:
aei.py: is unsurprisingly a library to run and control an AEI based engine
analyse.py: takes a given board position and gives it to an engine to think about
board.py: implements an Arimaa board representation*, step and move generator and some parsing and output. It actually represents most of the core of a bot, writing an example bot based off it should be fairly easy. Once I get around to doing it that is. 
gameroom.py (and gameroom_example.cfg): this is the interface to the gameroom
match.py: runs a basic tournament between to engines
Janzert
* as a little bit of trivia and history, this was my second implementation of an Arimaa move generator. My first was in python and used an array based board representation. This one is obviously again in python but uses a bitboard representation. 2 1/2 was a rewrite of this to make it work as rpython for pypy (an obscure python compiler and many other things but nothing you really need to know about probably). Finally, at least for now, my third is in the D programming language and is another bitboard based representation although quite a bit different from this one and with many ideas cribbed from Fotland's description of Bomb. So it would seem that I tend to write a new Arimaa move generator every 18-24 months.
|
| « Last Edit: Oct 10th, 2008, 8:48pm by Janzert » |
IP Logged |
|
|
|
omar
Forum Guru
Arimaa player #2
Gender:
Posts: 1003
|
|
Re: Arimaa Engine Interface (AEI)
« Reply #6 on: Oct 17th, 2008, 4:33pm » |
Quote Modify
|
Thanks for posting this Janzert. I have a feeling this code base will soon become the one that I recommend as the gameroom interface used by bots
|
|
IP Logged |
|
|
|
Oystein
Forum Full Member
Arimaa player #3272
Gender:
Posts: 21
|
|
Re: Arimaa Engine Interface (AEI)
« Reply #7 on: Oct 26th, 2008, 10:11am » |
Quote Modify
|
Great work Janzert. I have successfully played against my engine using aei and your gameroom script. But clearly documentation would be very useful.
I have tried to make an overview of aei. What I have written is probably not easily understandable, but hopefully not totally nonsense. I have never used uci, and have never programmed in python so I assume I made some errors. Please notify me of any mistake.
Commands from controller:
* aei
- First command to establish the interface to use. Waits for 'id ...' and 'aeiok'
* isready
- Ping engine. Waits for 'readyok'
* newgame
- Starts a new game
* setposition <position>
- Set the position. Positions are given by the side to move (w/b) and a string
consisting of the piece letter or a space for each of the 64 squares.
* setoption name <id> [value <x>]
- Used for timecontrol informations. Probably also intended for settings like hash size.
* makemove <move>
- Make a move
* go
- Start search
* ponder
- Tells the engine to start pondering
* infinite
- Search until 'stop' command
* movetime <time>
- Search for given time
* depth <depth>
- Search <depth> steps deep
* stop
- Stop current search. Expect best move found so far from engine
* checkeval <"current" | position>
- Ask for evaluation of current or given position
* quit
- Quit
From engine:
* id - Identify the engine
* name <name>
* author <author>
* aeiok
- Conform to use aei
* readyok
- Answer to [isready]
* bestmove <move>
- Best move found in search
* info <string>
- Send information like best move so far, score, pv, depth searched.
<Must be specified better.>
* log <string>
- Any information the engine wants to log
Comments
w and b are used for the two sides rather than g and s. Maybe this should be changed.
uci state that the engine should ignore unknown commands. I dont like that solution. Perhaps it is better to use the log command to state the problem?
Some differences from uci:
- Time information is set by the setoption command for aei, and by go command for uci. I like the uci solution best.
- I dont understand exactly how pondering works in uci, but apparently the controller inform the engine on which move the engine "should" ponder on. I dont see the point in this.
- Lacking commands
* go searchmoves <move1> .... <movei>
I think this can be useful for analysis. But I think there should be possible to list partial moves. Like 3 steps and let the engine find the last step, rather than listing all possibilities. Also move sequenses could be useful for situations where we have found possible refutation to some moves.
* go nodes <x>
* go mate <x>
Also useful for analysis.
|
|
IP Logged |
|
|
|
Janzert
Forum Guru
Arimaa player #247
Gender:
Posts: 1016
|
|
Re: Arimaa Engine Interface (AEI)
« Reply #8 on: Oct 26th, 2008, 7:42pm » |
Quote Modify
|
on Oct 26th, 2008, 10:11am, Oystein wrote:| Great work Janzert. I have successfully played against my engine using aei and your gameroom script. But clearly documentation would be very useful. |
|
Wow, great to hear you are able to find it useable even without any documentation. I had my computer hard drive crash last week so have been putting my computer back together and haven't had a chance to work on this at all.
I should mention that I've also never implemented a UCI engine. My knowledge of it comes strictly from the protocol document and various email and forum messages I've read.
Quote:| I have tried to make an overview of aei. What I have written is probably not easily understandable, but hopefully not totally nonsense. I have never used uci, and have never programmed in python so I assume I made some errors. Please notify me of any mistake. |
|
Looks like you have most of it. This would make a good base to build from for the protocol doc. Mind if I use it?
Quote:Commands from controller:
* aei
- First command to establish the interface to use. Waits for 'id ...' and 'aeiok'
|
|
It is currently unimplemented but eventually (i.e. once there is a gui controller) I want to add something similiar to uci where the engine can tell the controller what options are available.
Quote:* setposition <position>
- Set the position. Positions are given by the side to move (w/b) and a string
consisting of the piece letter or a space for each of the 64 squares.
|
|
I had thought this board notation was defined somewhere but now that I'm looking for it I guess I just copied it from the perl move generator script omar provides.
Quote:* setoption name <id> [value <x>]
- Used for timecontrol informations. Probably also intended for settings like hash size.
|
|
Yes, this is meant to set all configuration options for the engine. So while there should be a certain predefined set of options that are standard across all or most engines an engine is also free to define its own as well (e.g. besides timecontrols and hash size opfor allows the weighting given to different evaluation components to be changed).
Quote:* go
- Start search
* ponder
- Tells the engine to start pondering
* infinite
- Search until 'stop' command
* movetime <time>
- Search for given time
* depth <depth>
- Search <depth> steps deep
|
|
The only subcommands actually meant to be used here are ponder and infinite. The movetime and depth are a relic of my initial copying from uci that I later changed my mind on, see below.
Quote:* checkeval <"current" | position>
- Ask for evaluation of current or given position
|
|
This is something I added for debugging OpFor and I'm not sure whether it should stay in or not. It's meant to tell the engine to statically evaluate either the current or given board position and report back any debugging information and the score (e.g. OpFor also reports the score for each component of the eval). I suppose it would be useful for anything that uses a traditional evaluation function but not something like a monte-carlo searcher.
Quote:From engine:
...
* info <string>
- Send information like best move so far, score, pv, depth searched.
<Must be specified better.>
|
|
This is meant to send information to the controller about the current search. Primarily things that would be displayed specially in a GUI separate from a general log.
Quote:* log <string>
- Any information the engine wants to log
|
|
Log messages starting with "Warning:" will be handled specially by the gameroom interface. I should probably extend it and specify that "Warning:" and "Error:" and maybe "Debug:" be logged at the corresponding levels.
Quote:Comments
w and b are used for the two sides rather than g and s. Maybe this should be changed.
|
|
Yes, now that Omar has stated his intention to shift to the usage of g and s I agree this should follow that.
Quote:uci state that the engine should ignore unknown commands. I dont like that solution. Perhaps it is better to use the log command to state the problem?
|
|
I think it is appropriate for the engine to throw an error and exit on an unknown command, on the principle that it's usually better to try and catch an error as close to the point that it happens than figure out what went wrong later.
It is probably best to simply log a warning or error when receiving an unknown or incorrect options though. Since GUI clients may allow users to send any option they want.
Currently OpFor will throw an exception and exit on an unknown command, but will silently eat unknown options. I have had that latter case bite me once or twice though when I misspelled an option so logging a warning would have been a good idea.
Quote:Some differences from uci:
- Time information is set by the setoption command for aei, and by go command for uci. I like the uci solution best.
|
|
First just so it's clear the uci "go movetime <x>" command is used to have the engine move after a fixed amount of time. In a regular timecontrol based game it sends the time information with wtime, btime, winc, binc and movestogo subcommands.
With arimaa the timecontrol system is a little more complex (and better developed in my opinion). Most of this information is set at the beginning of the game so was more natural to send as options. I also didn't like using the go command to tell the bot search to a fixed depth as that only really applies to traditional alpha-beta search. Another thing is I wanted to be able to update the time used for a move so far throughout the search in case of more accurate information coming in later because of network lag and such. So I ended up deciding to take all the timing and search depth settings off of the go command. I do admit that using setoption for things like the reserve time available and time used so far in a move does feel a little odd, but I think it's worth it since any separate command is going to basically just duplicate the functionality of setoption.
Quote:- I dont understand exactly how pondering works in uci, but apparently the controller inform the engine on which move the engine "should" ponder on. I dont see the point in this.
|
|
Basically all modern chess engines ponder by assuming that the opponent is going to reply the way it expects and starts searching as if that move has already been made. If the opponent does make the expected move then it can reply very quickly since it has already thought about its own reply for the whole of the opponents move. But if the opponent makes an unexpected reply it throws away the whole ponder search and starts fresh with the actual move played.
UCI's ponder mechanism is completely geared around this method. When the engine sends the move to make on the board it also sends the expected reply. The controller then tells the engine to go ahead and ponder. When the opponent's reply comes in if it is the expected reply then the controller tells the engine that there was a ponder hit and the engine continues searching but switches from pondering to a normal search. Otherwise it stops the engine and gives the actual line of play (UCI also always sends the full move list instead of just the next move).
Quote:- Lacking commands
* go searchmoves <move1> .... <movei>
I think this can be useful for analysis. But I think there should be possible to list partial moves. Like 3 steps and let the engine find the last step, rather than listing all possibilities. Also move sequenses could be useful for situations where we have found possible refutation to some moves.
* go nodes <x>
* go mate <x>
Also useful for analysis. |
|
All of these would certainly be useful. A couple of things though.
I don't think nodes is something that should be a subcommand of go because it may not make sense for non-traditional searchers. I think it would make sense to make it a standard option like depth (for a fixed depth search) and hash (for the hash table size), etc..
Multiple arimaa moves in a single command as is used in searchmoves is somewhat problematic as it quickly makes for very long lines and it becomes difficult for a human looking at the protocol while debugging. Also you have to use some delimiter other than space since the moves will contain spaces and can be a variable number of steps. I think it would be better to implement this as a separate command that would send one move each time the command is given. Maybe something like "allowedmove <move>".
Janzert
|
|
IP Logged |
|
|
|
Oystein
Forum Full Member
Arimaa player #3272
Gender:
Posts: 21
|
|
Re: Arimaa Engine Interface (AEI)
« Reply #9 on: Oct 27th, 2008, 8:21am » |
Quote Modify
|
on Oct 26th, 2008, 7:42pm, Janzert wrote:| Looks like you have most of it. This would make a good base to build from for the protocol doc. Mind if I use it? |
|
Of course not.
Quote:It is currently unimplemented but eventually (i.e. once there is a gui controller) I want to add something similiar to uci where the engine can tell the controller what options are available.
Yes, this is meant to set all configuration options for the engine. So while there should be a certain predefined set of options that are standard across all or most engines an engine is also free to define its own as well (e.g. besides timecontrols and hash size opfor allows the weighting given to different evaluation components to be changed). |
|
Sounds good.
Quote:* checkeval <"current" | position>
- Ask for evaluation of current or given position
This is something I added for debugging OpFor and I'm not sure whether it should stay in or not. It's meant to tell the engine to statically evaluate either the current or given board position and report back any debugging information and the score (e.g. OpFor also reports the score for each component of the eval). I suppose it would be useful for anything that uses a traditional evaluation function but not something like a monte-carlo searcher. |
|
I think this is to specific to be a standard command, but what about allowing generic commands like options are handled?
Engine sends: addcommand checkeval
GUI sends: usecommand checkeval
Just thinking loud.
Quote:I think it is appropriate for the engine to throw an error and exit on an unknown command, on the principle that it's usually better to try and catch an error as close to the point that it happens than figure out what went wrong later.
It is probably best to simply log a warning or error when receiving an unknown or incorrect options though. Since GUI clients may allow users to send any option they want. |
|
I agree.
But if the engine sends allowed option with the option command, then the gui can check the spelling.
Quote:| First just so it's clear the uci "go movetime <x>" command is used to have the engine move after a fixed amount of time. In a regular timecontrol based game it sends the time information with wtime, btime, winc, binc and movestogo subcommands. |
|
Yes.
Quote:| With arimaa the timecontrol system is a little more complex (and better developed in my opinion). Most of this information is set at the beginning of the game so was more natural to send as options. I also didn't like using the go command to tell the bot search to a fixed depth as that only really applies to traditional alpha-beta search. Another thing is I wanted to be able to update the time used for a move so far throughout the search in case of more accurate information coming in later because of network lag and such. So I ended up deciding to take all the timing and search depth settings off of the go command. I do admit that using setoption for things like the reserve time available and time used so far in a move does feel a little odd, but I think it's worth it since any separate command is going to basically just duplicate the functionality of setoption. |
|
You have obviously thought more about this than me.
Quote:Basically all modern chess engines ponder by assuming that the opponent is going to reply the way it expects and starts searching as if that move has already been made. If the opponent does make the expected move then it can reply very quickly since it has already thought about its own reply for the whole of the opponents move. But if the opponent makes an unexpected reply it throws away the whole ponder search and starts fresh with the actual move played.
UCI's ponder mechanism is completely geared around this method. When the engine sends the move to make on the board it also sends the expected reply. The controller then tells the engine to go ahead and ponder. When the opponent's reply comes in if it is the expected reply then the controller tells the engine that there was a ponder hit and the engine continues searching but switches from pondering to a normal search. Otherwise it stops the engine and gives the actual line of play (UCI also always sends the full move list instead of just the next move). |
|
Then I think it is clear that the UCI solution is not the best for AEI.
Quote:All of these would certainly be useful. A couple of things though.
I don't think nodes is something that should be a subcommand of go because it may not make sense for non-traditional searchers. I think it would make sense to make it a standard option like depth (for a fixed depth search) and hash (for the hash table size), etc.. |
|
I see your point. Since you included 'go depth', I think it was natural to add 'go node'. But that argument does not hold any more.
Quote:| Multiple arimaa moves in a single command as is used in searchmoves is somewhat problematic as it quickly makes for very long lines and it becomes difficult for a human looking at the protocol while debugging. Also you have to use some delimiter other than space since the moves will contain spaces and can be a variable number of steps. I think it would be better to implement this as a separate command that would send one move each time the command is given. Maybe something like "allowedmove <move>". |
|
Good point.
|
|
IP Logged |
|
|
|
Janzert
Forum Guru
Arimaa player #247
Gender:
Posts: 1016
|
|
Re: Arimaa Engine Interface (AEI)
« Reply #10 on: Oct 31st, 2008, 2:47pm » |
Quote Modify
|
I added protocol description and readme documents. The protocol document is still missing an example and probably needs other work but will hopefully ease understanding of the protocol.
Janzert
|
|
IP Logged |
|
|
|
Janzert
Forum Guru
Arimaa player #247
Gender:
Posts: 1016
|
|
Re: Arimaa Engine Interface (AEI)
« Reply #11 on: Mar 22nd, 2009, 3:18pm » |
Quote Modify
|
Last night I added a fairly minimal implementation of an engine as an example. It can be found in simple_engine.py and will play moves by choosing random steps.
While writing this I noticed a few small things I plan to change in the protocol soon.
The setposition command specifies the side as w or b, this should change to allow either w,b or g,s with the intent to only use g,s at some point in the future.
The setoption specifies standard options of lastmoveused and tcmoveused. In the gameroom interface they are actually both currently prefixed with tc (tclastmoveused and tcmoveused). Since these are not actually part of the timecontrol but are rather informational I plan to remove the tc prefix from both.
The go command specifies an infinite option. I plan to remove this as it is equivalent to no time control information set and the depth left as unlimited.
I also am not quite satisfied with the info command right now as there is no way to group several information messages together into one snapshot. I may fix this by adding an option id or timestamp value directly after the info command and before the type field. I'll probably hold off on that until I get further along with a gui client and see if or how much of a problem it becomes.
If anyone else has run into things that are awkward or irritating let me know so I can see if there is a way to make it better. Any changes that should be made I would like to get in very soon before there is much relying on the current protocol.
Janzert
|
|
IP Logged |
|
|
|
jdb
Forum Guru
Arimaa player #214
Gender:
Posts: 682
|
|
Re: Arimaa Engine Interface (AEI)
« Reply #12 on: Mar 22nd, 2009, 5:20pm » |
Quote Modify
|
Quote:| The go command specifies an infinite option. I plan to remove this as it is equivalent to no time control information set and the depth left as unlimited. |
|
I agree that "go infinite" is not needed.
However, I think the time control / depth info should be specified or have a defined default behaviour.
For example the command sequence,
setposition blah blah
go
What should the engine do?
|
|
IP Logged |
|
|
|
jdb
Forum Guru
Arimaa player #214
Gender:
Posts: 682
|
|
Re: Arimaa Engine Interface (AEI)
« Reply #13 on: Apr 21st, 2009, 9:30am » |
Quote Modify
|
Janzert, any idea what this is about?
Quote:2009-04-21 12:49:30 INFO:gameroom:Received move 24w Ef4e Dg3w Df3w Rc1n
2009-04-21 12:49:30 INFO:gameroom.position:
24b
+-----------------+
8| r r d r r r |
7| r d r |
6| X c X c R |
5| H e |
4| R E h |
3| X R D X R |
2| R R R C |
1| R |
+-----------------+
a b c d e f g h
2009-04-21 12:49:44 INFO:gameroom:Sending move cg6n Rh6w Rg6w Rf6x cg7s
2009-04-21 12:49:45 INFO:gameroom.position:
25w
+-----------------+
8| r r d r r r |
7| r d r |
6| X c X c |
5| H e |
4| R E h |
3| X R D X R |
2| R R R C |
1| R |
+-----------------+
a b c d e f g h
2009-04-21 12:50:45 INFO:gameroom.net:empty response from server will try again, sleeping for 0 seconds
2009-04-21 12:51:05 INFO:gameroom.net:Received URLError, reason type <class 'socket.gaierror'>
2009-04-21 12:51:05 INFO:gameroom:Leaving game
2009-04-21 12:51:05 INFO:gameroom:Removed run file at ./running/125143b.bot
2009-04-21 12:51:27 ERROR:gameroom:Caught unkown exception #1, restarting.
Traceback (most recent call last):
File "./gameroom.py", line 803, in main
table.playgame(engine_ctl, bot_greeting, options['onemove'])
File "./gameroom.py", line 295, in playgame
state = self.updatestate(30)
File "./gameroom.py", line 195, in updatestate
gamestate = post(self.url, values, "Table.updatestate")
File "./gameroom.py", line 79, in post
if hasattr(err, "reason") and len(err.reason) > 0 and err.reason[0] == 10060:
TypeError: object of type 'gaierror' has no len()
2009-04-21 12:51:32 ERROR:gameroom:Could not find game against 125143 with side 'b' |
|
|
|
IP Logged |
|
|
|
Janzert
Forum Guru
Arimaa player #247
Gender:
Posts: 1016
|
|
Re: Arimaa Engine Interface (AEI)
« Reply #14 on: Apr 21st, 2009, 10:06am » |
Quote Modify
|
It looks like there was initially a network error using an exception that I failed to expect or handle correctly causing the gameroom interface itself to throw a TypeError exception. It then tried to restart but was unsuccessful in reconnecting to the game.
It looks like the initial error 'socket.gaierror' should only get thrown on server hostname lookup or address errors. Unfortunately though because of the second error the details of it were lost. I've reworked the error handling there slightly to hopefully better handle unexpected errors, so hopefully at least good information can get recorded if it happens again.
Janzert
p.s. I noticed in chat you mentioned about the current interface not reporting the various extra information about the game (opponent, rated, etc.); I'll try and get that added by the end of the week.
|
|
IP Logged |
|
|
|
|
Home
Help
Search
Members
Login
Register
Reply
Notify of replies
Send Topic
Print