Spring RTS Engine

Yet another stumbling block on the road to making a great AI, I've recently been running into this error:
which I know to be coming from the AI I'm working on. What's odd is, the AI I was testing against uses pathfinding much more extensively (pushing out about 4 waypoints per unit constantly) and that AI did not have the same problem.

My springsettings.cfg already includes: so I assume either I was misinformed about something, or more likely something in the AI is using up pathological amounts of bandwidth.

So I guess the question is what kind of things use bandwidth and what kinds of things don't? Ex if I call unit.getHealth() does that use bandwidth? (In java, although I doubt it's particularly language dependent) I assume that giving orders does, but I've already done quite a bit to minimize redundant order spam.

This is caused by sending messages over the network and is almost always due to commands being sent. It is not caused by any queries.
Sadly it's designed towards multiplayer, and not singleplayer.

Note that there are also other config values:
LinkIncomingMaxPacketRate
LinkIncomingSustainedBandwidth
LinkOutgoingBandwidth

I just put all of this on ridiculously high values and it tends to work well

Delay and split in time commands so it won't send 1000 of them in same frame.
Don't resend commands (like move positions) if they didn't change.

Situations where you're sending too many commands at once are problematic for other reasons, and can imply other problems are causing them from within the AI.

NTai and several other native AIs got around this by implementing a command queue, which issued commands on update at regular intervals, in batches. This way we could guarantee that no more than X commands would be given per frame. Ideally this would only throttle things when in late game and there were a lot of units, but sometimes it would come into play earlier.

E.g. an improperly built unitmovefailed call in could trigger a move command that immediatley failed causing a loop and command spam. The solution here is to have the unit logic wait a small period of time before deciding what to do, be it 5 or 20 frames, which makes a huge difference. Especially if the calculation done on that callin is expensive ( or it isnt but its running a lot )

d'oh. It turns out I had removed a lot of the bandwidth limiting stuff recently so it was trying to assign 30 workers per second plus whatever else.