Client java version
← Thread:Talk:RoboRumble/Client java version/reply (26)
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page.
Return to Thread:Talk:RoboRumble/Client java version/reply (26).
Agreed that the SkippedTurnEvent is mostly ignored, and that more could be done on this side. However, there is a reason that we have the CPU calibration, and that is because we want all environments to be similar. It is impossible to get consistent results if on one computer you can do second wave surfing with precise intersection and KNN gun with Gaussian kernel density estimation, and the other you have to fall back to single wave and a simple VCS gun. It would require all rumble battles to be contributed by a single machine, and then we are back to a standard environment.
While I take the blame for my bot performance.
I would claim that I am not ignoring the skip turn event. I have a counter for it, and I release bots which keep it low through the game. Typically in the rumble, it reports zero about every second round in 35 rounds game, in 45% rounds it is 1; in 2 or 3 rounds it spikes up to 7 or even 15 per round. Even 15 skips per 700 turns games is not too much to loose a game to sample.crazy with HoT gun.
So I still think it is the "Thread.Death" which is probably triggered by skipped turns.
I will try to reduce the bot CPU demand and see if the problem goes away.
ThreadDeath is just Thread.stop() doing its job.
See this article.
Are we actually talking about time-per-turn problem? I supposed, given the age of Robocode and Roborumble, that this is a well discussed topic and that every possible decision to make the system work fair enough while providing the "contributing" feature was already made. It seems that what we are talking about here is a bug. I know every environment is not equal, but even with the very little time I have on Robocode I could conclude a robot should work under the assumption that at least a reasonable quota of its turn time will be respected (even if in reality it's not eventually). If that quota is not being respected even after like, 10 battles, in a machine that is OK, and the results are absurd like the results Beaming reported, there must be a bug somewhere, even if it's on Beaming's side, and IMO it's worth it to discuss it and, maybe, to find it, since it may explain some other weird behavior in the future.