Ideas and questions for the ECP, CoC, and the FDF - MOD teams

[m21man]

Is it possible to make the bullets randomly bounce of surfaces, change direction and speed, or is it too complex cpu -power eater thing to do?

A. It's possible, and I don't think the math would be too complex to handle

B. But you'd need to track every bullet, which would get mighty CPU-intensive once someone mashes down the trigger on a SAW . IMHO, a better way to create area-suppressive fire is to tweak the config of a weapon so that the bullets distribute more.

When people can do amazing realistic effects aroud other realism facts, why this is so difficult to produce?

This is also stopped by the sheer number of bullets that you'd need to track once automatic weapons are introduced.

[MachoMan]

Is it possible to make the bullets randomly bounce of surfaces, change direction and speed, or is it too complex cpu -power eater thing to do?

A. It's possible, and I don't think the math would be too complex to handle

The math is not that hard no, but there is  just no way to deterimine the angle of the surface you hit. So consider this kinda impossible.

When people can do amazing realistic effects aroud other realism facts, why this is so difficult to produce?

B. But you'd need to track every bullet, which would get mighty CPU-intensive once someone mashes down the trigger on a SAW . IMHO, a better way to create area-suppressive fire is to tweak the config of a weapon so that the bullets distribute more.This is also stopped by the sheer number of bullets that you'd need to track once automatic weapons are introduced.

Well not really, the engine tracks every bullet anyway, your cpu is quite powerfull you know, it can easily handle a couple of SAW's, the can only fire 1000 bullets a sec, your cpu can easily calculate millions.

[Dinger]

Yes, the CPU is quite powerful, but M21man is talking about _scripting_. The CPU can track millions of bullets, using compiled C++ code (or whatever it is they're using). We'd have to track millions of bullets using runtime parsed OFP scripting code which does not have direct access to the physics engine.  In other words, we can't have the bullet's trajectory dumped to our scripts, we have to calculate it from polled spots along the way.  Very quickly the load becomes rather burdensome.  The moral of the story? Scripting isn't free. And fans of Big Scripting (like me) have to be careful or their missions end up choking the CPU.  If you doubt that's possible, take a look at MFCTI -- a revolutionary concept, sure; but also an object lesson in the limitations of Big Scripting with no concern for CPU.

Likewise, reading surfaces.  You could track say 5 bullets with no gravity as they hit the wall in slow motion, calculate the angle of the surface, and that way get the angle for the bullet to bounce off of.  But you couldn't do that for 1000 bullets.

[penguinman]

hmm

i hope u werent under the impression that i was being ovely agressive. after i looked my post over im begining to feel i was. im sorry, just got caught up in the heat of a debate and got a little excited trying to prove my point.

well anyways good luck w/ ur system

when is the next version of COC arty comming out?

[RedHouse]

how are you going to set the angle that the bullet bounces off at because theres no command to set the angle of the z coordinate, you can only set the direction (setdir) and thats only x and y coordinates. I would use penguinman's idea, keep it simplier useing the setdammge command but maybe add something that looks like shrapnel by creating particles.

[makkaramies]

Hello!
Allmost every topic I sent here, has been discussed but still nobody sayed anything about bullet/grande hit animations on water/snow,etc

Thanks for everyone for your intrest and replys. ;D
It is great to see that so many people are actually trying to do something to the realism stuff.
And the best thing is that people are doing stuff with with somebody who has experience from the real thing.

RESPECT and REGARDS ;D