Upgrade client version

Hi all

I've been thinking of upgrading the accepted client version. What are your thoughts on the matter? Have any of you tested extensively with the latest releases locally? Are there any changes in scores (or any changes that might affect scores) that we should do more extensive testing of first?

Finally 1.9.3.3 released, with RoboRumble battle duplicating fix, and with shorter participants list check period from 1.9.3.1 as well. It’s time to do a test and discuss to upgrade.

Question, what kind of tests should be done in local? Should we run a literumble locally and see whether it yields the same score as the main rumble? (which gives the best result but takes monthes). Or just using roborunner with a few robots (both 1v1 and melee certainly), and see their score is unaffected.

Just roborunner and a few bots should be fine. At some point it would be good to reset the meleerumble as well, since old bots get biased downwards by excessive battles against new (good) bots.

I've been always thinking about the pairing systems of meleerumble.

Once every combination of 10 bots had a run, the score is unbiased, which takes N = n! / (10! * (n - 10)!) ≈ 10^19 battles in current settings (n is the total of participants).

However we should get approximate score with feasible battles via monte carlo method. In current settings, ~10000 battles already gives a somewhat stable score (for the new participant).

Let each bot gets m battles, randomly selected from all (N / n) 10-bot combinations containing that bot, then the probability of meeting another specific bot in a battle is (N / n / (n - 1)) / (N / n) = 1 / (n - 1).

Assume that when a new bot is released, every battle contains that bot, then the probability of meeting that bot is 1 instead of 1 / (n - 1), which is highly biased.

To fix this, we have two options — mutate our current pairing systems to get unbiased score online, or to reset the entire meleerumble periodically.

Since the score of new bots are unbiased, all we need to do for an unbiased score is to ignore (n - 2) / (n - 1) biased battles randomly when calculating the score of an old bot. However this approach takes much more battles.

A more practical way is is, when bot A is added, for each battle, select another bot B randomly, and run melee battles containing those two bots as usual. A battle containing A, B and other 8 bots should yield 45 pairings, but only those matching (A, *) or (B, *) is taken into account. This produces 17 parings.

This scheme does not affect the pairings of the new bot itself at all, which is already unbiased; And for an old bot, the probability of being chosen as B is 1 / (n - 1), therefore the probability of a battle with A present being taken into account for old bots is 1 / (n - 1), the same as the unbiased one.

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?

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.

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.

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.

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)

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?

The rumble clients load version number dynamically, maybe we should tweak this to append Java version after version number as well to prevent running and uploading with Java 10 incidentally.

And since we have rolling average, the accumulated effect of bad configurations should be fixed automatically (after a lot of battles).

A patch for melee priority battle is harder than I thought, as the data structure (currently, very bad, string) needs a redesign for the extra 1 bit of information. And almost every line of code needs a rewrite as it depends on the implementation details of the (not extensible) data structure.

Done! After some refactoring, the rumble client should upload only pairings containing the prioritized bot, or containing the predetermined random bot when running prioritized battles.

The only flaw is that when the rumble server returns prioritized pairings, etc. A and B, if B is not evenly distributed, then B will get biased battles (meet more A). Is literumble using this feature currently? How not evenly distributed is bot B returned in this case?

Bot B is randomly selected from missing pairs, or if pairings are complete then randomly selected, with weighting biased towards lower number of battle pairs. It should be ok (and regardless, much much better than the current situation)

Great! I’ll send the patch to fnl after some test.

Now I need some test bed on literumble, or deploy one myself.

IIRC, everyone is able to create a new rumble game on literumble by writing rumble client config?

You can do it on literumble and I will delete when you are done.

Something strange happens.

http://literumble.appspot.com/BotCompare?game=roborumble&bota=aaa.n.ScalarN%200.011d.148&botb=aaa.n.ScalarN%200.011d.145&order=-Diff%20APS

ScalarN scores APS 0% and survival 0% (it was all 100%/100% before recent 1-2 days) against some bots with APS lower than 50, after 1.9.3.3 is allowed. However I've been testing my bot with 1.9.3.2 and 1.9.3.3 since the first day and nothing strange happens.

I noticed that Anonymous uploads in http://literumble.appspot.com/RumbleStats, which is the only machine besides my servers. I'm pretty sure this strange score does not come from my servers.

Is that possible to see whether some strange pairings comes from a specific uploader?

After more investigation, I thought that those strange score may come from some one who incidentally clicked roborumble.bat without proper configuration which however I never reproduced.

Using the latest robocode version as accepted one and allowing Anonymous uploads is risky as robocode has a lot of downloads per week and anyone who incidentally clicked roborumble.bat contributes without verifying configuration.

Maybe we should also modify roborumble client to add a field usually called "User Agent" and upload OS/Java Version etc. so that strange scores should be more trackable.

Another option is to disable Anonymous uploads when using the latest version of robocode, but this would only prevent incident roborumble runs and wouldn't verify user agent.

Honestly, I like the name gigameleerumble better ;-) Maybe we should switch to that instead?

I like gigameleerumble better as well ;) However is there a way to migrate old battles from meleeTo30 rumble to GigaMeleeRumble?

I personally like meleeTo30 since it describes participating bots. GigaMeleeRumble might be confused with ultra-large-sized bots, since we have nano and micro rumbles.

yeah, my first impression on gigarumble was those with code size greater than 1 GigaBytes ;)

However it would be confusing for two similar rumble having quite different name;) and giga also sounds awesome;)

Well, another special case is the initialization process. When every battle is a prioritized battle, should we have something special to prevent the slow down?

Potentially I could add something on the literumble side, yes. Also, if there are less uploads for melee then it can send back priority battles on every pair, or at least more often. Right now it only sends back priority on a fraction of the uploads.

Another question — will literumble return prioritized pairings all the time? or will it stop after each bot gets enough battles.

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.

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.

I submitted an issue: https://github.com/robo-code/codesize/issues/3

The codesize utility currently uses BCEL 5.2 which cannot handle Java 6, 7, 8 features properly. And the roborumble client has a logical bug that treats codesize calc failure as codesize 0 and allowing it to participant in even nano. The correct logic should be treating codesize calc failure as infinity, only allowing it to participant in MegaRumble.

I will definitely have to fix codesize as I have not touched it for many years. :O

Also notice that it will be faster to write to me a mail at fnl (at) users.sourceforge.net in order to have me fix as many issues related to RoboRumble as possible (this has a high priority to me). Just tell me to look on this discussion, if all details are already provided. This way you'll not have to wait for me updating Robocode, Codesize, RoboRumble etc. :-) And thank you for providing me with patches for RoboRumble. It is a great help to all of us.

Thanks for the contact info ;) And it is my pleasure to help as well.

Codesize 1.2 for Java 7, 8, 9 (Experimental) is ready.

Do we need to fix other stuff for RoboRumble before I make another release?

Sure, the meleerumble pairing algorithm also needs a fix. I’ll send you a patch then.

The melee pairing fix is now fully tested and available as a pull request:

https://github.com/robo-code/robocode/pull/13

discussions:

http://robowiki.net/wiki/Thread:Talk:RoboRumble/Upgrade_client_version/reply_(2)

Your pull request has now been merged and I have assembled and put a beta version here: https://robocode.sourceforge.io/files/robocode-1.9.3.4-Beta-setup.jar

If you are satisfied with this version, I will make the release. :-)

Thanks, I will test it.

It seems that the codesize part is not working completely. Both in roborumble and in the builtin editor. info: I'm using Oracle JDK 1.8.0_181 on mac.

It seems that codesize-1.2.jar cannot work on my machine at all. Can you have a test of this version as well?