Mpf, I'm guessing there's still some cases where that isn't enough.
I think the simplest fix here is adding a bit of leeway in Visual Actor to be honest.

The 'most correct' fix is probably to make the "speed at which the unit switches to the running animation" a template parameter instead of using the walk speed, since there is no real reason to switch to running when right above the walk speed. Might do that if it's easier.

Maybe it's just the resetting state @Angen mentionned :)

The camel issue does appear to be only the thing Angen mentioned. Doesn't mean there aren't units for which things get wonky from rounding though.

2010-11-22-QuakeNet-#0ad-dev.log

@Philip`: UnitAI is complex :-(

• Philip` has decided that writing unit tests is probably a good way to deal with it

@Philip`: Yay, my test is now non-useless
@Philip`: and I only had to construct 14 components in order to test one part of one UnitAI properly
@Philip`: EmjeR: Because it finds the bug I was trying to test, and also it tells me that if I make the obvious fix then a different case breaks

(Just encountered this while reviewing, not intending to imply that this should be done)

In rP22249#33460, @elexis wrote:

2010-11-22-QuakeNet-#0ad-dev.log

@Philip`: UnitAI is complex :-(

• Philip` has decided that writing unit tests is probably a good way to deal with it

@Philip`: Yay, my test is now non-useless
@Philip`: and I only had to construct 14 components in order to test one part of one UnitAI properly
@Philip`: EmjeR: Because it finds the bug I was trying to test, and also it tells me that if I make the obvious fix then a different case breaks

(Just encountered this while reviewing, not intending to imply that this should be done)

Was that test ever added ?

svn log test_UnitAI.js