The game pace still needs work. I was originally working with Singularity to work out the proper pace for various actions in the game, but he moved on before we really got that nailed down. I'm open to feedback on how that can be improved. If any action seems too fast or two slow, it's a simple matter for me to tweak the timings.

Kaus, I do intend to tackle the CPC issues we discussed.

Keep in mind that I'm talking about "sync delays", which are different from the action delays. I know I got into that quite a bit with you in PM, but in a nutshell, action delays tend to be relatively long, and you always wait for the specified delay. Sync delays are typically very short, and you only wait if you attempt to issue a second command before the delay expires. Every action in the game has such a delay, and many of them are as small as 2 ms. So when I talk about changing these timings, I'm not talking about decreasing the move delay or other action delays. I personally think 250 ms is the lowest reasonable speed for move delays, and that's been the fastest speed for over a decade. But the sync delays are new and are set to the fastest pace possible while keeping CPU load at a reasonable level for each player session. It is very possible that some off these timings are too fast.

Every sync delay can be set independently. These are intended to pace commands. So if a command has more processing overhead, it needs to be paced more so that it doesn't overload CPU. The initial values for these delays were set based on a test-rig, with the goal to keep any action, when repeated, from pulling more than 5% of CPU.

The system is really a replacement of the old Commands Per Second setting, but it gives me more control to balance game load. A sync delay of 25 ms is the same as saying that particular action can be processed no more than 40 times per second. I call it a "sync" because the delay works to synchronize the actions to a particular pace. If the sync delay is 25 ms, and the action takes 15 ms to process, only a 10 ms delay is imposed so that the next action can take place at the 25 ms mark. This removes the influence of CPU on gameplay.

So if this was something someone wanted to do, the approach would be to

1) Make a list of several common scripted activities
2) Measure the time to run many cycles of each activity
3) Divide the measured time by the number of cycles to determine a per-cycle time
4) Present a description of the scripted commands for each activity, along with the measured time.

From there, I'll work out a set of timings to achieve these target timings.