Regarding flexibility; how do bullets fit into all this? Do bullets coming from your team pass through your meat puppets but not your robots?

I really like the results, I'm looking forward to seeing these in game.

... yes i know i've been gone for months (mandatory overtime at work)

Love it, and implement it.

The results are quite satisfying to hear, except for weapon range.

You mentioned that projectiles will be fired at realistic speeds, so does this truthfully mean that the M16 will fire at 975m/s rather than 100m/s, and so on? (Keep in mind, you'll have to get DaTa to remove or raise the global speed limit of 500m/s.) If so, some of the rest of what I say might not apply... as much.

It's disappointing that the realistic range-limiter of AirResistance won't be used, and that the bullets will just magically lose effectiveness instead. You say that air resistance isn't suitable for realistic performance, which is completely absurd, since that and gravity is what limits the range of bullets in reality. It only looks unrealistic in current CC because the current bullets are unrealistically slow in the first place. It's also disappointing that bullets, albeit magically ineffective bullets, will be allowed to fly around the map and back at the user, since that looks awful.

Bullets settling into terrain in all cases is kind of a bad idea; since it'll looks so ugly after someone's been spraying a machine gun. Each pixel is 5x5cm, so it's more realistic for them to disappear rather than settle, (negative RestThreshold) since the bullets would be microscopic, on CC's pixel scale, and they won't need to be enlarged to highlight them, because they won't be important anymore.

You make a good point here about realistic firing speed, but CC's limitations are nasty for this case so I should probably rephrase my sentence to "Bullets will be generally very fast (faster than now, atleast), but we must try to find a compromise between realistic and what works good ingame as it is impossible to make the game follow realistic values to the letter as objects will warp into hyperspace and dissapear if accelerated over the speed limit (500m/s). That is an engine limitation, but a good compromise can be found to achieve a satisfying result."




I suppose I should have clarified that I was talking about the AirResistance variable (I typed it like a variable on purpose), not the function of it. What I mean is that bullets will have a custom air resistance script that slows them down effectively over time to get a much better air resistance effect than what the simple AR variable offers. And definately this script will not change mass, sharpness or any other properties of the object. Only the velocity of the bullet will be altered and nothing else.

The variable slows down an object in all axis and prevents it from going any faster than its air resistance allows. So with the variable, if you'd fire your gun at the sky, bullets would come slowly like flakes of snow or feathers. With the script, they will fall normally to the ground like bullets would in normal gravity.




This is something untested, so you might be right about this. One solution I can think of is that the bullet will check if its about to settle and will cause it to delete itself instead. But no lifetime would be involved though. Althought, since bullets will be of grey color themselves, they might not look bad at all as you might barely notice them in the terrain.

We'll see how it goes.

Bullets currently settle into terrain very often, you can see them and they're less than pretty in all but concrete, but I'm not that fussed as long as bullet penetration of terrain is cut back to a reasonable level.

I think it would be better if the AirResistance variable was updated to have effect per second rather than per frame (ie be deceleration in ms^-2 rather than a multiplier of the velocity each frame), ie do it the right way, so that scripting wasn't necessary for something like that. On systems with modified deltatimes, having variable performance for an engine variable seems of dubious merit. Regardless, it'd be nice to see it used more.
Perhaps we could even get a vectorised version of it? For one resistance when moving head on into something (like a bullet travels) and different resistance when moving side onto something (like a parachuting effect). It'd make oblongs behave more like oblongs. It'd also mean (if done "correctly") that the OrientsToVel variable would be obsolete.

DaTa added this engine limitation on purpose, because gibs used to get to ridiculous velocities during odd mo-mo collisions. These collisions are no longer common, but the limitation is still in place. DaTa should remove it (which likely wouldn't be too hard) to allow more modding and vanilla-content-development capabilities, please tell him. Just a guess, but I think it's the source of the actors-disappearing-at-map-loop-seams glitch.

There used to be documentation on the wiki, before, y'know, it got demolished, that told of an IsTooFast function, or something like that. It was a boolean value of whether the particle was going "stupidly fast". This bit of documentation was originally from DaTa, I believe. Which again supports the idea that DaTa was purposely setting things to delete anything going faster than 500 m/s, to lessen the effect of uber-glichy collisions, which is no longer an issue. And it's such a simple thing, so it's probably easily reversible.


That makes more sense with the AirResistance part, but won't that have a lot more lag than integrating the improved air resistance into the engine?

In my opinion, seeing the bullets, in their regular bullet colors, stuck in the ground looks bad. You can have them disappear instead of settling by using a negative RestThreshold, this doesn't involve LifeTime. It's a low priority thing, but do test it at some point to see for yourself which looks best. Personally, I say negative RestThreshold looks best.

Good to be having back-and-forth developer/community feedback.

what will be done about casings? I know people hate acid casings, but I'm not a fan of climbing a mountain of them either. Are there any plans for making them pile up less, maybe spread out before settling.

While I'm on the subject I shouldn't be able to make a set of floating stairs out of discarded magazines either.

Well that'd my two cents, thank you for your hard work on improving CC.

I think the survey results are fantastic. This is exactly the way I want to see Cortex Command proceed.
I'll be looking forward to more details about the way explosions will be represented. I assume they'll be brief and energetic, yielding to flying debris and possibly a small amount of smoke. That is unless a fuel of some sort is ignited by the explosion, then I would expect to see a fireball with flying fiery debris followed by lingering fire and smoke. I like the way Promster described it. The explosion's visual effect itself should not hide the damage that is being done.

First of all, I have to express that I thoroughly agree with both of you, Azzuki and Geti.

Also, Nummy, with some tweaking and fiddling, it is possible to use the current AirResistance variable to create reallistic bullet behaviour. The catch is using somewhat higher firing speeds (what it seems you're already gonna do, so that's cool) and very low Resistance values, as well as increasing the GlobalAccScalar a bit, just enough to compensate the heightened vertical velocity loss (Or removing it altogether for lighter projectiles, such as flak or shotgun pellets).

The drawback of this method is that either the bullets lose stopping power very fast, or become too poweful at close ranges, making the system more suited for shotgun-like weapons. Yet, I believe that it would be less CPU-intensive than attaching scripts to everything, considering the amount of bullets that are usually on-screen during a typical CC skirmish.

Of course, if you do find a lagless script to replace AirResistance, by all means use it. I'm just dropping my two cents.

On the subject of terrain penetration, I can only say one thing:

I'd try it if I were you.

Also, Salt, the acid casings was a small oversight from the dev team that, combined with the IsScrap malfunction, caused unexpected settling behaviour. If DaTa fixes IsScrap on the next build, the whole problem could be solved by making the casings settle into an extremely weak material.

The terrain altitude hack is lame. I'd prefer harder terrain and blunter bullets.
Also, scripting something with a simple script won't do much to performance, it would be faster to do it engine side but as long as you're not doing a lot of iteration on a lot of particles there won't be much overhead.

D:


Well, I do admit that it would be better to have it all .ini based, but I reckon that it would require a complete overhaul of material/strength values, to keep the effectiveness of bullets. It's just a quick n' dirty solution.

thanks Areku that makes me feel much better.

Salt, there's an official casings fix out on the forums if you search. It's by Capnbubs.

@Areku: We're talking official content here Dirty hacks shouldn't play into it (however many of them are in the current content). Also, TLB has done a materials overhaul (that he steadfastly won't let me play around with <_< (not that it'd do much good for me to get my hands on it now anyway: no CC)) that should fix a lot of the issues with bullets making huge trails through terrain and whatnot. That's the intention, anyway.

When you say organics pass through each other, does that include organics on opposite teams? I wouldn't want that to happen . Body slamming is half the fun in this game.