Find that bullet hole

[zayfod 1]

So close but no cigar yet.

Yep--mission impossible ECP team requests your help.

OK so we have Laws, tank shells, AA no problemo--we have their exact impact co ordinates calculated via very friendly FPS code (results of this yet to be seen in latest ECP).....

but bullets?

Well this is proving tough.

Up to the challenge?

All ideas no matter HOW crazy welcome.

Zay

[ZiRo 0]

get the x + y + z directions of the weapon, hieght from ground and calculate the impact

[MrZig 0]

why not use nearestobj then wait till its not alive, and there's your bullethole..

[InqWiper 0]

Quote[/b] ]why not use nearestobj then wait till its not alive, and there's your bullethole..

The bullet is too fast or the script is too slow, it wont be very accurate.

The bullet travels at about 950 meters pers second so if the scripts updates 1000 times per second it could still be almost a meter off.

[Migebuff 0]

player addeventhandler ["fired",{[_this select 4] exec "bullet.sqs"}]

bullet.sqs:

_b = _this select 0

_bullet = nearestobject [player, _b]

#loop

? alive _bullet: _pos = getpos _bullet; goto "loop"

[RED 0]

That won't do anything Midgebuff, we want to know the exact position of the bullet hole. I guess the best way is to track it the conventional way then try and detect the bullet hole model that is spawned there (if that is even possible?)

RED

[Migebuff 0]

Try this one:

_b = _this select 0

_bullet = nearestobject [player, _b]

#loop

? alive _bullet: _pos = getpos _bullet; goto "loop"

_bullethole = nearestobject [_pos, "crater"]

[uiox 0]

mission impossible

In the fired EH trap the bullet directly in it before pass arguements to the script, it's a little bit more quick, like this:

init="this addEventHandler [""fired"",{_Missile = nearestObject [vehicle(player), _this select 4];_BigGun = ""heat125"" createvehicle getpos _missile;_BigGun setvelocity (velocity _missile)}] ";

Test if the pos is [0,0,0], when the unit shots near it on the ground detection is not speed enough.

You can test if your bullet is non existing object like this:

a script call after detection in the EH

_Missile = _this select 0

? isNull _Missile : exit

_Type= typeOf _Missile

#loop

If (_Type == typeOf _Missile) then {_LastPos = (getpos _missile) }

If (_Type == typeOf _Missile) then {goto "loop"}

#end

[dinger 1]

you can use a method like uiox's to get the last known coordinate. Then you can do a NO scan for the bullethole (it may be crater, it may be something else -- you can determine bullethole's object name by using typeof and a NO scan on a testbed (or just use my laserdesignator stuff)), and getpos will get you the coordinates.

Problems: more than one bullet fired at an area will produce undesirable results. Last known position may be more than 50m away. Engine does not create bulletholes if player is too far away.

Method two:

A) use a scan loop like uiox's to track both the bullet position and velocity. Also record the direction the bullet was travelling.

B) when the bullet goes to 0,0,0 position, grab the last known good position and vector.

c) camcreate (not CV, so you don't have MP load) a custom object of the shotSmoke simulation, using an invisible model, and with all smoke turned off. Place that in the last known location of the bullet, give it the same direction, and setvelocity the vector. The shell should land in approximately the spot of the bullethole (you will get some error, because the AoA is slightly off, but if you use last known pos, that should be negligable).

d) .1 seconds later, read the position of the smokeshell. That will be impact point.

[Migebuff 0]

This one works also for multiple bullets:

player addeventhandler ["fired",{[_this select 4] exec "bullet.sqs"}]

_b = _this select 0

_bullet = nearestobject [player, _b]

#loop

? alive _bullet: _pos = getpos _bullet; goto "loop"

_bullethole = nearestobject [_pos, "Crater"]

hint format ["%1", _pos]

_bullethole setpos [0,0,0]

Exit

Im using setpos [0,0,0] because deletevehicle doesnt work with bulletholes... It will remove the hole, but thats the only way to get the exact position. You can still create a fake bullethole, but that shouldnt be a big problem for you...

[T J 0]

Sounds crazy this, and I havent had a chance to test it fully, hmm, in fact, it sound too crazy, i'll test it first.

(but i thought directly of ECP when the original inspiring eror msg came up)

TJ

[zayfod 1]

Ok this is good,

people have their thinking caps on.

All sugestions so far appear to be variations of the orthodox conventional methods--all good but very resource hungry and not too CPU friendly when we have hundreds of bullets flying about.  

Capturing the bullet , its direction, its velocity , etc in the function before its passed to the sqs and then doing a NO scan is all handy and doable (and probably quite reliable if the mathmatics is correct), but Im am hoping for a more direct route--something lateral.

The tracking of the position loop needs to be reduced in its frequency or cut from the equation altogether. Yes--I did say "cut from the equation"  but I am being "cough" very optimistic--or outta touch with reality? lol

ok hmmm,

is it possible to make a dummy bullet that is:

a) Invisible

b) doesnt dissappear on contact

c) doesnt instantly setpos itself at ground level after striking something.

I need expert thoughts here coz this is my personal crazy idea.

Simply grab the bullet,its pos, its vel in a sqf. Set the dummy bullet off at the same vel as the real bullet from the same pos as the real bullet, then when the real bullet is null we can find the dummy bullet position at our leisure with no high freq loops.Erm say only check isnull every 0.2 seconds--which would be fast enuff for any eye candy that we wanna spawn at the bullet hole.

TJ--what are u cooking up mate?

Hehe--wouldnt it be nice if we could add EHs via the config to ammo/bullet objects

[zayfod 1]

Quote[/b] ]Method two:

A) use a scan loop like uiox's to track both the bullet position and velocity.  Also record the direction the bullet was travelling.

B) when the bullet goes to 0,0,0 position, grab the last known good position and vector.

c) camcreate (not CV, so you don't have MP load) a custom object of the shotSmoke simulation, using an invisible model, and with all smoke turned off.  Place that in the last known location of the bullet, give it the same direction, and setvelocity the vector.  The shell should land in approximately the spot of the bullethole (you will get some error, because the AoA is slightly off, but if you use last known pos, that should be negligable).

d) .1 seconds later, read the position of the smokeshell. That will be impact point.

Sounds interesting

Dinger--what if we simply set the invisible model off at same velocity as soon as the bullet is captured? Will the flight path not be the same? I would really like to bypass the position tracking loop.

[Migebuff 0]

Why dont you just use my script? You dont have to create any invisible smokeshells, all you have to do is to copy & paste the script I posted above. It does everything you want. It finds the EXACT position of the bullet hole. And NO, it doesnt lag.

[Tactician 0]

I think MigEBuff's will work; you can deleteVehicle the existing crater and replace it with a new one that you've set up in cfgNonAIVehicles.  However, be aware that craters are not formed outside of the client's view distance.

About avoiding the tracking script: I believe smokeshell-type objects have different air friction values. If you can get around that, you can probably get a smokeshell object to follow a bullet's trajectory. However, how will you know when the smokeshell has impacted something? With a tracking script :P

[dinger 1]

you can try setting the invisible non-smoker right behind the bullet, and tracking it.

the limitation is that you can't set AoA, and the physics of OFP has a weird implementation of AoA effects.  So the farther out you create it, the bigger the offset between where the nonsmoker ends up and the bullethole

oh and that "non-lagging" scan loop will impinge upon ofp functionality. At the very least, in the loop, there should be a delay such as ~.00001

THe bullet simulation is updated every .05 seconds IIRC; adding this delay will allow the scan script to "play nice" with the other scripts running.

Still, if you've got a lot of bullets in the air, that's a lot of scripting overhead.

[zayfod 1]

When I say I would like to avoid a tracking script, I meant I would like to avoid a tracking script with a pause of ~0.0001.

A pause of 0.2 is what I would aim for, anything smaller will simply suck too many resources.

I did the smoke shell experiment and yes its flight path is quite dif when its given the same vel as the bullet (only the z factor changes tho)--smokers also appear to have a terminal vel also--hehe noticed that when I fired upwards.

So---hmm. What we need is the "disappearoncontact" option for a dummy bullet like there is for class "thing" in the main cpp.

[Migebuff 0]

Bulletholes are also created outside the view distance, as you can see in this video (viewdistance 500 m). And as you can see, the script is very accurate.....

[dinger 1]

A few things with the smokeshell -- first yes, there's a terminal velocity. This is controlled by maxspeed. so if you set maxSpeed=5000; or so, it should work fine.

second you must setdir the shell to match that of the bullet

third, you will get some difference in Z determined by AoA

mission impossible

[zayfod 1]

OK--real close now,

Dinger--anyway we can ascertain what the z facter diff is between a bullet and a smoker? Is it a constant?

lol is it a variable based on a fictitious mass and gravity thats hardcoded into the smoke shell class object?

Changing max speed helped a lil I think and I was always setting its direction correctly too-- but depending on angle of shot it varies from being 0 m out to 3 m out. For example, if you fire at your feet the smoker lands in the correct line but 3 metres further on, if u fire at ground say 20 metres in front of you its quite accurate, then if u fire at ground further than that it starts going out again.

Perhaps the "z" terminal vel of a smoker cant be altered?

[zayfod 1]

Thingeffect might be the ticket,

seems to follow the bullets flight path exactly every time--but it bounces away. Can anyone try and make a thingeffect invisible model that has crazy high mass and stays put when it hits the ground?

[toadlife 3]

Aren't the bullet holes objects? If so, can you replace the default bullet hole with an addon that runs a script upon spawning?

[zayfod 1]

Hey thanks for the offer Toady,

Ill wait here while you type up the addon

[toadlife 3]

Well I see this in the config.cpp

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

class Crater

{

model="";

simulation="Crater";

};

But I don't think you can attach an init script to something under cfgnonaivehicles -at least I don't know it would be done.

[hawkins308 0]

Im just bringing these thread out from the bowels of the forum, because I want bulletholes, I WANT THEM!

Plese good lord, send me a saint to do magical stuff with scripting and put in bulletholes.

Ive got this. Using SLX mod, he had a way to turn on simulation=crateronvehicle

simulation=crater

and bulletholes show up using his model. I darkend it, and edited it a bit. However, they fade away in 30 seconds and I CANT MAKE THEM NOT. Someone helpe me!