Eventhandler in a "addon" or the "mission" itself

[-IT-Q- 0]

whats the best place to save the eventhandlers:

-especially regarding multiplayer-

i mean eventhandlers like the dust or fire script - pros and cons, problems in general // for each event (like "fired") if necessary?!

write them into each units init line or better include them in an addon (if possible)?

[-IT-Q- 0]

oh come on guys

i've read a lot of threats in this forum but i am not very into this stuff - plz help me in this matter - if u dont have the "time" .... just write me /abc/ is better

[Pennywise 0]

It doesnt really matter rather you place it in the objects config or use the 'addeventhandler' command. If its ease of use you are after, I would just use addeventhandler. Otherwise, if your making an addon, you can just place your script directly in the config.cpp.

If you want specifics, your gonna have to provide us with a little more detail. Please explain what you attempt to do and how you intend on doing it. Im sure it will be easier guide you in the right direction from there.

[-IT-Q- 0]

Quote[/b] ]law/aa/at-soldier:

init="this addEventHandler [""Fired"",{_this exec ""effects\RocketShockDust.sqs""}]";

---

rocketshockdust.sqs

?player distance (_this select 0)>MaximaleObjektSichtbarkeit:exit

_waffe = _this select 1

?_waffe != "LAWLauncher" and _waffe != "RPGLauncher" and _waffe != "CarlGustavLauncher" and _waffe != "AT4Launcher" and _waffe != "AALauncher" and _waffe != "9K32Launcher" : exit

_c = 25

_circles = 5

_max_radius = 2.5

;color correction

_color1 = CFG_Rocket_Shock_Dust_color1

_color2 = CFG_Rocket_Shock_Dust_color2

_color3 = (CFG_Rocket_Shock_Dust_color3 + [0])

_max_opacity = CFG_Rocket_Shock_Dust_max_opacity

_mid_opacity = CFG_Rocket_Shock_Dust_mid_opacity

;//Size self explanatory

_size = [1, 3]

;//Height off Ground

_height = 0.1

;//Normal lifetime

_lifetime = 3

;//Radius Factor & Radius init

_rad_r = _max_radius / _circles

_rad = 0

;//giving each a different direction...

_step = 360 / _c

;//Wind

_Wind = CFG_Rocket_Shock_Dust_Wind

_Wind_dir = CFG_Rocket_Shock_Dust_Wind_dir

_Wind_var = 1

_Wind_dir_var = 20

_vel = [_Wind*sin(_Wind_dir),_Wind*cos(_Wind_dir),0]

;// calculate the opacity change along the radius

_max_op_rate = (_max_opacity / _circles)

_mid_op_rate = (_mid_opacity / _circles)

;// Position

_base = _this select 0

_pos = getpos _base

_x = _pos select 0

_y = _pos select 1

;//Outer Loop

_j = 0

#loop

_rad = _rad + _rad_r

_color = [(_color1 + [_max_opacity - _max_op_rate*_j]),(_color2 + [_mid_opacity - _mid_op_rate*_j]),_color3]

[_lifetime,_vel,_rad,_height,_size,_color,_x,_y,_Wind_var,_Wind_dir_var] call CFG_Rocket_Shock_Dust_make_circle

_j = _j + 1

?(_j < _circles):goto "loop"

exit

Quote[/b] ]

m1a1/m60/bmp/t72/t80:

init="this addEventHandler [""Fired"",{(_this + [""GUN120NT""]) exec ""effects\TankShockDust.sqs""}]";

---

TankShockDust.sqs

?((_this select 1 != "Gun120") && (_this select 1 != "Gun105") && (_this select 1 != "Gun125") && (_this select 1 != "Gun73") && ((_this select 1) != (_this select 5))):exit

?((player distance (_this select 0))> MaximaleObjektSichtbarkeit):exit

;//_c = Number of Droplets per Circle (do not edit)

_c = 50

;//_Circles = number of Circles

_circles = 10

;//_max_radius = the maximum Radius for the Shockwave (if you make this too large it won't look good)

_max_radius = 25

;color correction

_color1 = CFG_Tank_Shock_Dust_color1

_color2 = CFG_Tank_Shock_Dust_color2

_color3 = (CFG_Tank_Shock_Dust_color3 + [0])

_max_opacity = CFG_Tank_Shock_Dust_max_opacity

_mid_opacity = CFG_Tank_Shock_Dust_mid_opacity

;//Size self explanatory

_size = [3, 5]

;//Height off Ground

_height = 0.1

;//Normal lifetime

_lifetime = 6

;//Radius Factor & Radius init

_rad_r = _max_radius / _circles

_rad = 0

;//giving each a different direction...

_step = 360 / _c

;//Wind

_Wind = CFG_Tank_Shock_Dust_Wind

_Wind_dir = CFG_Tank_Shock_Dust_Wind_dir

_Wind_var = 1

_Wind_dir_var = 20

_vel = [_Wind*sin(_Wind_dir),_Wind*cos(_Wind_dir),0]

;// calculate the opacity change along the radius

_max_op_rate = (_max_opacity / _circles)

_mid_op_rate = (_mid_opacity / _circles)

;// Position

_tank = _this select 0

_pos = getpos _tank

_x = _pos select 0

_y = _pos select 1

;//Outer Loop

_j = 0

#Loop

_rad = _rad + _rad_r

_color = [(_color1 + [_max_opacity - _max_op_rate*_j]),(_color2 + [_mid_opacity - _mid_op_rate*_j]),_color3]

[_lifetime,_vel,_rad,_height,_size,_color,_x,_y,_Wind_var,_Wind_dir_var] call CFG_Tank_Shock_Dust_make_circle

_j = _j + 1

?(_j < _circles):goto "Loop"

exit

Quote[/b] ]

all helicopters in init.sqs

[unit-description,1.5] exec {effects\ChopperDust.sqs}

---

ChopperDust.sqs

; Heli Dust script by Vektorboson

; see _sensor and _calcH for above sea level calculation!

_heli = _this select 0

_lifetime = _this select 1

_null = "scalar bool array string 0xfcffffef"

private ["_sensor"];

_sensor = "EmptyDetector" createVehicle [0,0,0]

_calcH = {private["_result"]; _sensor setpos [getpos _heli select 0, getpos _heli select 1, 0]; _result = getpos _sensor select 2; _result};

?format["%1",HDSIN ] == _null: HDSIN = call {private["_i","_result"]; _result = []; _i = 0; while "_i < 50" do {_result = _result + [sin (7.2*_i)*15]; _i = _i+1;}; _result}

?format["%1",HDCOS ] == _null: HDCOS = call {private["_i","_result"]; _result = []; _i = 0; while "_i < 50" do {_result = _result + [cos (7.2*_i)*15]; _i = _i + 1}; _result}

; these are color prefabs! You may adjust or add some new if you like!

; color for this helictoper

_icolor = HDCOLORGRASS

_shape = "cl_basic"

_color = _icolor

; here comes all the visual part!

#DoWaitEngine

@isEngineOn _heli

#DoWait

@((player distance _heli<MaximaleObjektSichtbarkeit) and (getpos _heli select 2 < 30) and (speed _heli < 120) and (isEngineOn _heli)) or (!isEngineOn _heli)

? !isEngineOn _heli : goto "DoWaitEngine"

#DoDust

_pos = getpos _heli

_x = _pos select 0

_y = _pos select 1

_i = 0

#Do

_vel = [HDSIN select _i, HDCOS select _i, 0]

_size1 = random 2

_size2 = random 3 + 3

_size = [_size1, _size2]

drop [_shape, "", "Billboard", _lifetime, _lifetime, [_x, _y, 0], _vel, 0, 0.2, 0.157, 0.001, _size, _color, [0], 0.1, 0.2, "", "", ""]

_i = _i + 1

?_i < 50: goto "Do"

~0.01

if (abs(_heli call _calcH) < 3) then {_color = HDCOLORWATER; _shape = "cl_water"} else {_color = _icolor; _shape = "cl_basic"}

?(player distance _heli<MaximaleObjektSichtbarkeit) and (getpos _heli select 2 < 30) and (speed _heli < 120) and (isEngineOn _heli) : goto "DoDust"

goto "DoWaitEngine"

(by Vektorboson and Fishion)

ok thx a lot so far m8!

i am just curious as a friend told me that this stuff wont work in the init of an addon with 1.91, only with 1.92 or above it should work

burning or explosion scripts may be added too in the future...

my main concern is optimization regarding mulitplayer and the mission-editing

regards

[Pennywise 0]

'addEventHandler" basically places a callback in the message loop for the addon it's applied to in game.  Once your eventhandler is added, it will be called according to the type of handler you used.  It really doesnt affect multiplayer performance.  Your fine using it the way you are now.  However, You will run into issues when a respawn script is used with a vehicle the eventhandler is applied too.  If the vehicle respawns, the added eventhandler will not exist until it is added again.

In 1.91, the 'init' eventhandler is called on the  server only.  However, 'getin' is called anytime a player gets in the vehicle or if you start out in the vehicle at mission start.

In 1.92, the 'init' eventhandler is called on all clients and the server.  'getin' is called anytime a player gets in the vehicle, but does not get called if you start out in the vehicle at mission start.

(engine, fired, incomingMissile, getout, Dammaged, fuel) These eventhandlers in 1.91 and 1.92, get called on all clients and server regardless of version.

'killed' and 'hit' are called local (1 client only).  I have never used these two handlers before, but the doc tells ya they are client only.

Reference from ofpec

Quote[/b] ]

Event handlers

Description:

Event handlers can be defined in unit config or by function addEventHandler. Multiple handlers can be attached at one time. Event handler types are defined below. Each handler receives arguments in _this, argument types and meaning are defined below.

"Killed" object:killer

"Hit" object:causedBy,scalar:howMuch

"Engine" bool:engineState

"GetIn" string:position (1),object:unit

"GetOut" string:position (1),object:unit

"Fired" string:weapon,string:muzzle,string:mode,string:ammo

"IncomingMissile" string:ammo,object:whoFired

"Dammaged" string:selectionName,scalar:howMuch

"Gear" bool:gearState

"Fuel" bool:fuelState

"Init" No arguments

(1) position can be "driver", "gunner", "commander", "cargo"

MP notes: "Killed" and "Hit" event handlers are executed where given unit is local. All other event handlers are executed on all computers. Events added by addEventHandler may be different on each computer.

The refence does leave out one important piece of info.  Most of the eventhandlers are passed at least 1 parameter, a handler to the object (_obj = _this Select 0).  Those that show more parameters start at _this Select 1, _this Select 2, ... That is unless the doc explicitly says its located else where. I know 'init' gets passed a handle to the object. That was left out.

Looking at the scripts your trying to run in the init, you may do fine just by using the 'Getin' event handler for your 'init.sqs'.  You may even have to use 'init' and 'getin' to get it working on 1.91 and 1.92.  Anyways, I hope this helps some.  Goodluck!

[Pennywise 0]

One other thing, if you use addeventhandler, make sure it is ran on all the clients. Im not certain, but I think it's a local call only. You may have to research that or wait for someone else to verify that for you.

[-IT-Q- 0]

ok thx a lot so far m8!

vehicles do not respawn, but the eventhandler (launchersmoke) of the inf is started again while respawning via a script;

Quote[/b] ]if you use addeventhandler, make sure it is ran on all the clients

it seems to be ok like that (on 1.91 & 1.92b &1.93b), as we did some mulitplayer tests already and everything worked fine

as i said, my my main concern is optimization regarding mulitplayer and the mission-editing, so at least for the mission builder the addon-inbuild solution would mean less work (regarding implementation and deletion (if problems appear)/ but also requires a 1.92b or above serverversion)

[Pennywise 0]

Quote[/b] ]

it seems to be ok like that (on 1.91 & 1.92b &1.93b), as we did some mulitplayer tests already and everything worked fine

Cool!  I wasnt certain of that.  I have only used 'addeventhandler' a few times in the past.

As for multiplayer performce, I have never seen 'addeventhandler' cause performance issues in MP. One thing I did notice is the '@' condition in some of your scripts. That can cause alot of lag in MP. You should probably consider removing those and placing a simple goto loop with a small ~.1 wait.

[BraTTy 0]

And some of the loops have no delay.I would add some sort of a delay for any loop that you have

[-IT-Q- 0]

ok added a 0.1 delay to every loop;

---

update: well after looking again at the scripts, i think it makes no sense to add a delay or it would even "damage" the script (the effect wont work any longer like that) (some delays already present, some of the loops have a low limit and the activation of script is rather low (engine on/off, tank-/launcher-gunfire)

the @-case:

@isEngineOn _heli

----

#DoWaitEngine

? isEngineOn _heli : goto "DoWait"

~0.01

goto "DoWaitEngine"

@((player distance _heli<MaximaleObjektSichtbarkeit) and (getpos _heli select 2 < 30) and (speed _heli < 120) and (isEngineOn _heli)) or (!isEngineOn _heli)

----

#DoWait

? ((player distance _heli<MaximaleObjektSichtbarkeit) and (getpos _heli select 2 < 30) and (speed _heli < 120) and (isEngineOn _heli)) or (!isEngineOn _heli) : goto "Next"

~0.01

goto "DoWait"

#Next

like this?

[killswitch 19]

@ Sep. 17 2003' date='12:59)']it seems to be ok like that (on 1.91 & 1.92b &1.93b), as we did some mulitplayer tests already and everything worked fine

1.93b? What? When? Where?

[-IT-Q- 0]

1.93b is just a enchanced testversion for the connection lost problems

"connection lost" forums topic

and plz stay on topic!

ps: things like that sould be done via pm!

[killswitch 19]

Fair enough. Sorry about the slight detour. Now, back on topic: adding a fired event handler using an init event handler as hinted at in the "LAW/AT/AA RocketShockDust" example will, as noted, only work as intended with 1.92b and later versions.

A suggestion, instead of doing

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

...

init="this addEventHandler [""Fired"",{_this exec ""effects\RocketShockDust.sqs""}]";

...

why not just have

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

...

fired="_this exec ""effects\RocketShockDust.sqs""";

...

in the addon. This will give a unit the desired fired event handler even in 1.91 and previous versions.