Thread history

Fragment of a discussion from Talk:RoboRumble
Viewing a history listing
Jump to navigation Jump to search
Time User Activity Comment
No results

Your second approach seems good, it will need patches on the client side so that if a priority pairing needs to happen it only uploads the battles which contain one of the priority bots. This filter will work fine for the 1v1 rumble as well.

Why don't we wait to update the client until this can be fixed too?

Skilgannon (talk)21:50, 11 September 2018

The only reason for upgrading earlier is that those two bugs are very annoying when running rumble client 7/24.

And it generally takes monthes for fnl to release a new version in normal cycle ;(

Anyway, since those two fixes are unrelated to robocode engine, one should expect no performance difference if we cherry pick the fix back to 1.9.2.5.

Maybe we could release a special version of 1.9.2.5 for those running rumble 7/24, before the melee pairing fix is released.

Or, we may just ask fnl whether he could please release 1.9.3.4 soon after the meleerumble patch is applied.

Xor (talk)02:51, 12 September 2018

I patched robocode 1.9.2.5's roborumble by cherry-picking roborumble client fixes from 1.9.3.2 and 1.9.3.3

The patched roborumble.jar can be downloaded from:

 https://drive.google.com/uc?export=download&id=12lu8H4SlpBxOFRF5L8_koU5j7Cla5BLj

This should check participants list more often preventing retired bots from being battled and submitted nullifying smart battles. And on unstable network it won't upload 80000 duplicate battles for a single pairing any more. (See pulsar.PulsarNano 0.2.4 and ad.last.Bottom 1.0)

I suspect we should separate roborumble version and robocode version (since they are weakly dependent) and get roborumble bug fixes quicker than robocode, since roborumble bugs are generally more serious, and roborumble fixes has nothing to do with the rest of robocode users.

Currently fixes in roborumble takes almost a year to be actually deployed.

Xor (talk)05:57, 20 September 2018

I've enabled 1.9.3.3 for uploads. Let's try it for a while and see how it goes. If we notice anything strange, well, the rumble probably needs a wipe some time soon anyway, and definitely melee.

Skilgannon (talk)17:18, 3 October 2018

I'll upgrade all my clients later and upload the same bot of mine with different version number to see the impact on score...

The melee part is already discussed, but why the 1v1 rumble needs a wipe as well? And how long it should take to reload the rumble? Or should we run the current rumble as a backup in parallel until the reload completes? (so that new players can still submit their bots)

Xor (talk)17:40, 3 October 2018

Hopefully we don't need to wipe 1v1 rumble. I am more just concerned with bad configurations, running with Java10 etc that have accumulated.

Have you managed to make a patch for the melee priority battles?

Skilgannon (talk)17:45, 3 October 2018
 
Edited by another user.
Last edit: 04:37, 18 October 2018

Seems something is wrong, ScalarN is suddenly first in mini, micro and nano rumble ! And ofcourse second in roborumble, which in itself is quite an accomplishment.

GrubbmGait (talk)01:07, 18 October 2018

Just removed ScalarN d.160

The only related change in d.160 is experimenting lambda expressions

And it seems that codesize.jar cannot analyze bots with lambda expressions and returning non-valid results

We should disable 1.9.3.3 and wait for codesize fix along with my melee pairing fix.

Xor (talk)03:59, 18 October 2018