If you are using a model for the missile, could it be because its radius is bigger than the aoe?Should, yes. Does, no. I've had problems in CvC with drone missiles hitting other drones and not doing damage. This was the most prominent with friendly fire, i.e. friendly drones running in front of the missile drones and "catching" the missiles.
Developer Preview: NanoBlobs 0.50b (link added)
Moderator: Moderators
Nope, that's not it. Besides, the problem only appears with drones and only since I've reduced the drone radius (from ~20 to 10). At first I thought the missiles might hit the model of the drone but the explosion checked for the bounding sphere but now that I think about it it might be because the drones are so damn fast that they have already escaped the blast radius by the time the shockwave would reach them. I've seen quite a bit of weird delays with that shockwave behaviour (e.g. multiple drones running into a small explosion and getting destroyed, grenades taking almost a second to damage the drones in their blast radius, etc).
B: Hell freaking no. Nudging units is worth any cost in performance. Without it, pathfinding would be a hundred times worse than it already is.
C: disagree, it's a great visual effect and would make shockwave effects pointless. What kind of explosion affects everything around it before the shockwave hits? I'm talking about the visual ones.
To fix the sound effect range bug you mention, check this thread I just started. For original, spring-only mods, there would be a very small amount of work involved, but for others (ie, everything but nanoblobs at this point, right?) the problem would be solved instantly. It's here: http://taspring.clan-sy.com/phpbb/viewt ... p?p=107034
C: disagree, it's a great visual effect and would make shockwave effects pointless. What kind of explosion affects everything around it before the shockwave hits? I'm talking about the visual ones.
To fix the sound effect range bug you mention, check this thread I just started. For original, spring-only mods, there would be a very small amount of work involved, but for others (ie, everything but nanoblobs at this point, right?) the problem would be solved instantly. It's here: http://taspring.clan-sy.com/phpbb/viewt ... p?p=107034
As it is, this appears to be a fairly minimal cause of slowdown/lag.B: Hell freaking no. Nudging units is worth any cost in performance. Without it, pathfinding would be a hundred times worse than it already is.
If it was optional, I'd be fine with it. All we need is something like this:C: disagree, it's a great visual effect and would make shockwave effects pointless. What kind of explosion affects everything around it before the shockwave hits? I'm talking about the visual ones.
IF WeapontdfTag "InstantExplosion" == 1
THEN
Check simple sphere, get all collisions with all unit spheres
Apply damage
ELSE
Do current behavior
I'll go look at the source and try to write a patch myself... this cannot be that hard to code...
Ah, now this is very interesting. Among other things I found when searching for the explosion-ring-check thingie (which I still haven't found)... I found that if 4 values are all set to 0, then I can finally fix UnitDeath explosions, which have been causing craters.
Setting all of these things to 0 ... has lead to considerable performance increases even on maps with near-infinite Hardness values, as I've been strongly suspecting all along. Even with full-fledged combat going on, with 450+ units, my machine managed a very playable 35+ FPS, and very rarely dipped lower!
I suspect that the expanding-explosions and the generator for guided weapons are the last two major areas of lag in combat. After that, I think Spring's about as optimized for NanoBlobs as it's gonna get, short of me tearing out all of the complex COB animations for some of the more complex units (the Archer and SpireRook, in particular, have rather un-optimized animation sequences).
Code: Select all
impulsefactor=0;
impulseBoost=0;
craterMult=0;
craterBoost=0;
I suspect that the expanding-explosions and the generator for guided weapons are the last two major areas of lag in combat. After that, I think Spring's about as optimized for NanoBlobs as it's gonna get, short of me tearing out all of the complex COB animations for some of the more complex units (the Archer and SpireRook, in particular, have rather un-optimized animation sequences).
- Johns_Volition
- Posts: 134
- Joined: 05 Jul 2006, 21:17
Actually, once I can use the UnitIcon feature, then I will probably adjust the multiplier so that when zoomed out, the player is basically looking at a coded set of icons, and will only see detailed combat when zoomed in quite a bit. Y'know, like a real military commander would want to see. After all, NanoBlobs is not about individuals, once you're past early game- it's about streams of force.
- Johns_Volition
- Posts: 134
- Joined: 05 Jul 2006, 21:17
No, I'd have to (politely) disagree with that assessment. I'd say that Supreme Commander is a closer match with the vision behind NanoBlobs, given the thrust of the game design as understood by me.
What I will be looking at, when it is finally released, is whether Chris Robert's team will be able to preserve their core concept- one where individual fighters are less important than the abstract concepts of force projection that form the basis of modern mass warfare- without losing the interest of their core playerbase, which has grown up on games like OTA and Starcraft, and will be expecting a more individual experience.
NanoBlobs was mainly conceived as a way to study AI and the limitations of the Spring engine in a fairly simple and straightforward way. In most ways, this has proven an exceptionally useful testbed, which is why I keep tinkering with it, even though there's practically zero player interest. I put together this version from my work over the last few months in the hopes that the developers would sit down with it and see some of the things that we modders have been seeing- things that are deeper than a single subroutine, but hard to summarize or pin down to a single factor.
What I will be looking at, when it is finally released, is whether Chris Robert's team will be able to preserve their core concept- one where individual fighters are less important than the abstract concepts of force projection that form the basis of modern mass warfare- without losing the interest of their core playerbase, which has grown up on games like OTA and Starcraft, and will be expecting a more individual experience.
NanoBlobs was mainly conceived as a way to study AI and the limitations of the Spring engine in a fairly simple and straightforward way. In most ways, this has proven an exceptionally useful testbed, which is why I keep tinkering with it, even though there's practically zero player interest. I put together this version from my work over the last few months in the hopes that the developers would sit down with it and see some of the things that we modders have been seeing- things that are deeper than a single subroutine, but hard to summarize or pin down to a single factor.