Additional EventHandlers

[SoldierEPilot]

This is the question for all OFP scripters.

Imagine, what you/me/anyone can add to OFP any types of EventHandlers.
What EHs would you like to add?

P.S. I don't want to work with dlls, winapi or send wishlist to BIS
I just experiment with scripts, which can work similar to AddEventHandler/
RemoveAllEventHandlers.

[Lenyoga]

I've been thinking of ways to simulate ammunition that's having a different effect on different targets. (In my case armor piercing rounds for robots, turrets, etc., anti-personnel rounds for anything human)
What I used so far was a "fired" EH for the player unit which adds activates a global variable for the duration of the special bullet's lifetime, and a "hit" EH for potential target units which checks if the player did the damage, and if this variable was activated during the hit. It works alright for me, but only on distances, because the fired EH takes a few frames to register for bullets.

So, now the actual thing - do you have any good ideas for checking if a unit has been hit by a specific ammo type?

[SoldierEPilot]

Idea #1

[SoldierEPilot]

2 questions for all who download example("Incoming bullet"):

1) Does it works correctly in all situations?
2) Any other suggestions for brand new  EH type?

[Lenyoga]

I only had time to try it out now, and it works without any problems so far. I also tried to fire the shot as close as possible and I also caused a bit of frame rate drop to see if it still works - no problem, it works perfectly, just what I need for the different ammo types.

[Lone~Wolf]

Woah, this is awesome dude. Thank-you for doing this! 

Another EH that I've always needed but have never been able to make a workaround for is returning the last known position of a bullet. Basically I need a way to find out the coordinates of a bullet's impact.

All the times I've tried to update a variable every tick with the latest getPos of a bullet it's been way too slow; it gave me values that were way off or, amusingly, were at the tip of my gun barrel.

Any idea how to make an EH for this?

[h-]

Yes, it's called 'Fired'

Code: (fired event for unit, catches the bullet) [Select]

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

Code: (trace.sqs) [Select]

#loop
;this is the object (bullet) passed by the fired EH
_pos = position _this;
~0.001
;debug print of the bullet pos
player globalChat format ["%1",_pos]
;if bullet not alive, exit
? !alive _this: goto "end"
goto "loop"

#end
;display the last position of the bullet as hint
hint format ["%1",_pos]

[Lenyoga]

The problem with a system like in trace.sqs is that it gets unreliable if the framerate drops, often doesn't work correctly on shorter ranges, and so on. I've used it mainly for visual effects so far (based on grenade type ammo, with a velocity script), but for bullets, this can cause issues if the mission is packed with scripts, sounds and units.

[h-]

Well aware of the problems with FPS drop, we had to battle that quite a bit when we were devving MCAR back in the old ancient days.

You can overcome some problems with clever use of functions but that also has the problem of slowing down the game if the usage is too extensive (as in very fast loops calling functions willy-nilly).

With the tracer.sqs you could replace the ~ pause with @, then the position would be 'recorded' every frame but that would make your game crawl.

Be thankful though that in OFP you don't have to worry about the FIFO stacking kind of thing BIS added to the RV scripting engine in Arma2, that is a major pain in the 'hind when doing extensive scripting.

The only way to replace tracer.sqs type of solution is to do it like done with the incoming bullet thingy SoldierE posted but that has the disadvantage of the fact that you would have to be able to add hit events on every single object in the map..

Since OFP I have dreamed that BIS would add a eventhandler type 'custom' but not sure that would even be technically possible to do.

[Lenyoga]

Eventhandler "custom" ... I had that dream once, it was a good dream.
But I guess what I could do for my use of the bullet-tracing needs is to use conventional, slim scripts for the recording of the position and functions for anything else that requires more trickery. Ricochet script, you'll be reworked soon...  don't cry... it's not gonna hurt.

[SoldierEPilot]

Looks like the most accurate way to find impact point
is to use "crater" && "crateronvehicle" NOID objects.

For people who already download BulletImpactPos.Intro:
that example works because there are no map objects on Desert Island.
On Malden (.abel) it cause hundred of crashes

For all people: example below works with ground, water, units and objects,
if they have hitpoints. Map static objects are also objects.
And trees too.

 

[Lenyoga]

@SoldierEPilot I'm right now reworking all of the weapon scripts for my current project (thanks to your example I got into function writing and more effective scripting) and wanted to ask if I can use parts of the Incoming Bullet system for my mod, because it's pretty much the perfect way to implement different effects for different units and ammo types. (You'll be credited, of course)

[SoldierEPilot]

@Lenyoga, feel free to use ANY snippet of my code posted on forums.
And any function from DASH_Library too. Credit at will)

You may find something usefull for your weapon system in Inventory.sqf

P.S.
Example with cratersonvehicles: BIG thanks to Dschulle
for alternative drop command implementation
 

[SoldierEPilot]

Additional hitpoint control

Trying to monitor hits to some part of vehicles, which cause too small
dammage to be catched with regular EHs.
In other words, shot from SVD must cause some dammage event if it hits:
 1) Radar sphere on OH-58;
 2) Fuel tank on T80;

Sample with OH58 works good 8/10 times, sample with T80 - 5/10.
"crateronvehicle" seems to be indestructable && unremovable  
Sometimes nearestobject gets the previous crater if it doesn't disappear yet.
 
Maybe someone can work it out?

[Wiineri]

Using drop command to find the impact position of a bullet, like in SoldierEPilot's example, works fine, but it always needs an external script to be executed to get the position. Here is an easier way to calculate the impact point without crashing the game (this method can be used in a single script or a function, no need for external scipts or functions to be executed.):

Code: [Select]

_crt=nearestobject[_pos,"Crater"]; // _pos is the last known position of the bullet, as with SoldierEPilot's script.
if ((format["%1", _crt])=="NOID krater") then {_pos=getpos _crt}; // checks if the string for the found object is the same as the string for the crater.
No crashes, no FPS loss. Works great, feel free to use.

CraterOnVehicle ("NOID CraterOnVehicle") can be also searched for if there is no crater on the ground. This, however, requires that, in the main config, a model has been set to class "CraterOnVehicle". (Its model is empty by default)

Older craters may still be incorrectly considered as the impact point by the script. Moving used craters to [0,0,0] with setpos works, but there won't be any visible craters on the ground. (Although a fake crater can be added to the position.) This doesn't work with CraterOnVehicles unfortunately.

Here is an example of that (Searches also for the CraterOnVehicle):

Code: [Select]

_crt=nearestobject[_pos,"Crater"];
if ((format["%1", _crt])=="NOID krater") then {_pos=getpos _crt;_crt setpos [0,0,0]} else {_crt=nearestobject[_pos,"CraterOnVehicle"];if ((format["%1", _crt])=="NOID crateronvehicle") then {_posEST=getpos _crt}};