Client java version

I took a look at your results. Your bot is performing below expectations, most prominently with 37.71% survival against sample.Crazy (???), which I cannot reproduce on my own computer.

I do agree that bugs (particularly ones that produce unfair results) ought to be squashed ASAP. However, you cannot expect the amount of work-per-turn your bot is allowed to perform to remain constant between machines (and possibly not even between battles or rounds). Perhaps a CPU-intensive background process is running, or the user decides to play video games, or the OS starts throttling Java, or the CPU drops to 0.15 GHz for no good reason (I've actually seen that happen), or gamma rays hit your computer and flip a bit in the tick time counter, or whatever.

My point was that high-CPU bots must adapt to changing circumstances. Too many bots just ignore SkippedTurnEvent, when it's practically a blaring flashing-red-lights warning from Robocode. You could respond by reducing CPU load, e.g. disabling features, virtual guns, second wave surfing, etc. It's better for your bot to function suboptimally than to not function at all.

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.