Comms error with reference bot

Hello Entelectuals,

I’m trying to start up the runner with 4 instances of the reference bot (i.e. the one in the “SproutReferenceBot” folder) and I seem to be getting intermittent comms issues where bot commands aren’t received by the engine.

Basically I start up the engine, then the visualizer, then the same reference bot 4 times like so:

cd "SproutReferenceBot\SproutReferenceBot\" 
dotnet run SproutReferenceBot.csproj

and all seems well - for a while.
after a few seconds, the engine seems to stop receiving commands from some of the bots, and they wander off in a straight line forever.

See runner output here. You can see that commands are processed for all bots nicely at first, but then for some of the bots it’s always “Empty Queue taking last Command Down”.

As far as I can tell the bots all seem happy - at least, their output continues as usual after this happens.

Note also that I’ve modified the bot to use randomly generated token ids.

Any help would be appreciated!

Hi @japes, thanks for bringing this to our attention!

That is definitely not supposed to be the case, we’ll investigate and see if we can replicate and fix the issue on our end. Would you mind sharing a zip file or git repository with your changes to the reference bot so we can make sure it is definitely a bug in the reference bot? Thanks!

sure, here’s the bot: SproutReferenceBot.7z - Google Drive

in the meantime i’ll see if i get the same issues with any of the other starter bots…


just following up on this, am I the only one who gets these issues?

See it with the C# and javascript bots. Seems like a connection.invoke("SendPlayerCommand") never resolves, and that bot just hangs.

@japes I haven’t been able to reproduce this on my side, I’ve played multiple 4-player games without any hangups, so it might be unique to the js/C# bot somehow (I’m not using one of those two)?

@japes I was able to reproduce the issue, and I’ve found a fix:


shot @kobus-v-schoor !

Now maybe i can get started with the fun stuff!

Will keep an eye on the “issues” section of the github repo going forward, as well.

1 Like

Thanks @kobus-v-schoor!

I ran into exactly the same issue this evening.

@natash & Entelect team, will this be fixed in a new release? :slight_smile:

1 Like

Thanks for the PR @kobus-v-schoor!
@rfnel we were able to reproduce it on our side with both the reference bot and the TypeScript bot. We’ll assess @kobus-v-schoor’s PR and it should be fixed in a later version.

1 Like

I can confirm that @kobus-v-schoor 's fix sorts out the issue on my side :slight_smile:


What a legend that @kobus-v-schoor :muscle:


We have integrated @kobus-v-schoor’s fix for the runner hub, it will be going out in the next release.

1 Like

Thanks @natash! On your comment in my PR:

As for the parallel execution of bot commands, executing them in order was a decision on our part to reward bots for processing quickly. We did however try to limit this a bit by making sure that no bot can have more than one command per tick, so the benefit is just that your command gets executed sooner in any given tick.

Just want to clarify, the parallel execution I added was not to execute the bot commands in parallel, but to send the state updates in parallel (i.e. after all the processing is done) so that player 1 does not have an unfair advantage (by consistently getting the state updates before the other bots). Will this also be included in the release?

1 Like

Thanks for the clarification @kobus-v-schoor. We took another look at it and decided to integrate that as well, it will go in with the next release :slight_smile:

1 Like