Event Handler Speed Problems

[Lone~Wolf]

I need to track the properties of a bullet from the moment it's fired. However, there is a slight delay (milliseconds) between the gun firing and the event handler "Fired" executing the script to track the bullet. Once the script is up and running, it works fine, but the bullet is not registered as existing until it is at least 30m from the shooter.
Not good.

So if anyone could volunteer a solution - I would be impressed. My existing idea would be to run the monitoring of when it is fired inside one script - but I don't know how I would do that.
Help would be appreciated.

Thanks,
        Lone-Wolf 

[RKurtzDmitriyev]

Call a .sqf function from the eventhandler rather than a .sqs script, if that's what your doing. EventHandlers seem to be executed instantly on the frame that the event occurs, and SQF functions also take up only one frame. SQS scripts, on the other hand, take up many frames.

I just tested the following function and it seems to "grab" the bullet instantly, so to speak.

instaBulletTracker.sqf

Code: [Select]

private ["_projectile","_shooter","_thing"];

_shooter = _this select 0;
_projectile = nearestObject [_this select 0, _this select 4];
_thing = "smokeShellGreen" camCreate getPos _projectile;
hint format ["%1", [_shooter distance _projectile, _thing distance _shooter]];
_projectile

It's funny to see a smoke shell materialize instantly at the end of the gun barrel.

P.S.--if you want to see how SQS scripts don't read instantly even when there's no ~ delay, try this:

stupidscript.sqs

Code: [Select]

_number = 0
#loop
_number = _number + 1
hint format ["%1",_number]
goto "loop"

Makes an interesting noise, doesn't it? But the game continues to run. The point is that SQS scripts seem to be "shared," over many frames, with other processes that the game tries to run.

[Lone~Wolf]

Ok, that's good to know - I didn't know that .sqf files were run instantly.
However, your solution does not solve the problem. What happens for me is that the bullet is only registered once it is 30m away, but if it hits something before then, it is magically registered as being at the tip of the gun barrel.
Weird. 

Any thoughts?

[Worldeater]

Hmm, maybe you're doing something wrong? On my box the first few bullets are "caught" after ~1.6m, then the distance drops to ~0.9m [1].

I've attached the test mission (note: the output is written to the RPT).

HTH


Edit: The moment I sent the message was the moment I realized I'm in the OFP part of the forum... so the mission will most probably not work for you... doh! 

[1] It'd be interesting to know why. Does the script get prioritized or does the CPU cache kick in here?

[RKurtzDmitriyev]

LOL Worldeater.

Lone Wolf, what precisely do you mean when you say that the bullet is only "registered" once it is 30m away? How are you measuring that?

In the following demo mission, I can use an sqf function to give me a hint showing the ID (generally NOID), position, distance to shooter, and speed of the bullet, apparently on the same frame as it leaves the barrel, regardless of where the bullet hits.

The distance to shooter is usually about 1.7m and it varies a bit. I explain this on the grounds that the distance is being measured from the bullet (at the end of the gun) to the shooter's feet, and that the bullet doesn't always materialize at the same height for some reason. (Lack of precision built into the simulation, maybe).

[h-]

If you do the nearestobject search in the executed script instead of "in" the eventhandler itself there will always be some delay between the bullet being fired and it being caught, depending on the FPS.

Try something like this (syntax may be f'd, it has been a looong time since I did this in OFP):

Code: [Select]

this addEventHandler ["fired",{(nearestObject [_this select 0,_this select 4]) exec "follow.sqs"}]

Code: (follow sqs) [Select]

#loop
player sideChat format ["%1",_this distance player]
~0.001
?(alive _this): goto "loop"

 

[Lone~Wolf]

Ok, it's definitely a problem with the script running off of those measurements, because the measuring works fine.

Below is the script running off of the measurements, but for a reason I can't pinpoint, it ceases to create any particle when the bullet hits the ground near the player.

Code: [Select]

_bp = _this select 0
_bv = _this select 1

_speed = ( (_bv select 0)^2 * (_bv select 1)^2 * (_bv select 2)^2 )^0.5
_xv = (_bv select 0) /_speed
_yv = (_bv select 1) /_speed
_zv = (_bv select 2) /_speed

_c = 0

#LOOP
_c = _c + 1
? _c > 10: exit

_t = random 1
drop ["cl_water", "", "Billboard", 10, 2, [(_bp select 0) + (_t*_xv), (_bp select 1) + (_t*_yv), (_bp select 2) + (_t*_zv)], [0,0,0], 100, 1.28, 1,  0, [_t,_t,_t], [[0,0,0,0.5 * (1-_t)],[0,0,0,0.25 * (1-_t)],[0,0,0,0]], [0,1,0,1,0,1], 0, 0, "", "", ""]

goto "LOOP"

And here is the script to run it:

Code: [Select]

#loop
player sideChat format ["POS x %1  y %2  z %3   VEL x %4  y %5  z %6",(getpos _this select 0),(getpos _this select 1),(getpos _this select 2),(velocity _this select 0),(velocity _this select 1),(velocity _this select 2)]
_posx = (getpos _this select 0)
_posy = (getpos _this select 1)
_posz = (getpos _this select 2)
_velx = (velocity _this select 0)
_vely = (velocity _this select 1)
_velz = (velocity _this select 2)
~0.001
?(alive _this): goto "loop"
[[_posx,_posy,_posz],[_velx,_vely,_velz]] exec "thescriptmentionedabove.sqs"

Help plz! 

[RKurtzDmitriyev]

It's because the bullet is dying before your second script can record its properties accurately.

Code: [Select]

_posx = (getpos _this select 0)
_posy = (getpos _this select 1)
_posz = (getpos _this select 2)

Before these lines are reached, the bullet has already died and its position is now [0,0,0], and any particle effect will be created there.

Remember, OFP's bullets travel at 900m/s, so even at 90fps a bullet will already have moved 10m in a single frame.

By recording the bullet's position before the script begins (in an .sqf function run directly from the eventhandler), I was at least able to ensure that the particle effect always appeared. (See attached mission). However, it still appears several meters away from its actual impact point. That's because it dies at least a frame's-worth of movement away from its last recorded position. That's why the particle effect appears on the gun barrel if the bullet lands close (its last recorded position was leaving the barrel).

Using mathematical skills which I lack, it should be possible to approximate the impact point of the bullet much more exactly by taking its last known heading and position, and asking the engine to "draw" a ray from there to the ground. I might think of something.