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

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

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.

Xor (talk)18:05, 3 October 2018
 

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?

Xor (talk)02:44, 4 October 2018

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)

Skilgannon (talk)17:23, 4 October 2018

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?

Xor (talk)02:56, 5 October 2018

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

Skilgannon (talk)08:58, 5 October 2018
 

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?

Xor (talk)04:02, 7 October 2018

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.

Skilgannon (talk)22:01, 8 October 2018
 

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

Xor (talk)05:18, 7 October 2018