Algo timing out at random when using c++ extension

Algo timing out at random when using c++ extension
0

#1

I have built a c++ action phase simulator that uses a .so file in a similar manner to how many others here have done. It works perfectly when being called normally from a python file without the game engine. When it is called from the algo strategy python file when a match is run using run_match.py, it runs fine for a few turns and then it times out. The strange part is that the c++ extension seems to successfully return, and the algorithm says that each player is “Performing turn x of your custom algo strategy”, then gives a timeout error of 35,000 ms for each player. Sometimes it does this on the first turn, sometimes on the second, and sometimes anywhere up to the tenth turn. The fact that the timeout seems to occur after the extension is finished at first led me to believe that it was unrelated, but commenting out the positions returned by the extension and replacing them with hard coded locations actually does fix the error. The locations returned from the c++ extension are valid however because the replay from the game running ten turns shows placements at valid positions. When it times out on the first turn, the final state shows that both algos have placed all of the firewalls they wanted to. Uploading a zip file works perfectly fine, it compiles and then proceeds to do the exact same thing it did in local testing, it places defenses successfully for a few turns and then times out. I am not sure how this is possible, and any help would be greatly appreciated.


#2

If it’s running for a few turns on the Playground, I would try adding some debug writes before and after the call to make sure it is indeed the C++ code that’s causing the timeout. I suspect there’s probably a bug in the code that only occurs on some given game maps which makes it harder to test locally. You can also use std::cerr in your C++ code as a way of printing stuff. Have you tried running a game locally and seeing if that crashes as well?


#3

Yes with further testing I have actually found the general location of the error in the c++ code, for some reason it did not occur to me that it was timing out on the next turn, not the turn the c++ code was working for. The problem is going to take a while to find, but it should just be a bug in my c++ code that made it past my initial testing. If it turns out to m=be more I will update the thread. Thanks.