I’ve noticed in my last few matches against AELGOO, both of us use a little more computation time than usual, but then at round 23 everything seems to be remarkably slowed down until we both bleed to death on computation time. I don’t know if Aelgoo is timing his turns or not, but I know 7.8 second turns shouldn’t be possible on my end, as there are some pretty hard cutoffs as it approaches 5 seconds.
I noticed the same thing. One of my algo uses every ms he can but stops everything after 5s. The turns take between 5000ms and 5050ms (5000ms + the time for the algo to hand over). But I saw between yesterday and today some turns above 6000ms which shouldn’t be possible.
1 Like
The only thing we did yesterday that should have an effect on prod is patch the engine, it could be some weirdness with how the engine swap was handled. Is this still happening, or was it just in a few games yesterday around noon?
I noticed it yesterday afternoon but the replay I shared was sometime today (assuming a steady play rate between 4-6 a.m.)
the last time I noticed it was for a match at around this time: 2018-12-12T16:24:28.110Z
Is there an update on this issue? It happened again here, which took place sometime in the last few hours.
Thanks for bumping this, i’ll talk to the guys doing most of the server/engine stuff and see if we can get to the bottom of it today.
1 Like
Sorry for insisting but has something been done regarding this issue?
it still happens to my algos to the point where sometimes they are crashing due to time out (cumulation of -1/-2 health over several turns) . It would be quit annoying if they were removed because of that! (my top 3 have currently 4,3 and 2 crashes for time out)
I am quite convinced this is not on my end but are other players still experiencing this?
this is what I do already: That’s why I found it very strange that my algos are able to compute for more than 5s.
Edit:
Do you mean something like: if the game state says that my previous turn took 6s, compute only 4s for the next one?
My algos are actually entirely made of C++. I use python only to do the interface between my C++ module and the game engine.
The C++ module stops after 4990 ms (I check almost every ms)
In ranked matches, the overall time is between 4993 and 5040 ms when everything is good.
In the playground, the overall time is very stable : always between 4993 and 5000 ms.
The issue is with some ranked matches that have turns way above 5500ms and sometimes it even reaches the 7000ms.
My latest strategy relies a lot on very heavy computation (I want to use the full 5000ms every single turn) so if I have to shrink it for safety measure because the time can’t be trusted, it will incapacitate it a lot.
My thoughts on controlling time cutoffs were more along the lines of checking at certain points (within my C++ code, my simulator is also 100% C++) and if a certain checkpoint takes longer than anticipated then I could make future decisions about how much computation to do, with maybe a hard cutoff above a certain threshold. Currently, I don’t do this because I don’t run that many simulations (a few hundred) and time isn’t an issue, but I have the framework in place and it works quite well. For C++ users I have been using <chrono>, but I’m sure there are lots of options.
I am currently using clock() with CLOCKS_PER_SEC from <time.h>
I will give <chrono> a try
(btw, I just breached the mark of 50k simulations per turn 
)
50k simulations per turn while im strugeling to have 300, the efficiency of the code became so important as the game goes on, good job. i can just imagine the things i could have done with 50k simulations per turn, i hope that maybe next seasone we will get a more efficent pathfinder in the starterkit. there is no doubt that even the slightest lead in number of simulations per turn can give you a big advantage.
it just happens again here (25 damage from time out). And this algo got removed because it is the 5th time… it was at 1945 elo
My algo ranked third at the moment (about 2000 elo) has 4 crashes already, so I am afraid that it will have a similar fate… 
@876584635678890
An algo that has ‘crashed out’ will not play any more matches. The reason we need to include time outs as a regular ‘crashing’ algo is so that we can ‘crash out’ while loop algos, which are fairly common.
Hey, just to report in on this, the two engineers best suited for this task did spend some time discussing solutions and how to better communicate the time constraints and ensure they are accurate, but they seem decently time consuming and will not be in before the global competition.
Its not a very satisfying answer, but ultimately you may have to try to enforce your cut off a little earlier. We may increase the crash count to avoid losing algos. We acknowledge that this is an issue on our end which is disproportionately affecting algos that try to get as much use out of their turn time as possible.
If you could do that before I lose my algo ranked third, I would be glad 
It is indeed a bit frustrating… If 7s are counted for 5s of computation, it means that I must use only 3.57s or so (if we assume the shift in time is linear)
but ok I will look into that
We are going to change it so your crash count won’t increase unless you timed out for over 30 health in one turn, as opposed to taking your last point of damage from overtime. This will make it so that it will only affect algos that are broken and not algos that are going slightly overtime.
4 Likes
Lots of simulations are nice, but it depends on what you do with them. Less can be more sometimes.
2 Likes
Thanks a lot @Isaac ! works like a charm!
I don’t know a lot about this, but maybe I was previously monitoring the computing time and now I am monitoring the real time (chronometer vs time reading). I don’t know the why of the difference but it is now very accurate even in ranked matches (at least for the past 8 hours)
To you have any suggestions for timing in Python? I thought “import time” and using time.time() was doing pretty well, but either my recent increase of computation time is showing this to be ineffective, or I’m experience the server issue much more frequently. I am starting and stopping the timer at the beginning/end of each simulation, perhaps I should just have one universal start at the beginning of my turn?