OFPEC Forum
Editors Depot - Mission Editing and Scripting => OFP - Editing/Scripting General => Topic started by: penguinman on 27 May 2005, 02:51:43
-
hi,
im trying to make a script that finds out when the player fires a bullet, and then follows the bullet and when it hits anything and stops then a drop thing is executed where the bullet hit, how would i go about this, i have the drop comand i need but its the script thats causing problems
-
eventHandler "fired" then grab the bullet with a nearestObject command.
-
If you are using some rifle the bullet is too fast for even the fastest OFP .sqs loop...
-
what about a ~0 second loop and slow the speed down to something about
set acctime 0.10
that might just work
-
It was discussed dozens of times...
example
-
thanks but actualy, ive goten the script to detect the bullet, its the finding where it hit the dirt that im haveing probs with,
how do i find the exact place where a bullet hit?
thanks
-
how do i find the exact place where a bullet hit?
You can't, due to the speed...
If you follow the bullet with a script the scripts 'drags' behind and reports the wrong position in the end...
Here's thread (http://www.ofpec.com/yabbse/index.php?board=6;action=display;threadid=22254;start=0) that this same thing was discussed...
As you can see from there even the fastest loop can't keep up with the bullet...
I suggested the fast loop there myself at first because MCAR uses such thing on the Recoilless Gun jeep but the projectile on that is so slow you can actually keep up with it quite accurately (accurately enough for our use)...
But in the end a mathematical solution was found...
-
1.hmm, interesting, but say my bullet was slow enough to catch in the loop, how would i find its final position.
2. As you can see from there even the fastest loop can't keep up with the bullet...
i think i know how to solve this
after the bullet is fired, camcreate an object behind it in its wake, an object that wont disapeer after it hits somthing, like a bottle. then propel the bottle in the same direction and speed as the bullet using setvelocity, at the same velocity the bullet is going, after the bullet hits and disapeers, the bottle will hit in the same spot(same velocity) and will stop, then you just get the position of the bottle and delete it. and i could use that position, for my drop comand. possible?
-
ehhh i supose so but seems a bit how about cam creating a bullet set velocity it to the same speed of the rifle bullets then name it _bullet1 then target it with a camera so you know where it is
-
Once you have grabbed the bullet with the EH you can name it - you don't need to create other objects. Good idea though.
-
1.hmm, interesting, but say my bullet was slow enough to catch in the loop, how would i find its final position.
With a loop similar to this:
#loop
_pos = position _bullet
@alive _bullet: goto "loop"
?_time >= 2.8: exit
<insert drop[] stuff here>Now, the final time _pos is updated should be pretty close to the last position of the bullet...
Why ?_time >= 2.8: exit ?
Because OFP bullets 'live' only for roughly 3 secs, and without something like this you would get the drop[] 'created' in mid-air once the bullet exceeds it's lifetime...
after the bullet is fired, camcreate an object behind it in its wake, an object that wont disapeer after it hits somthing, like a bottle. then propel the bottle in the same direction and speed as the bullet using setvelocity, at the same velocity the bullet is going, after the bullet hits and disapeers, the bottle will hit in the same spot(same velocity) and will stop, then you just get the position of the bottle and delete it. and i could use that position, for my drop comand. possible?
Yeah, in theory that should work...
But, you would still need that fastest loop to get the bullets velocity and update the bottle's velocity... You can't just shove the bottle to some velocity...
And this means the object could actually 'overfly' a bit the bullets last position because the velocity could have just been updated and the loop starts over again and while the loop is restarting the bullet 'dies'...
But this could be more reliable than the position thingy...
Better use something less visible (and less destructable) than a bottle, like a game logic ("logic")... Dunno if gamelogics can be 'setVelocitied' though...
Worth a try, you never know...
ehhh i supose so but seems a bit how about cam creating a bullet set velocity it to the same speed of the rifle bullets then name it _bullet1 then target it with a camera so you know where it is
What good would this do ???
Then you would have a camera that points to the position where the bullet hit, that's all...
There is no function getPosWhereTheCameraPoints... ;)
Or did I misunderstand something??
-
bo but then you camcreate <object> setpos get pos _camera
wich would leave it right where it landed
-
so hater, how would one make the script that shoots the game logic,
-
Hi PM
I just learned how to use EH's and drop effects in the past few months and have been having lots of fun creating new sounds, particle effects and weapons from standard items.
One thing I did was turn the standard grenade into a Molotov cocktail. All I did was to use a "fired" EH to add a custom smoke and flame trail behind any thrown grenade, then replace the detonation effect with flame drop effects and sounds and a quick trigger placement to "burn" anyone within 5m of the impact point.
For your purposes you could use the same thing, but with a "killed" EH inside the "fired" EH to get the death point of the captured bullet, like so -
Put a "fired" EH on the unit that is shooting.
In the EH script put in just two lines -
_bullet = nearestobject [_this select 0, _this select 4]
_bullet addEventHandler ["killed", "_bullet exec {bulletImpact.sqs}"]
Now create a script called bulletImpact.sqs and put in this line
_impactPoint = getPos (_this select 0)
Voila ! You now have the exact point of bullet death for you to add your custom smoke puffs, sound effects or game effects.
Hpe that this helps.
roni
-
Nope.
You can add eventhandlers only to class CfgVehicles, which means men, vehicles, houses etc...
-
Well, there goes that brilliant idea down the gurgler. :( :P
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
-
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
-
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.
-
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 ? :D ) 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
-
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...
-
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
-
@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