OFPEC Forum

Editors Depot - Mission Editing and Scripting => OFP - Editing/Scripting General => Topic started by: SoldierEPilot on 02 Apr 2014, 20:42:52

Title: Additional EventHandlers
Post by: SoldierEPilot on 02 Apr 2014, 20:42:52
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 :D
I just experiment with scripts, which can work similar to AddEventHandler/
RemoveAllEventHandlers.
Title: Re: Additional EventHandlers
Post by: Lenyoga on 03 Apr 2014, 17:22:46
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?
Title: Re: Additional EventHandlers
Post by: SoldierEPilot on 06 Apr 2014, 00:03:08
Idea #1
Title: Re: Additional EventHandlers
Post by: SoldierEPilot on 29 Apr 2014, 16:17:17
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?
Title: Re: Additional EventHandlers
Post by: Lenyoga on 04 May 2014, 17:25:03
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.
Title: Re: Additional EventHandlers
Post by: Lone~Wolf on 08 May 2014, 12:57:24
Woah, this is awesome dude. Thank-you for doing this!  :clap:

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?
Title: Re: Additional EventHandlers
Post by: h- on 09 May 2014, 10:06:19
Yes, it's called 'Fired' :P

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]
Title: Re: Additional EventHandlers
Post by: Lenyoga on 09 May 2014, 13:29:38
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.
Title: Re: Additional EventHandlers
Post by: h- on 10 May 2014, 15:38:28
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' :P but not sure that would even be technically possible to do.
Title: Re: Additional EventHandlers
Post by: Lenyoga on 10 May 2014, 20:15:05
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...  :shhh: don't cry... it's not gonna hurt.
Title: Re: Additional EventHandlers
Post by: SoldierEPilot on 11 May 2014, 14:34:34
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.

 

Title: Re: Additional EventHandlers
Post by: Lenyoga on 14 May 2014, 17:14:10
@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)
Title: Re: Additional EventHandlers
Post by: SoldierEPilot on 14 May 2014, 21:34:32

@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
 

Title: Re: Additional EventHandlers
Post by: SoldierEPilot on 22 May 2014, 20:03:28
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?
Title: Re: Additional EventHandlers
Post by: Wiineri on 21 Aug 2014, 22:10:05
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}};
Title: Re: Additional EventHandlers
Post by: Lone~Wolf on 24 Sep 2014, 13:16:48
Wiineri that's absolutely amazing. You're a star! Do you know if this also works with the more recent BIS games up to ArmA 3?

Now that I know I can use this, I can combine this with someone's brilliant suggestion (I'm so sorry I've forgotten who came up with it) of doing ghetto raycasting using smokeshells to check if an object intersected along a line.
With the two of them working together I can create the most incredible goremod that BIS games have ever seen! MUAHAHAHAHAHA!

Entry wound impacts, exit wound splatter, hit-location specific effects like bone fragments or brain in the ejection, blood splatter hitting walls/ceilings and dribbling down/dripping off a-la-Brutal-Doom...

Looks like I've found my programming project for this semester!  :D
Title: Re: Additional EventHandlers
Post by: Wiineri on 30 Sep 2014, 20:41:13
Well, I have pretty much no experience at all of modding any ArmAs, and haven't tested this with any of them, but I don't see why this wouldn't work with them too. Propably the string "NOID krater" is something different, but otherwise I think it should work fine.

Good luck with your project!
Title: Re: Additional EventHandlers
Post by: SoldierEPilot on 18 Apr 2015, 12:34:52
Even in old Battlefield 1942 shot range affects direct damage from projectiles.
The formula is:
Hitpoints = MaterialDamage * DamageMod * AngleFalloff * DistanceMod

DistanceMod = minDamage + (1-minDamage) * (distToMinDamage - distance) / (distToMinDamage - distToStartLoseDamage)

BF community sample: for a shotgun pellet hitting at, say, 50 meters:
distance=50
minDamage=0.5
distToMinDamage=80
distToStartLoseDamage=40

DistanceMod = 0.5 + (1-0.5) * (80 - 50) / (80 - 40) = 0.875
(87.5% of the full-power hit which is occurred at ranges<40)

In OFP shots from, say, Kozlice at 5 and 105 meters are equal in power as I know.
Muzzle velocity value from config.cpp has no deal with direct damage too.

So if people want to implement some damage-modifying scripts -
here is a demo of new hit-detection system, which detects
weapon, muzzle, mode or magazine, ammo and initial position of bad boy who made this hit.

I also removed property system elements to provide maximum simplicity and performance
and optimized the scripts to work even faster in CWA.
P.S.
If someone also need to know projectile hit angles - just say a word...

--EDIT--
Hit system updated in 3 variants.  One of them combines data from 3 event handlers: shooter's "fired" EH,
victim's "hit" and "dammaged" EHs. BF 42 features are not implemented yet.
Title: Re: Additional EventHandlers
Post by: Alex_Mercer_1479 on 04 Jan 2018, 13:56:21
An eventhandler that detect which weapon that the unit is holding would be great (Only v1.96 and under you can use AnimChanged to detect it but its for 1.99 only)
Title: Re: Additional EventHandlers
Post by: SoldierEPilot on 06 Jan 2018, 16:05:01

In CWA 1.99 u can use this mod
http://www.flashpoint.ru/threads/real-cold-war-crisis-mod-v4-5.55472/ (http://www.flashpoint.ru/threads/real-cold-war-crisis-mod-v4-5.55472/)

Code: [Select]
_wpn = _man call localize "fn_weapon_in_hands"
hint _wpn

In OFP 1.96 and below it can be done only 4 player
http://ofp-faguss.com/fwatch/command/mem_getplayeranim (http://ofp-faguss.com/fwatch/command/mem_getplayeranim)
Title: Re: Additional EventHandlers
Post by: Alex_Mercer_1479 on 15 Jan 2018, 10:33:29
So there isn't a vanilla way?
Title: Re: Additional EventHandlers
Post by: Alex_Mercer_1479 on 20 Jan 2018, 09:17:31
Also what about getting the current way point position of unit and also dynamically checking if resistance is friendly to east/west :D
Title: Re: Additional EventHandlers
Post by: SoldierEPilot on 25 Feb 2018, 10:54:24
 >So there isn't a vanilla way?
In 1.96 there is no good native way to check out unit's current animation.
But there is a way to check out if unit's weapons are in safe mode:
Code: [Select]
?behaviour player in ["CARELESS","SAFE"]:  player sideChat "My hands are empty"
Take note, what WW4-based mods uses patrol anims and wherefore rifles will always
be in hands till dropped.

Another limitation is what once u holster the gun, your behavior will be "safe" or "careless"
after a several seconds and this may be critical in stealth missions.
--------------------------------------------------------------------------

>Also what about getting the current way point position of unit and also dynamically checking if resistance is friendly to east/west

Current waypoint position: find all waypoints of unit, find 2 nearest of them and
second waypoint in this pair should be the current.
To find all WPs use getWPpos command and loop.

The side of resistance can be set in init.sqs:
RES_SIDE = EAST
;RES_SIDE = WEST
;RES_SIDE = sideEnemy
;RES_SIDE = sideFriendly

More universal way is to use a global array of all units,
select one unit of resistance side and use commands "reveal"
and "countEnemy" with pairs (res unit - east unit) and/or (res unit - west unit).
It's hard to do and I recommend much simpler way:

just use countEnemy command to determine if this known unit
is enemy or not for current.













Title: Re: Additional EventHandlers
Post by: Alex_Mercer_1479 on 18 Mar 2018, 12:44:30
It felt like you read my mind except getting the current waypoint of a unit part your way is not that reliable

Anyways I'm probably going to release my script soon the AI taking cover script (Dynamically) stay tuned :D
Title: Re: Additional EventHandlers
Post by: SoldierEPilot on 18 Mar 2018, 23:05:21

; to get all WPs one can use DASH_Library 2.5
https://www.ofpec.com/forum/index.php?topic=36435.0 (https://www.ofpec.com/forum/index.php?topic=36435.0)

Code: [Select]
_array_of_pos=_unit call localize "f_waypoints"

; But it's often more easy to lock current WP and do what u want
Code: [Select]
_unit lockWP true
; some scripting actions
_unit lockWP false

; about RESISTANCE allies detection:
1) create 2 invis targets of East and West side
(laser type is the best) in a meter near some resistance unit
2) show 'em to him via reveal command
3) wait a second
4) use _unit countEnemy [_tgt] to see who is resistance enemy.
5) the rest of sides are friendly 2 Troska fraction.
6) remove targets

U can use SideFriendly 4 "All" and SideEnemy 4 "Nobody".

However there are only few situations where u realy need to know
RES fraction allies -  group link (infoshare) and :hmmm: ... do u know one more implementation?

>AI taking cover script
See also
\DASH_Library 2.5\Test Missions\Examples (part 2).Eden\Examples\Misc\useCover.sqs
(one unit hides from another using some big object like APC)
Title: Re: Additional EventHandlers
Post by: Alex_Mercer_1479 on 07 Apr 2018, 11:41:42
https://forums.bohemia.net/forums/topic/215599-improved-ai-script-take-cover-script-v13-and-swimming-script-for-vanilla/

read this :D

Also what is the

\DASH_Library 2.5\Test Missions\Examples (part 2).Eden\Examples\Misc\useCover.sqs

link you gave me?
Title: Re: Additional EventHandlers
Post by: SoldierEPilot on 09 Apr 2018, 22:35:24

It was the path to the script included in this archive
http://www.ofpec.com/forum/index.php?action=dlattach;topic=36435.0;attach=6354 (http://www.ofpec.com/forum/index.php?action=dlattach;topic=36435.0;attach=6354)
An illustration how to use "f_hidden_pos" function.

Your take cover realization is rather interesting.
But the swimming without swim animation is like crawl on ice not to say worse.
Check out an addons below:

Animated vehicle-based swimming:
http://yadi.sk/d/tm8TLgUa3Mwoyx (http://yadi.sk/d/tm8TLgUa3Mwoyx)

Animated script-based swimming:
ninja_LLU.pbo (can also be found in @SLX mod)
Title: Re: Additional EventHandlers
Post by: Alex_Mercer_1479 on 14 Apr 2018, 11:58:24
I wanted the swim script to work without mods just vanilla and in a random mission that you can add on yourself

There is another way for swim script to work without crawling and that is walking (but half of the body is submerged underwater of course)
Title: Re: Additional EventHandlers
Post by: Alex_Mercer_1479 on 14 May 2018, 15:08:11
is there a way to detect vehicle from a unit who is also in that vehicle?

the only way i think of is nearestobjective

NEVERMIND I FOUND IT