BeepBoop seems to be the new king
I think RoboRumble should be inclusive, which means the client should be run with the latest LTS version of Java to allow more Java versions to participate. LTS versions are also meant to be more stable, which help with more stable results.
I also updated the guide to suggest Java 17, which is the latest LTS version for now, instead of Java 11. Would you mind updating the Java version of your client?
Sure. I am upgrading my clients to Java 17. Seems to be ok, except the warning about depreciated calls to
WARNING: System::setSecurityManager has been called by net.sf.robocode.host.security.RobocodeSecurityManager (file:/home/evmik/misc/robocode-1.9.4.2/libs/robocode.host-1.9.4.2.jar) WARNING: Please consider reporting this to the maintainers of net.sf.robocode.host.security.RobocodeSecurityManager WARNING: System::setSecurityManager will be removed in a future release
I think it is addressed in the newer robocode versions, but rumble still accept only 1.9.4.2
It is never addressed. Also, there's currently no solution after Java removes SecurityManager, other than sticking to Java 17 (or newer LTS versions still with SecurityManager). Tank Royale could be the long-term plan, but it is only possible after some cross-platform sandbox solution having been implemented.
Btw, BeepBoop seems to be losing APS due to inconsistency in RoboRumble client (e.g. skipped turns).
BeepBoop runs fine on my computer, with the same result as (previous) RoboRumble and without skipped turns. Could you share some information about your environment, e.g. clients running in parallel, dedicated (not running any other task) or not. This may heavily affect reproducibility of RoboRumble.
I presume you are asking me. Well, I have several old computers pushing 10+ years, with which I use to run many roborumble battles for many years. All of them are doing other useful cron jobs so performance is not guaranteed. Also since the modern cpu throtle whenever they feel so, it might bring more jitter.
An interesting observation, I made all rumble clients by copying the robocode folder. So they all have identical `robocode.properties` file with the following content
#Robocode Properties #Tue May 06 09:49:19 EDT 2014 robocode.cpu.constant=7434452 robocode.version.lastrun=1.9.2.0
The striking part is that the cpu constant is the same on all computers. Also note that version is misreported.
So this might be the problem, since some machines are slower than my master computer. But I doubt that they factor of 2 slower.
I used to run RoboRumble on very old computers as well, but I think as long as the cpu constant is actually computed on the corresponding hardware, the results can be trusted if no other tasks are running.
If the computer is under heavy load, I generally multiply the cpu constant by 10 to ensure no jitter.
Misreporting `robocode.version.lastrun` should be fine, the property is only there for robocode to regenerate robots.database. It should have been overridden to the real version by robocode to prevent regenerating database each time, but anyway this shouldn't have any impact on the results, only slowing down the initialization time.
Anyway we need to wait Kev to upload an identical new version in order to check whether the above countermeasures actually work... It would be great if we could get the same results on 10+ years hardware (with moderate load), greatly reducing the cost of running RoboRumble.
Happy to upload a new version! Do you know if I can just change the version number in RoboRumble/Participants or do I have to upload a new jar? I'm away from the computer I normally develop BeepBoop on for a week.
