BeepBoop seems to be the new king

Fragment of a discussion from User talk:Kev
Jump to navigation Jump to search

Btw, BeepBoop seems to be losing APS due to inconsistency in RoboRumble client (e.g. skipped turns).

BeepBoopDiff.png

http://literumble.appspot.com/BotCompare?game=roborumble&bota=kc.mega.BeepBoop%201.21&botb=kc.mega.BeepBoop%201.2&order=-Diff%20APS

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.

Xor (talk)13:46, 13 January 2023

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.

Beaming (talk)06:19, 15 January 2023

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.

Xor (talk)08:22, 15 January 2023

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.

--Kev (talk)20:15, 16 January 2023

I think you should recompile. The robot.properties has uuid and version field. I am not sure that they are checked, but it is better to avoid rumble confusion.

Beaming (talk)01:36, 17 January 2023

They are verified by the rumble to prevent typos. So at least repackaging with an updated robot.properties is needed.

I can also release an identical version of ScalarR to verify the results.

Xor (talk)06:17, 17 January 2023