Client java version

Ok. Among recent literumble clients uploads we mostly have java8. The only exceptions are Dsekercioglu and GrubbmGait, we also have uncertainty on Anonymous uploads. GrubbmGait did not make uploads more recent than 4 days old, while I have score glitches on more recent releases. It could be abnormality in Java9.

One more thing. If I run GUI client at full speed with debug graphics toggle off, from time to time I see a error message in console from robocode 1.9.2.5 about java Threads dying. In such battles my score drops a lot, strange thing that it is not directly related to skipped turns counts. It could be a bug in robocode itself.

Does anyone see such phenomenon?

@ Dsekercioglu, would you mind switching off you liteclient for a while? Let's see if we can pinpoint the issue to java9 glitches.

@ all, if you are not running java8, please do not run liteclient for a week, starting from 2017/09/04.

Okay I'm closing it.

Or you can just use two versions in parallel ;) For me I develop my bot and run the rumble on Java 8, but I always test it on Java 6 before every release to make sure it works.

Just install them in different directories, and call java executable with the correct directories when starting robocode/roborumble.

Would adding a bot written with JDK9 and compiled with robocode would create a problem if there was an error with JDK9?

If there is an error in JDK, than sure it will be a problem.

But there might be a problem with JDK9 compilation, even if jdk9 itself is good, if the rest of us run literumble with java8. You bot might even not start in our clients.

Couple years ago when java transitioned from java 6 to java 7, we had this issue in rumble. People who made their bots with more recent java were in disadvantage and their bots showed a lower score.

I would suggest to cross compile your bot to java8 version, since according to the poll the rest of us run java8. Or go to extremes and make it compatible with java7 via retrolambda, as User:Xor does.

Java 7 compatible is a very good idea, I am on 1.7_051 (but intend to go to JDK 8 in the near future) and can't run battles for a handful of bots. Just look at the missing pairings of GrubbmThree 0.9a. Btw, other clients should do those, why don't they. But it seems that there are also a few bots that can't handle a Java 8 client, like tcf.Drifter and sm.Devil (see comparison between GrubbmThree and MaxRisk)

There is something fishy with literumble. In console, I see a lot of entries like

Ignoring: gh.micro.GrubbmThree 0.9a,cb.nano.Insomnia 1.0,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,dsekercioglu.ColdBreath 1.9,SERVER
Ignoring: dsekercioglu.HammerR 1.1,gh.micro.GrubbmThree 0.9a,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,suzushin7.nano.Galaxy03 1.01,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,nosteel.Welby 0.0.3,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,cs.PumpkinPie 1.0,SERVER
Ignoring: cb.nano.Insomnia 1.0,gh.micro.GrubbmThree 0.9a,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,dsekercioglu.Husky 1.9,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,dsekercioglu.Wyvern 1.0,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,dsekercioglu.Hammer 8.6,SERVER
Ignoring: theo.Hydrogen 2.1r,gh.micro.GrubbmThree 0.9a,SERVER

I see the problem. Your bot is entered as

gh.micro.GrubbmThree 0.9a,https://1drv.ms/u/s!Aj169YS0AhgMoQVZe6rd5zXnabUE

If I point a console downloader like 'wget' to this link, it downloads some web page and not the bot. You should no better but to trust your files to MS products which break all possible web standards and serve different content depending on the web accessing clients.

Bottom line, we cannot run your bot because literumble clients cannot download it.

Nothing to do with MS products, just an indirect download link. Dropbox and Google Drive do this as well.

Direct download link: https://qevpmw.dm2304.livefilestore.com/y4mj6ooicv7LFLWmhTf1-ozrosL2kMwHPfHvkZe77l8RQ6WUHPgBUlU3jh5ty3cqIgmjMjT94WgbXlvk7Kf3Wqhuft-mcv8ZhBZ5t5mL662MRNHJfTuEqA9Kx1NPU3_vM9VA9-m6i_MMlswLF6cJZmpYzx0oqrP-YIXlpNzTVRleyRYH4wAA-rvVXwF53qExNPYeRPUfUcAlz51BGUEQfONaA/gh.micro.GrubbmThree_0.9a.jar?download&psid=1

That link broke too. (Apparently OneDrive direct download links are not permanent.) Luckily, Rednaxela's server picked it up.

I will look into that this evening, I switched provider, so my old webspace is gone. It explains why I provided most (or all) of the battles although I have separate installs for robocode and roborumble.

Put them (version a b c and d) on GoogleDrive now. Still missing 7 pairings, so I wait a bit before switching to 0.9b

Yeah, I have exactly the same issue, but since I never saw anyone complain about this, I just ignored it. I can reproduce the issue with 1.9.2.6 as well.

I spent a lot of time reading Robocode's source trying to find a connection between that and skipped turns with no real success. Perhaps Skilgannon, which seems to be strongly related to how Robocode evaluate skipped turns as it is today, could share his thoughts about this.

When testing it with Roborio, there were a few times I fixed the running speed at 1000 TPS and could see skipped turn messages instead of these Thread errors, but this only happened when using my old GoTo code, which was really slow. I can't see skipped turn messages with Roborio 1.2.4, for example.

Then I tried to run Neuromancer with the same setup and could see a lot of these Thread dying errors as well, despite seeing no skipped turn messages when locking at 1000 TPS.

What is weird is not that the crashes are occurring at all. Maybe they really make sense. But the thrown exception instead of a helpful message is somewhat weird.

I sometimes see the ThreadDeath things as well, it seems completely sporadic. I can't reproduce it at all with the current dev version.

A possible issue is the platform it is run on. Windows has a system timer with a very coarse tick (30ms IIRC). We had to use the nanosecond timer in chunks of 0.999999ms to emulate the larger timer. Maybe this nanosecond timer is broken in later releases of Oracle JDK.

So I'm curious: the people who are seeing Moxiebot broken, are you running Windows? Are you using Oracle JDK or OpenJDK?

So, I was little distracted when I read the source for the first time. Now I've read it again.

This error is thrown when the bot must be stopped because it skipped too many turns in a row, since Thread.stop() is deprecated. Is that right? I can safely assume that if this error appears, then the bot has skipped too many turns in a row?

My only doubt is (it's more like a curiosity than anything else): what may cause the robot to skip this amount of turns when going full speed and not to skip any turns when going 1000 TPS?

I'm on OpenJDK 8 and Ubuntu, by the way.