Following a shell

[Ace Productions]

I've been tryng to write a script that will make the camera follow the shell of a tank until it hits a target. I've used the 'fired' EH to detect when the tank is firing, and then in the activated script I've used nearestobject command but I get an error '3 elements expected, 0 returned'. I'm attaching the script for advice.

Thanks in advance.


The Script

_shooter=_this select 0
_weapon =_this select 1
_muzzle =_this select 2
_mode   =_this select 3
_ammo   =_this select 4

_camera = "camera" camCreate [0,0,0]
_camera cameraeffect ["Internal", "Back"]

_shell=NearestObject [_shooter,"_ammo"]

#Fire
?(!Alive Idiot):GoTo "Done"
_camera camSetTarget _shell
_camera camSetRelPos [0,0,0]
_camera camCommit 0
~0.01
GoTo "Fire"

#Done
_camera cameraeffect ["Terminate", "Back"]
camDestroy _camera
TitleCut ["","WHITE IN",3]
ForceEnd

[revellion]

its easy fixed m8'

Changed Working Version

The Script

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

_shooter=_this select 0
_weapon =_this select 1
_muzzle =_this select 2
_mode  =_this select 3
_ammo  =_this select 4

_camera = "camera" camCreate [0,0,0]
_camera cameraeffect ["Internal", "Back"]

_shell=NearestObject [getpos _shooter,_ammo]; here's the error you cant give "NearestObject" an object you must give the Pos in 3D which "getpos" will do

#Fire
?(!Alive Idiot):GoTo "Done"
_camera camSetTarget _shell
_camera camSetRelPos [0,0,0]
_camera camCommit 0
~0.01
GoTo "Fire"

#Done
_camera cameraeffect ["Terminate", "Back"]
camDestroy _camera
TitleCut ["","WHITE IN",3]
ForceEnd

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

happy scripting

[Ace Productions]

From official command reference:

Description:

Nearest building of given type to given position or object. pos may be [x,y,z, "type"] or [object, "type"].

Example:
nearestObject [player, "StreetLamp"]

I've tried it mate but it's not working.

Thanks anyway

[sa8gecko]

Solution:
_shell = NearestObject [_shooter,_ammo]

Be advised: if your computer is not fast enough, or is lagging, and the
shell is travelling at 1000+ initspeed, especially in very objects crowded
islands, Nearest object could report nothing because when it's executed
the shell is way beyond nearestobject range, that is about 50 meters.

THEN: nearestobject written in the above way works, but as long as you
use as _ammo the actual ammo type returned by the fired eventhandler
(_this select 4). If you try to use the ammo base class (i.e.: AT3 for an RPG)
it won't work this way.

The error in the first script is:
_shell=NearestObject [_shooter,"_ammo"]

_ammo is already a string. The bad with the fired eventhandler is that it
doesn't return the ACTUAL shell fired, but only it's type,muzzle and mode.

You will see an interesting use of nearestobject used this way in the
following days. Stay tuned on OFPEC.

[Unnamed]

You could try this for getting the shell:

Code: [Select]

_sh=_this Select 0
_at=_this Select 4
_ts=ObjNull
@(Call {_ts=NearestObject [_sh,_aT];!IsNull _ts})
This is the best way I can think of for making sure you catch the shell when its fired?

[sa8gecko]

Unnamed:
I fear that when the fired eventhandler is called the bullet is already
in the air. That should mean that if the execution of the script detecting the
shell is retarded (because for example OFP engine is trying to keep up with
framerates, or it's executing another script), the shell will be already away.
You can test this trying the script first in desert island, then on Everon,
setting view distance as high as you can (and maybe even moving with the
tank, so that FPS is even lower)

But if you (Unnamed) don't make the script be called by fired eventhandler,
but you make it execute from the initialization line of the vehicle, maybe it
could work always. The problem would be that if another unit fires the same
shell type near the tank, then nearestobject would catch this.

Tell me what you think, I'm interested.

[Unnamed]

I fear that when the fired eventhandler is called the bullet is already
in the air. That should mean that if the execution of the script detecting the
shell is retarded (because for example OFP engine is trying to keep up with
framerates, or it's executing another script), the shell will be already away.

Yeah this is the problem, there is no way of forcing multiple events to checked before every frame.

The @ command does that to a certain degree, in that functions embedded within its condition operate together rather than if they where called as a regular function i.e:

Code: [Select]

@({Call Func1 ; Call Func2 ; True})
This will execute Func1 & Func2 before certain process are checked, note: this returns true so its only checked once.

But the following can pick up other events before its finished.

Code: [Select]

Call {Call Func1 ; Call Func2}

I think starting the loop from init would probably yield the same result?

But if you really want to track a shell without creating CoC UA style addons, it was the neatest way I could think of.

[Dinger]

you can get good results if you use the function called immediately by the EH:

mydude addeventhandler [{Fired}, {[nearestobject (_this select 0), (_this select 4)] exec "TrackShell.sqs"}]

Will launch TrackShell.sqs with _this select 0 as the object, and do it pretty reliably
you can put a trap on the other side:
_myshell = _this select 0;
?IsNull _myshell:player sidechat "ERROR -- EH MISSED"; exit

[Grendel]

Just had an idea...


To (maybe) fix the whole 50m detection thing, what if you used a little bit of trig to "push" the nearestObject search out a little:

Code: [Select]

_dir=getdir player
_pos=getpos _shooter
_px=_pos select 0
_py=_pos select 1

_px2=_px+(50*(sin(_dir))
_py2=_py+(50*(cos(_dir))

_shell=NearestObject [_px2,+py2,2,_ammo]
This would move the nearestObject search 50m in front of the shooter, so it would theoreticly give your cpu more time to process the command.  I don't think the getpos/getdir and minor math is enough to make it irrelevant, but you never know till you try.

-Grendel

[Chris Death]

Isn't a tank's heading and a tank's turret heading different?

I remember ppl having had troubles, checking out the turret's
heading, as getdir only returns their unit's face heading.

Not really sure about this, as i haven't been messing around
meself with that.

~S~ CD

[Grendel]

Isn't a tank's heading and a tank's turret heading different?

Yeah, now that you mention it, you would have to already catch the shell to calculate the turret angle.

I guess the trig thing would only work for a non-turreted unit, unless you make few overlapping searces that surround the whole vehicle...which would probably increase cpu usage anyway.

-Grendel

[sa8gecko]

If the commander is turned out I think you can know turret direction
checking the commander dir: there's another recent thread that deals
with it, and Unnamed solved the situation (you have to modify p3d
model, though)

I guess the trig thing would only work for a non-turreted unit, unless you make few overlapping searces that surround the whole vehicle...which would probably increase cpu usage anyway.

already tried ... a nightmare, in heavy scenario you can end up with
nothing even after searching in six different position 60 meters away
from the tank. We at PsyProd dropped this method for our missile car,
substituting it with Unnamed's, that is 100% reliable even in lagging
games.

[Dinger]

If you're trapping a shell with an EH and nearestobject, use a FUNCTION, not a SCRIPT to trap the shell. REmember that every line of a script is alotted a simulation slice ; every function is alotted the same slice. So if you need to get the shell at the earliest possible moment after it's been fired, use an EH.  Looking 75m downrange may be a good idea, but only if you don't find the shell closer.
Also, any solution you code will need to take into account the situation where the shell just isn't there.  For example, if you park a gun against a wall and shoot, so that in the same simulation step the shell's created, it is destroyed, you're not going to trap a shell.  So make sure to handle that case.

Or you can just zero out the thrust of the shell, so it plops in front, and apply the thrust using setvelocity referenced to your own targeting routines and applied to dynamically assigned variable names unique to the firing unit. That works pretty well.

[sa8gecko]

Even with a function sometimes it's impossible (I, mean, the shell
is already far away)
I agree that the lower the shell's initspeed, the greater the probability
to find it, but setting initspeed to almost zero will prevent the AI to
engage.