Testing the Bridge on LiteRumble

[Cu3PO42]

I previously tried to wrap all bots from LiteRumble in the bridge to determine which would produce wrapped bots. I have now orchestrated battles including every one of these wrapped bots to determine which run without crashing. This test did not verify that they behave sensibly or correctly.

Out of a total of 1363 (including the known-bad team definitions), the following bots crashed before completing two rounds:

aaa.r.ScalarR_0.005h.053-noshield
abc.Shadow_3.84i
ahr.ice.Ice_1.0
ahr.ice.Ice_1.0.2
ary.FourWD_1.3d
aw.Gilgalad_1.99.5c
bjl.LoneDragon_0.5
catcat20.Lambda_0.017
catcat20.Lambda_0.024
cb.mega.RandomBot_1.0
CharlieN.Omega.Omega_1.03
cx.BlestPain_1.41
cx.Lacrimas_1.36
cx.Princess_1.0
darkcanuck.B26354_1.06
darkcanuck.Gaff_1.50
darkcanuck.Holden_1.13a
darkcanuck.Leon_1.01
darkcanuck.Pris_0.92
davidalves.PhoenixOS_1.1
ds.Versatile_RB1.0.1
eem.EvBotNG_v12.8
eem.EvBot_v4.6.16
eem.EvBot_v4.6.4
eem.IWillFireNoBullet_v2.4
eem.IWillFireNoBullet_v2.8
florent.XSeries.X2_0.17
gg.Wolverine_2.0
jab.avk.ManuelGallegus_0.6
jam.mini.Raiko_0.43
justin.DemonicRage_3.20
justin.DemonicRage_3.4
kawigi.spare.SpareParts_0.7.6nosnd
kc.mega.BeepBoop_2.0
kid.Gladiator_.7.2
kid.test.NightFox_.2
krillr.mega.Psyche_0.0.3
labg.Cataclysm_2.05
lrem.magic.TormentedAngel_Antiquitie
lunchie.Lunchbox_0.93
lxx.Tomcat_3.68
nat.PallasHawk_1.0
ntc.Swim_0.9
pedersen.Ugluk_1.0
pedersen.Ugluk_1.1.1
pe.SandboxDT_2.71m
pe.SandboxDT_3.02
qohnil.blot.BlotBot_3.61
rh.Intra_2.1DomoKN
rjw.RabidWombat_0.71
rsalesc.melee.Medina_0.4.5
rsalesc.melee.Monk_0.3.6c
simonton.micro.GFMicro_1.0
spinnercat.Robovirus_2.718
stelo.RamTrackSurfer_1.2
synapse.Geomancy_15
synapse.rsim.GeomancyBS_0.11
techdude.forest.FlamingForest_1.1
throxbot.ThroxBot_0.1
tjk.deBroglie_rev0108
voidious.micro.Jen_1.11
zyx.mega.YersiniaPestis_3.1

Further, some pairings resulted in in "invalid results" where Robocode TR did not return exactly two scores for the two involved bots. In these cases one bot seemed to not participate in battle, but it didn't hard-crash either.

dsx724.VSAB_EP3_ATR_1.1
hlavko.micro.Flex_1.5
jk.mini.CunobelinDC_1.2
gh.mini.Grimmig_0.3.6
as.xbots_1.0
buba.Buba_0.3
d414.nano.Quantum_1.0.0
cb.Domogled_1.2
wcsv.Stampede2.Stampede2_1.1.0
synnalagma.NeuralPremier_0.51

I have not yet performed analysis why any of these bots are crashing, but I hope this is useful as a reference towards identifying and fixing further issues with the bridge.

[flemming-n-larsen]

@Cu3PO42
Really cool! Did you create an application or script to automate the task?

I have been investigating a bug I first saw when running the original sample bots from orig. Robocode with the bridge.
I found out that Crazy do not bounce of the wall as it should when the HitWall event occurred.

This weekend, I pursued this bug and found out that the internal event for driving the API and the Bot event queue needs to be separated in the Bot APIs. This is a major bug, which might potentially also solve other issues, like some found with the bots you discovered.

I made a fix with the Java API, which fixes the issue, and now I will do the same for the .Net API. After that, I need to make some additional fixed for the Bridge as well. I hope some of the annoying "ghost" issues will vanish after that.

[Cu3PO42]

I have looked into BeepBoop crashing and have identified the cause. The RoundStartedEvent fails to be deserialized due to a missing default constructor, leading to the relevant event handler in BeepBoop never being called. Said event handler is where some state is being initialized however, leading to a NullPointerException down the line.

[Cu3PO42]

Really cool! Did you create an application or script to automate the task?

Thank you! And I did! I cobbled something together with my in-progress battle runner. As it stands it's not currently very useful for a general consumer, but I plan to eventually release it.

when the HitWall event occurred.

Did you check if the bot actually received the event? With the issue I encountered with BeepBoop, there was never a RoundStartedEvent as far as BeepBoop was concerned. I could imagine this being a similar issue here.

internal event for driving the API and the Bot event queue needs to be separated in the Bot APIs

I'm not sure I'm following right now. Are you saying the bot must not have access to the same event object as is used on the WebSocket side of the API?

[flemming-n-larsen]

Did you check if the bot actually received the event? With the issue I encountered with BeepBoop, there was never a RoundStartedEvent as far as BeepBoop was concerned. I could imagine this being a similar issue here.

The issue with the event current is that all events go to the event queue before the event handlers are triggered. Old events are removed after two turns. Hence, events will disappear, if other event handlers "take several turns" to complete.

Hence, I now split up event that go for the bot event queue, and events that go for the internal API handlers, which must typically be handled immediately, and not later (which is the case with the event queue). As mentioned, I am currently working on this, and it already solved a great deal of issues I have observed with the events.

[Cu3PO42]

Feel free to let me know when this is resolved and I will be happy to rerun the test.

[flemming-n-larsen]

I just finished the fixed on this branch:
fix-internal-event-handling

I am testing it to make sure I did not introduce any unwanted side-effects. I fixed the event handling for both Java and C#

I am also working on fixing the event handling on the Robocode Bridge. But this work is still in progress. I hope I will have it ready in this weekend.

[flemming-n-larsen]

@Cu3PO42

Feel free to let me know when this is resolved and I will be happy to rerun the test.

I have now fixed the event issue in the Bot API and the same for the Bridge. I solved lots of strange bugs seen with the bridged bots. So it was definitely a step forward.

I tested 10 random bots out of those you listed that did not make it for 2 rounds. Fixing the event issues did not have a positive impact on those. I guess the bots do something with the API that makes them hang.

I will start fixing some of the issues logged by the bots as exception, e.g. when their properties files cannot be found.