Woa, careful there Keith. The AI is getting too smart for the engine to handle.
Well, fast and smart are two different things. For a little bit there it reminded me of a video I saw of someone playing an SC2 tournament. But the overall result was "dancing" to the extreme. So getting it to prefer "stay the course" just enough to avoid that while not closing out the ability to adapt to a situation is a bit tricky.
On a more serious note, what happens? CPU hogging? Race conditions? Excessive locking?
There were some logical race conditions. Nothing that would crash the program or whatever, but the AI would give an order and then get back around to checking the same unit for orders and giving new orders before it got an updated state on the unit from the first order. There were some safeguards to prevent this (it did have to wait to hear an acknowledgement that the
order has been executed on the main thread, but that doesn't include a state update on the
unit). Before you didn't
usually notice this because there was a lot of stuff slowing the AI thread down (stuff that was needed at the time it was written, but things have changed over 4 years, etc). But sometimes you would notice this in some of the forms of unit "dancing" you've seen before. It just depended on a particular timing of AI-thread-slowness and main-thread-slowness. That is, race condition.
Anyway, it isn't too hard to just tell it "never ever give an order to a unit if you don't at least have a state update on that unit since the
last command you gave it" but there are still a few gaps I'm closing up.