Non-standard Tick Rate

[NicEastvillage]

Needed for backwards compatibility with old v4 bots

https://wiki.rlbot.org/botmaking/tick-rate/

[VirxEC]

I don't think this should be added into core - with v5, missing a tick can mean missing information. All v4 compatibility (creating the old types, limiting tick rate) should be left to whatever compatibility layer is created for the bot's specific programming language. All v5 bots should run @ 120tps, and it wouldn't be hard to make that 60tps on the language interface side if you're confident that's something you want for your bot/script.

[NicEastvillage]

That is a good point. The tick rate logic should be close to the bot logic. However, a bot running at 60 tps would result in a 50% performance metric, unless the bot duplicates each output. If the bot is slow, that is not possible without additional threads. So either we accept that, or we simply have a setup message to indicate the bot's intended response rate (e.g a new SetReponseRate message or a field in ConnectionSettings) and normalize the performance metric based on that.

[VirxEC]

Due to the fact that only sending half the number of packets would result in missed information, it would be best to accept that some bots will run more than one thread. Bots devs should be more creative with minimizing response times to achieve 120tps output - like, for example, offloading expensive path finding logic to another thread or using a compiled language. A bot running at 60tps is running at 50% and I don't think we should change that - even v4 reported 60tps bots to be running at 50%.

[VirxEC]

That being said, there should probably have be a mechanism so bots don't get backed up on processing old game tick packets when they're processing really slowly. However, it is possible to implement this on the language interface side by reading all information from the socket and only calling get_output on the latest GameTickPacket that's waiting.

Doing it in core by refusing to send new GameTickPackets until player inputs are received could be detrimental to bots as instead of skipping ahead to the newest one they will still be operating on old data instead of the newest data like what would happen if the above mechanism was implemented.

[NicEastvillage]

That being said, there should probably have be a mechanism so bots don't get backed up on processing old game tick packets when they're processing really slowly. However, it is possible to implement this on the language interface side by reading all information from the socket and only calling get_output on the latest GameTickPacket that's waiting.

Definitely, v4 behaves like this, though I don't know where the logic is implemented in v4.

[kipje13]

That being said, there should probably have be a mechanism so bots don't get backed up on processing old game tick packets when they're processing really slowly. However, it is possible to implement this on the language interface side by reading all information from the socket and only calling get_output on the latest GameTickPacket that's waiting.

Definitely, v4 behaves like this, though I don't know where the logic is implemented in v4.

This behavior is inherent to the IPC used. v4 uses a single instance of the game state in shared memory which all bots get to read from (polling). If a bot is slow it just means that the game state is updated more than once before the bot reads it again, i.e. a dropped frame.