using a script to find a bullet

[Roni]

Well, there goes that brilliant idea down the gurgler.      

I'm sure that there must be some way of capturing a bullets final resting place.  :-\    

FWIW - I have ben doing a lot of experiments with EH's and fired bullets.  At one stage I had an EH that created a standard empty pallet at the location of the bullet, then kept it in the air via a quick script - lots of fun trying to get the upwards velocity right between loop cycles to keep it stationary.  And no, it wasn't just 9.8 m/s . . .    

Another test was designed to just capture the bullet itself, but it looks as if there is no actual p3d model for a the generic "BulletSingleE".  I could hear the thing hanging there in space as the standard BulletSingleE has an associated "in flight" sound (sort of a humming sound) and I could walk in to it (doing myself damage !), but I couldn't actually see it, not even with binocs.

In the end I camcreated a Shell73 at the location of the bullet - now I could see it and even move it, but as soon as it touched anything it "died" and exploded.  I'm pretty sure that's how all bullet objects work - as soon as the engine detects a "bump", either with the ground or an object, the bullet object (with or without associated model) is destroyed and the relevant damage dealt to anything within range.

On the subject - it appears as if the engine loop cycle is about 10 times as fast as the script execution cycle.  No matter how fast the loop I still couldn't catch the bullet any closer than 20m.  Using the camcreated objects I did pick up that the objects were "caught" at two defined points appproximately 20m and 30m from the firer.  I'm guessing that that is the standard for BulletSingleE and will be different depending upon bullet speed etc.

I will get back to editing tonight and try out some new ideas.  I'm hoping that maybe a @!(alive _bullet) command will work just as well as a "killed" EH.

Here's hoping !

 :-\



roni

[Planck]

Another test was designed to just capture the bullet itself, but it looks as if there is no actual p3d model for a the generic "BulletSingleE"

Actually, all bullets and shells in the game use the same p3d model..........shell.p3d.


I doubt that helps you much though.  


Planck

[456820]

why dont you have what you want to cam create follow the bullet so when it lands there it is no need of big script or too much editing knowledge.

[Roni]

why dont you have what you want to cam create follow the bullet so when it lands there it is no need of big script or too much editing knowledge.

I tried that and it kind of works, but it isn't perfect.  Since the game execution cycle is about ten times faster than the script exection cycle the bullet position is only updated about every 20m or so for a standard bullet.

I had fun with a little fired EH that camcreated a Shell73 at the same point and with the same velocity as the fired bullet.  It only worked on targets beyond 20m (arming range ?    ) but it was great fun spraying shellfire onto a hapless enemy squad !   :help:   :noo:

Another test tried to camcreate the shell at the final impact point - again, the shells appeared anywhere up to 20m short of the target.  This isn't too bad if you're looking to create an area effect weapon but it is if you're simply tying to create a scripted high damage rifle for example.

The answer is out there !



roni

[h-]

Actually, all bullets and shells in the game use the same p3d model..........shell.p3d.

Yeah, and the shell.p3d model is actually quite big...

I'm pretty sure the simulation "shotbullet" (or what ever it is) makes the model invisible so that you won't see shells the size of the man's head flying out of the weapon he's firing...
(ok, it's not that big, but anyway...)

@Roni:
Have you tried using no delay in the loop at all?
OFP may not like that but it's worth a shot...

[Grendel]

Have you tried using no delay in the loop at all?
OFP may not like that but it's worth a shot...

I tried it, but you still get the bullet's position before impact.

I tried some workaraounds for this awhile ago...but nothing perfect.  to see how far the distance is between position updates, use a drop particle in the loop...

Maybe some genius can work out the actual ballistic path of a given OFP bullet, and use a LOT of math to calculate the angle the bullet is traveling, and using the algorithm to map the trajectory and find the projected point of impact...any takers?

-Grendel

[Roni]

@Grendel
I think that the CoC system works out flight trajectories.  I don't think that it's too hard since AFAIK the OFP engine does not factor in wind resistance or temerature/pressure gradients or whatever.

If a bullet is projected at 300 m/s then it will go 300 m/s, subject to gravity of course.  The only exceptions are missiles which have an initial velocity, an acceleration factor and a burnout time.

@Hater
I tried every step of loop down to ~0.0001 but beyond ~0.01 there was no discernable difference.

Even the @!(alive _x) command doesn't seem to be that fast - if you put in a single command in a "hit" EH (eg - _this setdammage 0) you can take any hit, but put it in a script with even one comment before it and the unit dies before the command can be executed.

Curiouser and curiouser . . .


roni