sepefeets;40723 wrote:Then test it.
Edit: I'm pretty sure that even if it does work as a test for whether the board is done updating or not, SF will only be able to log it although if we can identify the cause the Joy should be able to fix it. Botmaker originally used the IsProcessingPowers check to send a fake action to get another update later but afaict HR won't accept the fake action anymore since Joy added the "use default ai when SF crashes" option even if you have it disabled. The newer IsProcessingPowers check just sleeps but that doesn't let the gamestate ever update so all it does is log it (much less than data sync actually occurs since other things are causing it too).
@sepefeets, i have a question. If HR+Silverfish.dll is running under the same process, when the thread sleeps, both with sleep, so HR won't be able to update the gamestate? If I am not wrong, when the thread wakes up then the dll process will write to the text file or network port, the board state which is not changed at all during the sleep? So to solve the problem we may need to detach the process altogether, the dll have to be tasked to simply send the gamestate to the external exe process through IPC calls continously or through a pipe. Only Silverfish.exe will block based on the status of the gamestate, the dll should never block. Please let me know if my thinking is wrong.
Edit: Further thinking, I think to solve this problem Joy needs to add a new bot action type BOT_WAIT, so that Silverfish.dll can exit from OnQueryNextMove function and subsequently process UpdateGameState and then after that call OnQueryNextMove again. Since as long as the call to OnQueryNextMove is not completed, it will never be able to call to UpdateGameState.
