New Starter Pack Release: 2021.2.2

Greetings Challengers!

We have released a new version of the starter-pack, available here .

What’s been updated:

  • Fixes commands being ignored from Java and some other clients that send enum members as integers
  • Adds messagepack support on the runner for clients that can leverage it
  • Fixes issue with torpedo salvo count not being considered
  • Fixes issue with torpedo salvo count not being decremented when torpedoes are fired

If you currently are on a starter pack, please grab the latest from above - version 2021.2.2

If you have cloned the repository to use docker or just to investigate, please ensure your clone is up to date!

P.S: If you are interested in using the MessagePack protocol with your SignalR Client, please review the documentation here:
Use MessagePack Hub Protocol in SignalR for ASP.NET Core | Microsoft Docs

It’s been implemented to improve performance between the runner and engine on our infrastructure, but this comes with the benefit of any client being able to choose whether they communicate over MessagePack or JSON.

There is no net gain between using one or the other for bots, as you can still only issue one command per tick, and that tick time is still 75ms at minimum, from the time that the last game state had been successfully published to all bots.

Entelect and the Challenge team however are not officially supporting MessagePack for bot communication, and it is purely “Use at your own risk”. Our recommendation to any issues raised when using MessagePack will be to switch back to the JSON protocol.

Thanks, James



Good day, @James.Reynolds just started working on this tournament, it seems like there is a problem with the file for this release as all the reference bot just disconnect and the file also does not close all its tasks properly which led to 100% of my CPU usage and had to kill the tasks in the task manager.

Hi @Yasin , thanks for the info. Will look into it and get back to you as soon as possible

Hi @Yasin,

This should be fixed in the next release, which will go out tomorrow.

1 Like

Hi folks,

I’ve just added support for torpedoes to my Java bot. However, it looks like the game engine is ignoring any FIRE_TORPEDOES commands that I issue. The literal value for the command in my PlayerActions enum is 5.

I log the tick number and command in my code, and I’ve cross-referenced that to the game engine output against the reference bot. The logs below illustrate the issue.

My logs:

Player: GameObject{id=84185cc8-dd77-43ed-95ba-97b56895a637, size=41, speed=5, currentHeading=333, position=Position{x=-213, y=267}, gameObjectType=PLAYER, activeEffects=0, torpedoSalvoCount=5}
Game state updated.
Tick: 576, Action: PlayerAction{action=FIRE_TORPEDOES, heading=8} ← SEE HERE
Sent action in 1ms.
Player: GameObject{id=84185cc8-dd77-43ed-95ba-97b56895a637, size=41, speed=5, currentHeading=333, position=Position{x=-209, y=265}, gameObjectType=PLAYER, activeEffects=0, torpedoSalvoCount=5}
Game state updated.
Tick: 577, Action: PlayerAction{action=FORWARD, heading=333} ← SEE HERE
Sent action in 2ms.

Engine logs:

[INFO] [Logger]: Tick: 576, Adding to log
[DEBUG] [PLAYERACTION]: PlayerAction: [ action: Forward, heading: 189, bot: 135f1188-1023-443c-ab07-5eb6efe49bc9 ] ← SEE HERE; only one action in tick 576 where I issued FIRE_TORPEDOES
[INFO] [TIMER]: Game Loop Time: 77ms
[INFO] [Engine]: Tick: 576, Player Count: 2
[DEBUG] [TPS]: Start of tick
[DEBUG] [StopLog]: Simulation complete, Time: 0, Ticks: 563
[DEBUG] [StopLog]: Informed Consumed Bots, Time: 0, Ticks: 18
[DEBUG] [StopLog]: After Tick SC Complete, Time: 0, Ticks: 194
[DEBUG] [RunLoop]: Processing tick took 0ms
[DEBUG] [StopLog]: Got Published state, Time: 0, Ticks: 167
[INFO] [GameStatePublished]: Tick: 577, Player Count: 2, Object Count: 37
[DEBUG] [RunLoop]: Published game state, Time: 0
[DEBUG] [RunLoop]: Waiting for Tick Ack
[DEBUG] [RunLoop]: TickAck matches current tick, Time: 0
Previous Target exists, updating resolution
Player action:1:190
[INFO] [Logger]: Tick: 577, Adding to log
[DEBUG] [PLAYERACTION]: PlayerAction: [ action: Forward, heading: 190, bot: 135f1188-1023-443c-ab07-5eb6efe49bc9 ]
[DEBUG] [PLAYERACTION]: PlayerAction: [ action: Forward, heading: 333, bot: 84185cc8-dd77-43ed-95ba-97b56895a637 ] ← SEE HERE; here when I issue FORWARD, both my bot and the reference bot have commands processed by the engine.

Is this a potential issue affecting Java bots?

Edit: Just to confirm - this is on the latest version of the starter pack.

Did you check if your command is executed a a few ticks later?

I run a Python bot and have a similar problem. In my case the engine seems to fall behind and then executes the commands on the next tick or several ticks later than when I issued them.

Hi Thinus,

That’s interesting, thank you. I’ve had a look at the engine logs, but it looks like the engine never executes a FIRE_TORPEDOES action for my bot. The only instances where I can see it happening is when the reference bot uses torpedoes.

I had a look at the game engine source code and I believe I have found the issue. The recent fix for Java bots introduced the JsonStringEnumConverter.

The enum used by the engine looks like this.

My enum was declared as follows, following the same conventions as the starter bot.


If I remove the underscore, it looks like the engine is able to map and execute the correct commands.

Hello Again!

The crosstalk between Java and .NET is really strange here.

For testing purposes, the reference bot uses integer values, avoiding sending the enum over the wire entirely and just sending the action number.

Can you confirm whether your bot is sending a string or an integer over the wire for it’s PlayerAction payload?

And just on the addition of the StringEnumConverter, it was in the engine from launch. It was removed in 2021.2.1 due to possible performance issues on the infrastructure, but that was what caused the engine to completely ignore commands from Java bots entirely - so this release added it back.

Hi @James.Reynolds ,

I pulled the code for sending actions straight from the Java starter bot, so SignalR is determining what goes over the wire behind the scenes. Based on the behaviour I can see, I’m guessing that it’s a string.


I think this also explains why I could never get the afterburner working in round 1. My bot was sending afterburner commands like crazy and never going any faster. :sweat_smile:

If you can, maybe convert it to an int before sending?

Otherwise please ensure the naming matches, and it should work.

The enum serialiser will accept either the exact name or the integer value.

Hi @thinus

This was an issue with run-away on the engine previously, but was fixed in back in phase 1.

Can you please DM me some logs indicating this issue, and include the version of the runner and engine you are using?

I am running on release 2021.2.1. 2021.2.2 fails to run on my machine.
My bot checks for a change in gameState ( botService.gameState[0][‘world’][‘currentTick’]), if it finds a change it executes the bot.

if tickvalue != previoustickvalue:
previoustickvalue = tickvalue
print(’@@@ my bot starts - tick’, tickvalue, ’ time ‘, time.time())
action = 1
heading = 45
botService.computeNextPlayerAction(bot.object_id, action, heading)
actionList = [botService.playerAction]
tickvalue = botService.gameState[0][‘world’][‘currentTick’]
print(’@@@ my bot stopped - tick ',tickvalue, ’ time ', time.time())
Execution time is less than 2 mS. I then run it against 3 Reference bots

Sorry. The editor lost the Python indentation.