Same Turn Move Processing

[Chakakhan]

I created a patch that addresses issue number 788

The goal was to reduce the time between when a move command was issued and the unit responded.

Previously all move commands were asynchronously queued up and held until the start of the next turn. Then they were all processed at the start of the next turn. This caused a noticeable delay and made the game feel unresponsive. The problem was compounded when moving formations of units the formation proxy movement was delayed until the next turn, then the unit movement based on that proxy movement ended up being delayed a couple of turns out.

The solution was to continue to asynchronously queue up message, but at key points during the turn processing we will now process some of those movement request during the turn where they were queued up. This make the game feel more responsive. Formations feel a little better because we move the formation proxy and let the players re-path based on that movement all in the same turn.

This does not increase overall performance and in some cases can make it slightly worse. It only affects the responsiveness, not performance. I added a threshold value that limits the number of "same turn moves" that can be processed during a turn which minimizes excessive same turn re-pathing in massive battles. It also allows us to tune this functionality. This threshold value is in .../data/mods/public/simulation/data/pathfinder.xml, the value is called MaxSameTurnMoves. The default value is 16 based on some testing I did on my slowest machine. If you set this value to 0 the same turn move functionality is completely bypassed. So if you are testing and want to make sure this feature is not involved in an issue, you can turn it off.

The code still post all moves asynchronously so that the pathfinder code could potentially run in a separate thread.

Thank you to Philip for spoon feeding me the solution.

Cheers!

Edited June 19, 2011 by Chakakhan