BeepBoop seems to be the new king

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

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
 
 
 
Retrieved from "http://robowiki.net/wiki/Thread:User_talk:Kev/BeepBoop_seems_to_be_the_new_king/reply_(11)#BeepBoop_seems_to_be_the_new_king_6923"