Look, people, instead of wasting time on theory, try this test. Let us know the results, or better yet, post a replay, so that we can repeat the experiment on our machines and actually have a scientifically-repeatable experiment with various hardware mixes.
1. Start up a server. Set up a game with NanoBlobs.
2. .give yourselves 500 of any land unit in NanoBlobs.
3. Tell them to all go somewhere.
4. Watch what happens to your CPU usage. You will see CPU usage hit over 50%(which is when problems start occuring) in waves. It is not always the first instant after the move command is issued that is the worst, either.
Try a second test:
1. Start up a server. Set up a game of AA.
2. .give yourself 100 Peewees.
3. Move 'em around a little bit, to randomly distribute them.
4. Kill 'em with something light enough to leave a corpse.
5. .give yourself 50 more PeeWees.
6. Give them a move order through the field of dead.
I wish there was a cleaner way to set up the second test, but nobody has
bothered to construct a simple mod for stress-testing purposes that is 3DO and includes corpses, and I'm not about to build one for you guys, when you could do it yourselves in about 20 minutes.
My points here are simple, testable, and repeatable:
A. The amount of CPU used during events is not always maxed at start (when the pathfinder is doing initial work). It often actually peaks later.
B. Corpses add a lot to the CPU use, because they aren't handled well by the steering / collision code.
Basically, there are dozens of ways to make Spring lag out to the point of desync with the older mods, and I'm frankly surprised that desync hasn't been a bigger problem, except that everybody's been playing mods with slower gameplay than NB. For example, the FALL | SMOKE | FIRE | EXPLODE-ON-HIT code is veeeeeeeeeery inefficient and slow. It breaks up the model and makes new collision spheres on the fly, so that it will bounce on the ground. If you blow up enough stuff with fancy explosions in multiplayer, it is quite likely someone will desync. That's one of the reasons I took most of that code out've NB... it was waaaaay too slow for gameplay I wanted, and would've caused problems everywhere...
Oh yeah, and did I mention that because somebody thought it'd be great if the broken parts could cause damage, that every part freed up by FALL events becomes both something with a hitsphere, but also gets treated as a WeaponProjectile, and is thus being used by sync code, instead of just being a desynced special effect like it probably should be?
So, what we need is for someone to test my theory, that the primary cause of desync is people with crappy systems or lousy 'net connections. As Lazorwolf's post indicated, it eventually was shown that somewhere along the way, Spring was desyncing due to packet loss or fragmentation.
Perhaps Spring's bandwidth usage needs to be studied more- maybe it has a very low maximum throughput level that is reached too easily on high-latency connections, or maybe it's flooding lower-bandwidth connections, because a lot've things that shouldn't be synced still are being synced, or maybe my theory is correct, and CPU usage spikes are the true culprit- in which case, the only real remedy on the software end is better-optimized code for the primary culprits (not an easy or pleasant task, I wager, and I'll be the first to say that I am not skilled enough to even try). However, there is ALWAYS GOING TO BE a ceiling, people. The urge to keep Spring at such a low level that it is always playable on 800Mhz machines is just stupid, when it costs so little these days to build a machine that will run it with ease.
I played NanoBlobs on a co-worker's Core Duo machine the other day at Work, and was amazed how silky-smooth it ran, even with insane unit counts. His GPU sucks compared to the one in my Athlon XP 2800+, so I have to put that down to sheer CPU speeds. It was quite instructive about what really makes Spring "lag"- CPUs are simply getting overwhelmed.
)
Is it possible thought that units are getting stuck on one machine, and not the other, and that is causing the desync?
