Nominations 2017-11-25

Seems that an update is appropriate, as rsalesc.Knight(#4) and cb.Firestarter(#5) would enter. Next to that, updated versions of aaa.ScalarBot, gh.GresSuffurd and jk.Neuromancer and the re-entrance of ags.Midboss. Alas ags.RougeDC, kc.Hydra and pulsar.pulsarMax will (temporarily ?) disappear from the list. I will update the list tonight and try to start running a client.

Updated to Java 8, but I can't run battles for rsalesc.Roborio and xander.XanderCat. Seems that they are made with Java 9 specific things. So if anyone else with Java 9 can also run Gigarumble, the ranking can become complete.

Suddenly Roborio works, with some luck XanderCat will also . . .

Team rumble and Twin Duel are broken in Java 9. I won't upgrade until the Robocode engine is fixed.

The battle bugs (Bug-389, Bug-390) have been fixed, but only with version 1.9.3.0. The rumble is still stuck on version 1.9.2.6, because the server won't be upgraded until a regression analysis is made, and no one has yet volunteered to do that.

Both works fine here in Java 8, so maybe restarting the rumble/cleaning the caches helps? btw I would like to run Gigarumble as well, may you post a working config file for it? Hope that is included in the next release of robocode.

I removed the caches from all installations (RoboRumble and GigaRumble are separate installs), and now XanderCat also works! I can't run battles till I get home though, as the firewall at work prevents download/upload of necessary files and results.

My config file is listed in the discussion below. The gigarumble.bat file contains:

java -Xmx512M -cp libs/robocode.jar;libs/roborumble.jar;libs/codesize-1.1.jar; roborumble.RoboRumbleAtHome ./roborumble/gigarumble.txt

There are 4 bots vulnerable to BulletShielding present: Phoenix (#16), Chalk (#21), CassiusClay (#22) and Seraphim (#27). They earn their presence as they kick a lot of butts. But you are right, DrussGT only clings on the first place due to its Bullet Shielding. Diamond on the other hand does not use it.

Yeah, sure they do, but these are bots we can probably assume that won't receive new updates, so they will be BulletShielding-susceptible forever and, let's be honest, they will eventually be kicked off from top30. Maybe it will take very long, but they will. And of course, they will be kicked from top30 in part because of the legacy they left behind :P

And just to clarify, I would love to be wrong about those bots not receiving updates :P

And I'm curious about why there are so many bots NOT vulnerable to BS ;)

To effectively BS, you have to shoot the other bullet out of the air. So you have to exactly know where the other shoots. If the enemy moves, it will aim directly at you, but fires the next tick. Or maybe they compensate, but still they will not fire from the exact place they interpolate. Some bots just spin their radar and shoot whenever they see someone. Only good bots will fire really exact, and only they will be vulnerable to BS. When BulletCatcher came around in 2009, the actively developed bots took their countermeasures. Only a slight deviation from the 'ideal' angle is enough to let a BS miss. DrussGT tries to shield against a few different firingmethods, before it decides to fall back to its native gun and movement.

Thanks for the detailed explanations! I thought the firing control part should be mostly the same among a lot of bots (e.g. via copying the sample bots or OS bots), but it seems that this is also the part a lot of people made mistakes in, and there are also so many variants. Some bot aims precisely but fires whenever gun-turn-remaining is less than bot width, some forgot to call setAdjustXXX, some aims from the next tick but uses velocity from the last tick to predict... Such mistakes are so subtle that no one notices, until they incidentally found their bots not vulnerable to BSs. I know very few bots protecting themselves from BSs deliberately, most people get protected occasionally.

Are there bots like MoxieBot, which instead of intercepting HoT bullets, deliberately create a shadow to which they move on?

MoxieBot is quite cool, but unfortunately does not run reliably in the modern robocode engine. I think we still have a lot to learn from this bot.

I myself clearly have buggy bullet safety shadow code since I see enemy bullet in the calculated shadow zone quite often.

I think with a modern Passive Bullet Shadower, you can easily implement Active Bullet Shadower by brute-forcing firing angles — and actually with some math you should be able to calculate that directly.

I've been long thinking about some smooth transition between Bullet Shielder to Active Bullet Shadower and Passive Bullet Shadower. E.g., shield at first, then begin dodging. When there's a chance to shadow, do that deliberately if worth the miss.