Thread history
Viewing a history listing
| Time | User | Activity | Comment |
|---|---|---|---|
| 10:34, 12 September 2013 | Skilgannon (talk | contribs) | New thread created | |
| 12:10, 12 September 2013 | Chase-san (talk | contribs) | New reply created | (Reply to Better Priority Battles) |
| 12:24, 12 September 2013 | Skilgannon (talk | contribs) | New reply created | (Reply to Better Priority Battles) |
| 17:12, 12 September 2013 | Voidious (talk | contribs) | New reply created | (Reply to Better Priority Battles) |
| 14:39, 18 November 2013 | Skotty (talk | contribs) | New reply created | (Reply to Better Priority Battles) |
| 17:43, 18 November 2013 | Skilgannon (talk | contribs) | New reply created | (Reply to Better Priority Battles) |
| 17:53, 18 November 2013 | Rednaxela (talk | contribs) | New reply created | (Reply to Better Priority Battles) |
| 18:02, 18 November 2013 | Skotty (talk | contribs) | New reply created | (Reply to Better Priority Battles) |
| 18:29, 18 November 2013 | Skilgannon (talk | contribs) | New reply created | (Reply to Better Priority Battles) |
A while ago I made a change with the priority battles to do a global search for bots that didn't have full pairings, instead of a descent towards lowest by following the lowest bot of the current processed pairing. It really helped with making sure that all pairings filled out ASAP. I've now added something similar to battle count, so only bots with a battle count within 10% of the lowest will get priority battles once pairings are full. It is already making a difference in directing priority battles to more recently added bots.
Next to add is a "lowest APS against enemy" column to rating details.
Good to hear, thanks Skilgannon. I actually thought it had already been doing that for some time.
It did have priority battles based on battle count, but it was a 'gradient descent' method, so it gives a priority battle to the bot in the uploaded pairing with less battles, and eventually it will 'descend' to the bot with the least battles. The new method goes directly to the bots with lowest battles: if the currently uploaded bot is one of the 'priority bots' it intelligently selects which pairing to give as priority weighted towards pairings with lower battle counts, but the new behaviour is if the currently uploaded bot isn't one of the priority bots, and now instead of giving a priority battle to the currently uploaded bot with less battles it gives a random pairing to one of the 'priority bots'.
I've noticed that there are currently 4 bots in the roborumble which seem sort of stuck at around 950 pairings. I'm running my client, and it appears to just be running random pairings; it's not running pairings for any of those 4 bots. I do have a number of bots that my client won't run due to the "major.minor" version issue, but it's only about 30 bots, and there are will over 100 pairings missing from each of the 4 bots without full pairings, so that doesn't quite explain it. Might be worth looking into.
I'm not quite sure what was happening, I think it might have been due to changing code without changing version number. But I've re-deployed the code with a new version number and it seems to be fixed now, those bots are getting priority battles again.
Do you have a list of what 4 bots those were? I'm wondering because robocode-archive.strangeautomata.com doesn't automatically update when the same version number already exists.
eem.EvBot v4.4.5, xander.cat.XanderCat 12.7, zezinho.QuerMePegarKKKK 1.0, EH.nano.NightBird M. EvBot was the most recent release. My client was running quite a few battles for EvBot initially (when it only had about 400 pairings) but when it got up to the 900's, suddenly it was just running random pairings of all bots despite the 4 being short roughtly 150 pairings each. It appears as though all 4 of those bots are now getting priority again, as they have each picked up at least 50 pairings since this morning.
Appengine code, not bot code :-)
