infinite time to live shells ?

[bdfy85]

What config parameter I have to adjust in order to get ammo that won't disappear in the air after flying several (at most several dozens ) sec ?
I know this parameter
timeToLive = 1e10; // infinite time to live
But it doesn't seem to be worky at all:(
Any suggestions ?

[Planck]

Not sure about it at all.

Have you tried something like:

timeToLive=10000000000.0;


This is used for class Thing


Planck

[bdfy85]

No. It doesn't work
I tried any values to this parameter - no influence

PS  1e10 = 10000000000

[Planck]

PS  1e10 = 10000000000

Yes I know, but, I was working on the assumption that the scientific notation might not be working properly in OFP....was just a thought.


I always presumed that the game engine dealt with ammo timetolive and it wasn't changeable anyway.


Planck  

[bdfy85]

Russian team  investigate OFP ballistic ( you willbe amazed - but it uses real physic model to make artillery mod or smth

Due to this issue with shell's lifetime I can fire gun only with small angles ( < 15 degrees or so ) to hit the ground. Of course this affects fire  range  
Look at the picture
ingame projectile's trajectories and it lifetime. I can't even determine  regularity in shell disappearance!

[Planck]

Looking in the games config.....cfgAmmo.....the only thing with a timetolive value is the smokeshell.

This is why I presumed the engine handles all other lifetime values for the rest of the ammo........unless of course there is another parameter that is used.


Planck

[UNN]

Russian team  investigate OFP ballistic ( you willbe amazed - but it uses real physic model  to make artillery mod or smth

Well perhaps not amazed, I used one for my own Mortars:

http://www.ofpec.com/yabbse/index.php?board=43;action=display;threadid=23490

Coc used a Nueral network in OFP. Now, that I did find amazing

But do you mean. How long it lives for (exists as an object) ?

Cant remember the exact values now, but it goes something like:

Bullets 15 seconds ?
Shells 23 seconds
Missiles 30 ?
Bombs 52 seconds ?

AFAIK These values are hardcoded and cant be changed with configs.

[h-]

Bullets 15 seconds ?

Not even close...
2-3 secs...
Why else we would have had amazingly difficult time with some parts of MCAR dev

Other ones seem quite close, although I think it would be more like:
Bullets 2-3 secs
Missiles 12 secs
Shells 20 (or is it really 23?) secs
Bombs 32 secs

Can't remember any others than the bullets for sure though...

[UNN]

Shells 20 (or is it really 23?) secs

Looking back at some of my scripts, 20 seconds sounds right. But I'm sure bombs last longer.

Cheers

[bdfy85]

HateR_Kint
UNN
Look at the picture I posted - ther's no definite time value for shell's time to live Also different shells/missles lives for differenr t amount of time
But anyway we have to use CoC way - setvelocity bombs , in this way they klive forever. But trajectory in this way ( uincluding CoC artillery ) is not ballistic  - it seems  just like in vacuum and has to be somehow corrected.

[Kyle Sarnik]

You can't set time to live to infinate anyways, EVERYTHING must have a limited lifetime.

[bdfy85]

http://www.thechainofcommand.net/cgi-bin/ikonboard/ikonboard.cgi?s=5a32884242d2fcb87539bdb7ea390c87;act=ST;f=20;t=648;st=0;r=1;&#entry6299

1) OFP Projectiles have hardwired TTLs: shotShell = 20 seconds, shotBullet = 3 seconds, shotMissile = 10 seconds. None of these are acceptable to artillery.
2) BIS hacked their own system to get an object with a TTL of 120 seconds (=acceptable for artillery). You need a shotMissile with a thrustTime of 0. That's how they did the LaserGuidedBomb
3) But doing that means that you can't have the engine automatically fling the shot -- you have to do it manually, and write your own system for firing shells.
4) Ballistics is a tricky problem. I've figured out a couple ways to do it. In UA, we trained neural networks to do it: basically we decided it wasn't a problem worth solving, so we had someone write up a neural net, we fed it a bunch of data, and we generated a "black box" system. We give it the range, difference in altitude, and trajectory, and it spits out the elevation.

[UNN]

Look at the picture I posted - ther's no definite time value for shell's time to live

Well it's definite enough for BIS, CoC, MCar and myself (mine is ballistic) to use in game. But without knowing how you came across those values, there is not much I can say. Although this quote from Suma may explain why you get confliciting values?

http://www.flashpoint1985.com/cgi-bin/ikonboard311/ikonboard.cgi?s=db3645b33a926c66f69de59f56aaa25f;act=ST;f=7;t=47930

Timing and profiling is always right, but only when set up properly.

There problems with your setup which make timing wrong:

You cannot use _time for profiling, as this gives you how much time elapsed in the game world, not in the real world, even less how much time was spent in the script itself. The game does not  execute the whole script "in one go". It executes several lines, then continues simulating and rendering, and goes back to the script in the next frame. The time spent you are measuring therefore covers mostly OFP engine simulation and rendering.

But thanks for the heads up on the timimg for bombs, I was sure it was considerably more than regular shells.

[bdfy85]

1) OFP Projectiles have hardwired TTLs: shotShell = 20 seconds, shotBullet = 3 seconds, shotMissile = 10 seconds. None of these are acceptable to artillery.

I'm a bit unsure in this fact...
Enjoy the test mission I attached ( fwatch needed ) . I can see 2 sec for bullets , but no exact value for shells,  rockets... There can be a bit fault in my test mission (I start measuring time only after  to nearestobject command... it takes a bit of time ) But this small fault can't explain results...

[Dinger]

Hi -- okay, I'll confuse things further by putting differents posts here and in the CoC forums.

Here:

This mission (also uses EHs) will give you a TTL measurement that is roughly accurate enough for you to see the actual settings. Just set your unit type, fire a round, and wait for it to timeout. repeat if necessary.