Bot Command send and update game state delay

I am working on my Java bot and when running the first initial times, I saw a bit of a delay from when my command was sent, and receiving a game (bot) state that is reflecting that command.

The issue I am seeing is that my command is sent on tick 2, and are still receiving “old” game (bot) state for the following 4 ticks. I know that the processing of my command will only happen on the next tick (tick 3), and then on tick 6 I see the update game (bot) state.

So what I mean with out dated game (bot) state is.
I send 1 unit to the scouting tower on tick 2, and only see that the ‘traveling units’ field change on tick 6.
(Although the ‘traveling units’ are wrong, but that is another topic).
I know that the units have traveling time before the resources of that tower will be showen.
But to my knowledge, the ‘traveling units’ should be updated by tick 3/4.

This that delay correct, or is that something that is weird?
Do you guys also experience this behavior?

With my NetCore bot I have noticed that when I send an immediate Scout command at startup that the unit only start travelling on tick 4. It looks to me like a “warmup” delay. After tick 4 all goes as planned. The JS Reference bot also start travelling on tick 4.

Last year I personally found a lot of inconsistancies with ticks,
So much that it was impossible to get consistancy with a Genetic AI,

I would end in cases where my bot kept missing moves by 1 turn, when i forced a round delay. the same thing happened.

And my goal was to build a Genetic solution. When my Genetic AI kept failing due to really strange cases (and i admit I probably did not give it enough time)

I didnt even bother submitting what I had, even though i had the perfect Assassination (Teleport Kill)

I was too unhappy with the state of my actual bot.

What I am saying is for me last year ticks were unpleasant.
But this year im pretty amped to get over that.

I feel beyond everything the tickrate should be consistant.

If a command is sent in round 2, it has to be processed in round 3.
The runned should not add a randomized delay.

If its only initially, thats simple as we can give the runner a startup delay to make sure everything is right.

Just random thoughts on my end.
Tick processing last year was one thing huge challenge.

This year so far is not as impactful. Mainly because the game is pretty linear.
And its easy to program a near perfect efficiency (though the challenge here is seeing the solution)
Where other times seeing the near perfect solution would be easy but programing it would be hard.

Just my thoughts.

Im excited for this year and it could be a really great.
Will get pretty intense if we look longterm. Would be interesting to see what kind of sabotage players get up to as we add more featured.

Thank you @kuifie , I will test that and work according to that.

Yeah @WillieTheron , lets hope the tick consistency is stable this year.

I tested and added a bot warm up delay and the command still only reflects on the game state 4/5 ticks after sending the command

After working on my bot and with the engine, there is still some delays happening, but not just at the start of the match, but during the match as well.
When I send a command to light campfire, (which is an instant effect, AFAIK), but I only get heat 3-5 ticks after sending the initial command.
There is a lot of inconsistencies.

I assume it is because the engine does not wait for commands, when you get a new game state on tick 10, the engine already started with tick 11 , and by the time you send your commands the engine needs to queue them and probably already started on tick 12, so your commands gets pricessed tick 13 and is shown in tick 14 game state

That seems to be the case yes. But it shouldn’t be that way. Receiving an updated state on tick 3/4 tick after I sent my og command within 3ms of getting the state, is not how long it should take. IMO, when giving the state out to the world, those 50ms that the engine is waiting for commands, should be that, but also processing the commands in the tick to get an updated game state based on your previous tick’s command in the next tick.

But it’s just my opinion, the state shouldn’t take that long to reflect my commands. It’s working with 3 tick old state at all times.

For me, I have had a similar issue. Running a Python bot.

After 2500 ticks, I would end up for 8 people because my bot sends the commands to late it seems. Calculation time is between 10-15ms max. If I run the same bot on my PC but I turn down the Tickrate to 1000ms, I get like a bazillion people on my map. Which is odd…

I think I know the problem though:

https://forum.entelect.co.za/t/python-and-signal-response-time-issues/1386?u=gatkramp