This is the current build of NanoBlobs: 0.50b. Included in this release are new template files for building Armorclasses in a simple way, custom Explosion Generators using the current (to-be-replaced-soon) code, and (most importantly to Spring developers) all units have been "Epic-sized", and all of the smaller types have had their Death Events removed, so that only the Custom Explosion events occur.
Please do not bother me about game-balance, etc. This is not meant to be a polished release at this time- it's mainly a demonstration of a few points which will hopefully lead to improvement of the game engine's fundamentals. Some of the following whining/complaints are fairly sharp, but please don't take it personally, devs... I've built this version of the mod pretty much for you guys to see some things that are less clear with other game designs. This version's still compatible with NTAI.
FPS DROP / LAG
1. Previous controversial posts have gone back and forth about the speed of rendering S3O objects, and many players have complained about NanoBlobs and lag. My final test results indicate that sheer drawing speeds are not the main cause of lag. Instead, there are several notable causes that playing this release side-by-side with the previous official release will amply demonstrate:
A. EXPLODE events are a very noticable cause of lag. This is, in large part, because the default Spring explosions, smoke FX, etc., are not very well optimized, and also I strongly suspect there's a bug in the physics code somewhere. Taking them out helped to stablelize NanoBlobs framerate. The biggest culprits are FALL events. Those that generate smoke are also quite lag-inducing. As my custom Explosions should show, it is simply unnecessary to have 30+ particles per event and still look pretty good. Hopefully we will soon have the ability to name custom Explosions from COB/BOS soon somehow (maybe by invoking the BITMAP1, BITMAP2, etc. variables).
B. Pathfinding is a major part of lag. As Smoth and others have pointed out, the ability of units to "nudge" one another out of the way causes quite a few needless path re-calculations.
C. Having explosions that do not reach their targets immediately is both laggy and an entirely unnecessary bit of extra chrome. It makes high Rate-Of-Fire weapons less practical, but really does nothing very useful for large-area-effect weapons, except to make them less effective. I would have to vote that this part of Spring's code be permanently removed, now that EdgeEffectiveness is being put in.
D. Beamlasers have very bizarre performance characteristics. I would like to know how many times per second they actually fire, since it's now quite clear that they do not actually fire on a continuous basis, nor does the depicted position of the beam actually match the impact events. Moreover, the multiple impacts are each assigned their own explosion events, which increases lag. My vote on this is that Beamlasers be just a visual effect- let modders determine the true rate of fire, accuracy, etc. As it is, we get the worst of all worlds- we get a visual effect that has certain hard-coded parameters with implications for both lag and gameplay.
E. Guided weapons cause a surprisingly large amount of lag. One of the major causes (and a personal pet peeve) is that you cannot have a guided weapon without Smoketrail=1
Please remove that arbitrary limitation... Guided=1 and Turnrate=!0 should be more than enough. Smoketrails are special effects... they should not be mandatory.F. Lastly, there is something out there that is still causing the game to lag more and more at endgame, even with CPU loads under 60% (the highest CPU load I have ever seen, with NTAI playing against me and 600+ units). My guess is a very large part of this is the fact that unit death explosions STILL CAUSE CRATERS, which even on maps with near-infinite Hardness... still results in microscopic changes to the map's true coordinates. Guys... Explosions with an ImpulseFactor of 0 should not cause any cratering, period, no matter what the source! It's pretty vital to engineering game designs involving hundreds of actors without causing big pathfinding problems and lots and lots of lag. If I want something to cause a crater, I should have that choice- and vice-versa.
However, I suspect there's something else out there that is causing a problem. I can't put my finger on it, though, so maybe I'm just chasing phantoms. But after Epic-sizing everthing to make pathfinding much less laggy, I was pretty underwhelmed with the final results, which were much less impressive than I'd hoped. In theory, according to what I've read in the sourcecode, what I did (I resized every unit by 1/2 or 1/4, and scaled their Footprints to the nearest 1) should have resulted in pathfinding improvements of almost an order of magnitude. Sadly, this is not the case, at all. While making the Footprints of a large percentage of the units 1/1 did reduce the number of outright collisions quite a bit, it didn't result in nearly the improvement I was hoping for.
Other Test Results / Oddities
1. Setting a Tolerance of 0 for a weapon results in a weapon that never finishes aiming. Ever. Even if the weapon can turn so quickly that it should get a "lock" result during the same frame that the firing event is checked. This seems a bit problematic, but is mainly just an oddity.
2. Setting anything but the Base / first Parent object as the Sweetspot for a unit does not work correctly. This seems to make Spring create a new hitsphere for the selected Sweetspot object on-the-fly, which is usually tiny, instead of having the weapon aimed at the Sweetspot but still using the S3O's main hit-detection sphere. Very odd, and it makes "spoofing" units with Sweetspot-moving code, which was a popular trick with OTA units, impossible.
3. Using areaeffects under 16 units often results in hits not really being registered correctly. I strongly suspect this is because of the "delayed-effect explosion" code. As I have stated above, I would strongly prefer that it was removed entirely- it is a significant cause of lag without strong gameplay benefits of any kind.
4. The volume/distance of weapon sounds is ENTIRELY determined by the default damage value. This makes zero sense, but it was easily worked around. For the first time since 0.62, NanoBlobs actually has sounds that work correctly... until the next version breaks it again, no doubt
5. No setting I tried had any effect on the size of the Flamethrower projectile. This is too bad, but based on what I've been reading on SVN, it doesn't matter-we're about to see a quantum leap forward in the graphical quality of projectiles :)
6. Flying units move to the centerpoint of the S3O from which they are built, when they take off after being constructed, instead of obeying their Cruisealt values. This looks like some sort've dirty-and-fast workaround, should be easily fixed.
7. Setting every unit with a MyGravity of 10 entirely removes the infamous "floating but untouchable units" phenomenon that I have seen with NanoBlobs since the beginning.
Umm... I think that's about it for now... more results after I've looked into some other things.
