- 08 Dec, 2011 2 commits
-
-
Sam Moore authored
-
Sam Moore authored
Caused by the Program base class attempting to write EOF to programs which had already exited. This caused a SIGPIPE signal. The SIGPIPE handler function Game::HandleBrokenPipe then attempted to log the event by calling Game::theGame->logMessage However, since the program was exiting, DestroyGame had been called and Game::theGame was in the process of being deleted. Fixed by removing the fputc(output, EOF) line in Program::~Program. It is ironic that this only became an issue since I modified the sample AI to actually obey the protocol and exit as soon as "QUIT" is recieved...
-
- 07 Dec, 2011 1 commit
-
-
Sam Moore authored
Thats all
-
- 03 Dec, 2011 1 commit
-
-
Sam Moore authored
-f option to allow replaying of games output to files with -o -m option to enforce max number of turns (default 5000) before a DRAW is called -p to print a colourful representation of the board to stdout Yes. I now have both graphics AND pretty coloured terminal escape codes. Why did I do this??????????????
-
- 30 Nov, 2011 1 commit
-
-
Sam Moore authored
The "outcome" of a move is now listed as: TYPE [ATTACKER_RANK] [DEFENDER_RANK] Where ATTACKER_RANK and DEFENDER_RANK will be present if TYPE is one of: KILLS, DIES, BOTHDIE, and indicate the ranks of the pieces involved. This involved adding a class MovementResult, which stores the ranks of pieces in addition to an enum, replacing the enum Board::MovementResult The sample agent "forfax" was causing broken pipes, which caused the manager program to exit. I added a handler for SIGPIPE in manager/main.cpp to ensure that the manager program reports a DEFAULT victory to the other AI, and exits gracefully. However, I still don't know WHY forfax causes broken pipes, but hopefully its a problem with forfax and not with the manager program. I edited the images used by the graphical display to show the ordered ranks of the pieces, rather than some obscure characters. Unfortunately I have just realised that the enum used for Piece::Type stores ranks in the wrong order. In the actual game, LOWER numbers are better, in my enum, HIGHER numbers are better. To make things more confusing, I made the printed ATTACKER_RANK and DEFENDER_RANK correspond to the traditional numbering, not the enum numbering...
-
- 29 Nov, 2011 1 commit
-
-
Sam Moore authored
More details to follow :P
-