Distance from tank to exploded shell

[zayfod 1]

Is there anyway u can estimate point of impact (position) of a tank fired shell before it impacts? Or even after its impacted for that matter--Ill setlle for either.

Ive Tried this. I get the projectile object from a  fired eventhandler.

Almost works but a lotta the time the shell is too fast and by the time the script has gotten its position its exploded and gone to position [0,0,0] as exploded shells do.

Its sposed to place a gamelogic 200M in front of the firing tank and the gamelogic is sposed to make an incoming sound. If the firing tank is closer than 200 M to where the shell explodes then there should be no sound at all.

It works when one tank engages up to only two tanks.

But if I add more tanks for the "shooting tank" to fire at it only works if I turn and watch the firing tank. If I turn and watch the tanks hes firing at it doesnt work.

It would appear that watching the tanks hes firing at slows the script down and it isnt able to getpos the  _projectile and get its distance.

Also note. Same results occur if I simply try to delete the projectile. If I watch the firing tank its shell will be deleted soon as it comes outta the barrel. If I turn and watch the numerous tanks hes firing at the projectile never gets deleted and hits the tanks.

So under these circumstances it would appear the the fired eventhandler isnt even fast enuff to delete a tank shell.

Note I have made similar scripts for bullets and had no problems so I think its simply that tank shells are incredibly FAST.

Conclusion is that relying on DATA obtained from the actual _projectile is not reliable so I need to obtain ANOTHER way of determining the distance of the shooter to explosion.

DINGER where are ya mate?

--------------------------------------------------------------------------------

#shells

_incoming = shellins call shuffle select 0

_gl = "Logic" camcreate  [(getpos _shooter  select 0) + sin (getdir _shooter ) * 200, (getpos _shooter  select 1) + cos (getdir _shooter ) * 200, getpos _shooter  select 2]

_gl say _incoming

#loopb

_dist = _shooter distance _projectile

~0.01

? isnull _projectile: goto "shelldead"

goto "loopb"

#shelldead

? _dist <= 200: deletevehicle _gl; exit

~0.4

deletevehicle _gl

exit

EDIT: BTW I have tested it with no pause (~0.01) at all as well in the loop and it makes no diference.

This is very urgent

any help appreciated

Zay out

[zayfod 1]

Im thinkin perhaps if we can get the guns elevation and an accurate direction of the gun then extrapolate on that to estimate a rough pt of impact according to the relative ground height in the target area that the barrel is pointed at?

Like I said--it appears we cant rely on data from the actual projectile

[InqWiper 0]

The eventhandler is fast as hell, its just that the scipt isnt run fast enough.

Try shooting another tank with your tank wich has the following eventhandler:

this addeventhandler ["Fired",{deletevehicle nearestobject [this,_this select 4]}]

And bullets dont go to [0,0,0] when they explode, they disappear. If you try using getpos on something that doesnt exist anymore it will return [0,0,0]

I tried making an eventhandler that would update the position until the bullet was no longer alive using:

this addeventhandler ["Fired",{a=nearestobject [this,_this select 4];while "alive a" do {pos=getpos a}}]

But I got an error so I suggest you keep trying with a script that updates the position.

Maybe you should make a script run already before you fire because that could be whats taking the most time with the script, the actual executing.

You can type into your initfield:

a=this;[] exec "Position.sqs"

then you can add an eventhandler to the tank

this addeventhandler ["Fired",{a=nearestobject [this,_this select 4]

make the script look like this:

#Loop

?alive a;pos=getpos a

?!(alive a):hint format ["%1",pos];goto "Loop2"

goto "Loop"

#Loop2

?alive a:pos=getpos a:goto "Loop"

goto "Loop2"

I havent tried this but I hope it works.

[BraTTy 0]

But why you use the nearestobject?

A little extra cpu usage I think because I believe _this select 4 gives the ammo and you can just get the pos of that.

this addeventhandler ["Fired",[_this select 4] exec "bullettrack.sqs"

bullettrack.sqs

_bullet = _this select 0

_bulletpos = getpos _bullet

Get what I am saying,I havent tested this,but I recall seeing scripts getting the position this way

[Harnu 0]

I had this concept for a little while now, Penny helped write a script for just this sort of thing.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">; begin yourscript.sqs

_shooter = _this Select 0

_weapon = _this Select 1

_muzzle = _this Select 2

_mode = _this Select 3

_ammoType = _this Select 4

_tankshell = NearestObject [_shooter,_ammoType]

?(_tankshell==objNull):player globalchat "Shell missed"; goto "end"

?(_tankshell!=objNull):player globalchat "Shell found!"

#again

"Marker1" setmarkerpos [(getpos _tankshell select 0), (getpos _tankshell select 1), (getpos _tankshell select 2)]

~.05

?(alive(_tankshell)):goto "again"

Exit

; End yourscript.sqs

This is our product thus far. Theres one problem with it, it only works half the time. In order for it to work 100%, you need to SetAccTime to around .5.

This gives you any practice you need in SP, but were trying to avoid slowing time so that it will be MP compatible.

[Bart.Jan 0]

But why you use the nearestobject?

A little extra cpu usage I think because I believe _this select 4 gives the ammo and you can just get the pos of that.

It returns type of ammo (string), not the projectile (object) itself.

[zayfod 1]

I had this concept for a little while now, Penny helped write a script for just this sort of thing.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">; begin yourscript.sqs

_shooter      = _this Select 0

_weapon       = _this Select 1

_muzzle       = _this Select 2

_mode         = _this Select 3

_ammoType     = _this Select 4

_tankshell = NearestObject [_shooter,_ammoType]

?(_tankshell==objNull):player globalchat "Shell missed"; goto "end"

?(_tankshell!=objNull):player globalchat "Shell found!"

#again  

"Marker1" setmarkerpos [(getpos _tankshell select 0), (getpos _tankshell select 1), (getpos _tankshell select 2)]

~.05  

 

?(alive(_tankshell)):goto "again"  

Exit

; End yourscript.sqs

This is our product thus far.  Theres one problem with it, it only works half the time.  In order for it to work 100%, you need to SetAccTime to around .5.

This gives you any practice you need in SP, but were trying to avoid slowing time so that it will be MP compatible.

This is basically what Ive got too . With same results (doesnt always act fast enuff to get the shell, Ive tried many different versions.

So there is no way to calculate pt of impact other than trying to track the projectile?

This is really want I need to know

[stoppelhopser 0]

well i just did a similar script for aa-guns to shoot timed shells.

there is no other way than tracking the projectile-object that you get by the nearestObject function. but that shouldn´t be a problem at all.

Quote[/b] ]

But why you use the nearestobject?

A little extra cpu usage I think because I believe _this select 4 gives the ammo and you can just get the pos of that.

i should think 2 more faces in a addon model use much more cpu time.

at least on my machine (gforce 3 blabla biggest model, athlon 1.9xp, 512ddr) i have now 10 choppers attacked by a battery of 22(!) 88 flaks, and they all shoot beautiful timed shells in detonating in the air.

for testing i implemented a hintText showing the detonation height given by <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_shellpos select 2, and with a desired denonation height of 200m i got results of +/- 6m!

so i guess it´s all fast enough!

also if you only use getPos() once, you will obviously get only the shell pos at given time, and and if you do that right when bullet is fired, you get [0,0,0], which also shows that the eventhandler grabs it so fast that it has not even time to travel far

you´ll have to poll the position continuously.

[dinger 1]

Few quickies:

nearestobject only works on stuff within 50m. If your machine is loaded, it won't catch the tankshell in time.

Quote[/b] ]

this addeventhandler ["Fired",{a=nearestobject [this,_this select 4];while "alive a" do {pos=getpos a}}]

While loops are functions and execute immediately. the condition of a while loop has to be something that the operation changes: it cannot be something outside of the operation (like the status of an OFP world object), or it will never occur.

how I'd do it:

this addeventhandler ["Fired", {[_This select 0, nearestobject [_this select 0, _this select 4]] exec "trackscript.sqs"}]

trackscript.sqs

_tube = _this select 0

_shell = _this select 1

_osp = getpos _shell

#TrackShell

~.001

_vel = velocity _shell

_sp = getpos _shell

?_sp select 2 == 0:goto "splash"

_osp = _sp

_ov = _vel

goto "TrackShell"

#Splash

_OriginX = _osp select 0

_OriginY = _osp select 1

_OriginZ = _osp select 2

_vz = _ov select 2

_vy = _ov select 1

_vx = _ov select 0

_offset = _originz/_vz

_OriginY = _OriginY + (_vy * _offset)

_OriginX = _OriginX + (_vx * _offset)

_originZ = 0

_impact = [_originX, _originy, _originz]

That should be a pretty good guess of where the round hit.

Now, knowing this when the shell comes out is a bit tricky.

What you'd need:

A) A way to calculate an OFP trajectory. To my knowledge, nobody has figured out the exact calculation. For UA, we use firing tables and a neural network to solve this problem. But our stuff only works the other way (i.e., you have a target you want to hit, and you calculate the solution.)

You'd read the elevation in degrees and get an idea of hte trajectory

B) A little bit of trig. Follow the trajectory and find where it hits terrain.

C) A way to make this script run faster than the shell flies.

[zayfod 1]

Thanks to all that helped

I did get it sorted a wee while ago but forgot to check back here till I saw Dingers post. And ofcourse Dinger is correct (as %99.9 of the time he is ) . I discovered the trick was indeed to determine the projectile within the parameters of the "fired" eventhandler, by using nearest object.

I originally had it similar to Harnu's script, where the nearestobject query is in the script, but it was too slow on most occasions. But by placing the nearestobject query inside the "fired" eventhandlers parameters (see Dingers example above) it works %100.

Cheers guys.

Zay out