[PATCH] Handle case where an AI sends an invalid message and then crashes If an AI sent a bad move and then crashed, a SIGPIPE would be reported rather than the AI's bad move. NOTE: There is an issue with Program::Running, because the segfaulted AI still returns 'true', which leads to confusion in handling SIGPIPE. Should probably handle segfaulting AIs better. Then again, people should probably not make segfaulting AIs. [SZM]
Added image output to manager, added plots to results pages Can generate images from manager program with the -I option Can generate a video from these images with the -v option (Note: just runs ffmpeg) These two options only work if the program was built with graphics enabled. Note: You can generate a video from a saved log file by "./stratego -v video -o logfile" So that's cool. Results pages look nicer. Fixed bug with score updating between rounds. Added pretty plots. Most plots end up being straight lines. But its pretty anyway.
Worked out networking Wasn't thinking straight with the initial approach Basically: - Each stratego program is running ONE AI program locally -> That AI's responses need to be sent accross the network to the other stratego program -> Each stratego program keeps state seperately and sends instructions to its local AI, so actual instructions (ie: "Its your turn") aren't sent - A special controller is needed to recieve the responses So we have NetworkSender, which wraps around an AI_Controller and simply sends its responses (exactly as they are) to the network and NetworkReceiver which waits for responses from the network. As far as networking itself is concerned, its not that important who is the Client and who is the Server. If an IP address is specified, then Client is used, if no IP address is specified, Server is used. NOTE: It isn't possible to use networking for both AI programs yet. (ie: stratego @network @network) will fail when the Blue server attempts to bind the socket already used by the Red server. I may consider fixing this at some point. Going to test on mufasa. I've just thought, if the stratego programs have different timeout sequences, there may be problems. Oh well.
Setup client and server properly Erm, now what?
Began implementation of networking Slightly confused about the client/server thing Server is going to run red Client is going to run blue Need to get them to talk nicely? Doesn't work at the moment - server can't bind socket, client segfaults (NULL pointer). Blergh.
[RULE CHANGE] *Victory by "attrition"* + Bug fixes Minor bugs in the manager program fixed. Changed some messages for clarity, can't remember what, look at diff. Added VICTORY_ATTRITION; victory by destroying all of the opponents _mobile_ pieces (ie: Everything except Bombs/Flag) This means we don't get results of DRAW or DRAW_DEFAULT when one AI destroys all the other's mobile pieces. Since those games would last up to 5000 turns, this saves a lot of wasted time. AI should still respond with "NO_MOVE" when they have no mobile pieces. Made timeout value adjustable by an argument switch, '-T' Altered simulate.py to use a timeout variable and supply the switch to the manager program. So now I don't need to recompile and commit the manager program every time I want to test a different timeout value on mufasa! Mufasa is now on game 3 of the test round, out of 12. After FIVE HOURS. This particular game has lasted 1132 turns, with BLUE making "NO_MOVE" for the last 600 or so. The new victory condition will stop this sort of thing :) Merry Christmas!
Added build option to build "stratego" without graphics I need this for mufasa (vm), which doesn't have SDL or OpenGL or even GNOME Besides, it doesn't need it, and attempting to install them did not end well... Still need to test that it actually builds on mufasa
Changed directory structure (again) I got fed up of typing progcomp2012/progcomp Obsessive compulsive urges rising...