You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When you start a match with a bot that is started manually, you must wait for ~1-3 seconds before starting that bot for core to recognize it as ready. You should be able to connect with the bot immediately after the match manager has received the FieldInfo and MatchConfiguration packets.
This is not a trivial fix, and something I've know about for a while.
The issue is that since the bot technically connected before the match started, it's treated as if the bot was a part of the previous match. The solution would be to put the server in some kind of intermediate state as soon as the match start request comes in, but due to the nature of multithreading it might shrink the "wait" phase down to 0.01ms or something but it might be hard to guarantee the expected behavior if a bot connects at the same time as a match start request.
Either way 0.01ms is better than 1+ seconds. Perhaps some sort of global lock/flag can be implemented?
The issue is that since the bot technically connected before the match started, it's treated as if the bot was a part of the previous match.
I think we can find a solution that satisfies the condition mentioned by swz:
You should be able to connect with the bot immediately after the match manager has received the FieldInfo and MatchConfiguration packets.
At the point where the MatchConfig and FieldInfo are sent out, the server should have enough information to know that the new connections belong to the new match. Maybe we are just need to clear the agent id reservation earlier?
It depends on if the bot is being disconnected or if it's just not getting MC/FI. If it's the latter, we probably can just change the order something happens in to fix it.
Upon first looking into it, I don't see any obvious problems with manually booting a bot right after the MM gets MC/FI. There shouldn't be any problem with that; I'll have to try and actually replicate what is definitely a bug.
Activity
VirxEC commentedon Feb 2, 2026
This is not a trivial fix, and something I've know about for a while.
The issue is that since the bot technically connected before the match started, it's treated as if the bot was a part of the previous match. The solution would be to put the server in some kind of intermediate state as soon as the match start request comes in, but due to the nature of multithreading it might shrink the "wait" phase down to 0.01ms or something but it might be hard to guarantee the expected behavior if a bot connects at the same time as a match start request.
Either way 0.01ms is better than 1+ seconds. Perhaps some sort of global lock/flag can be implemented?
NicEastvillage commentedon Feb 2, 2026
I think we can find a solution that satisfies the condition mentioned by swz:
At the point where the MatchConfig and FieldInfo are sent out, the server should have enough information to know that the new connections belong to the new match. Maybe we are just need to clear the agent id reservation earlier?
VirxEC commentedon Feb 2, 2026
It depends on if the bot is being disconnected or if it's just not getting MC/FI. If it's the latter, we probably can just change the order something happens in to fix it.
VirxEC commentedon Feb 2, 2026
Upon first looking into it, I don't see any obvious problems with manually booting a bot right after the MM gets MC/FI. There shouldn't be any problem with that; I'll have to try and actually replicate what is definitely a bug.