Jump to content
Sign in to follow this  
chammy

Need help with Fired Script and Event Handlers

Recommended Posts

I posted earlier the same subject but it was in the wrong forum, I guess you can delete it placebo, sorry.

Anyways, I was wondering if anyone here can give me some help , sorta explain where the script goes and how to implement it correctly. Thanks. if you can help I will give my IM name.

Share this post


Link to post
Share on other sites

Ok, I 've been reading the Eventhandler read me and there really isnt anything there that I quite understand to tell me on how to use the event handler or fired script. I just need to know what to write down and how to set it up and activate it, I've been really slow at learing how to do that. You see, there are a few things I want to do: Examples:

1) When West Unit Jon Doe fires then trigger activates sound sample "unit say [sound sample]"

2) When car blows up then triggers "East units attack" or East or West Units start in waypoint or action.

3) Unit West or East fires AK, then trigger activates sound sample [ak sound] and or m16 fires and triggers [sound sample m16 or UnitM16 sound] something like that.

I think there is one more,I nneed to look at my mission outline.

Thanks

Share this post


Link to post
Share on other sites

Ok, here's the skinny on the fired event handler.

I'm going to assume you understand basic mission building and scripting topics.

If you don't, you're trying to learn to run before you walk.

FIRST study the information in the comref available here:

http://www.flashpoint1985.com/docs/comref_102002/data/comref.html

Everything under these headers is important.

1: Event handlers

2: object addEventHandler

3: object removeAllEventHandlers handlerType

4: object removeEventHandler handler

I'm going to cover what everything that I mentiond in this document means as it pertains to the fired handler. This should give you a good idea how to use the others.

I'm going to cover addEventHandler First.

Quote[/b] ]

Type of returned value:

Number

Description:

Format of handler is [type,command]. Check scripting topic Event handlers for more information. Index of currently added handler is returned.

Example:

player addEventHandler ["killed",{_this exec "playerKilled.sqs"}]

First, create a test mission on the desert island map. Place a player, let's say, an american officer, named wSoldier1 and save it.

Open the mission folder, create "eventHandlerA.sqs"

Inside of event HandlerA.sqs, we're going to put a test message to show that it works.

player globalchat "fired"

Also create "init.sqs"

Inside of init.sqs, put:

eventHandlerAIndex = wSoldier1 addEventHandler ["fired",{_this exec "eventHandlerA.sqs"}]

Return to the editor and test this. You'll see what it does, then read below for a precise description of everything on the line.

myVar is the index of the event fired event handler on the unit. This will be very usefull later. As event handlers are stored in an array of some sort, by type, and by unit.

This Means that if you do the above, myVar will be the index of the of the fired event handler on wSoldier1. These will start at 0 and increment by 1 for every event handler of the same type added to the same unit.

Proof: Add a trigger to the map, make it big, west present, give it a delay of 2. I just find it to be best to give event handlers a chance to get ready before you do anything with them. In it's on activation feild, put:

player globalChat format ["Event Handler A Index: %1", eventHandlerAIndex]

Run the mission. After a couple of seconds it should display "Event Handler A Index: 0" in the chat area.

wSoldier1 is the unit to add the event handler to.

addEventHandler is simply the command to add it.

"fired" is the type of event handler that it is.

inbetween the {} is either a series of commands or, as in our case, a script to be executed

_this is an array of values that the event handler returns. This will be discussed in depth a bit further on. For now, just know that it is an array and that ALL event handlers return an array of values when fired.

Now, I'm going to cover the information present under "Event Handlers"

Quote[/b] ]

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

In your mission folder, create a new script called "eventHandlerB.sqs"

Put this code in it:

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

_unitFiring = _this select 0

_weapon = _this select 1

_mode = _this select 3

_ammo = _this select 2

_muzzle = _this select 4

player globalChat format["Unit Firing: ""%1""", _unitFiring]

player globalChat format["weapon: ""%1""" , _weapon ]

player globalChat format["muzzle: ""%1""" , _muzzle ]

player globalChat format["mode: ""%1""" , _mode ]

player globalChat format["ammo: ""%1""" , _ammo ]

Put this in init.sqs, below the first line we added.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">eventHandlerBIndex = wSoldier1 addEventHandler ["fired",{_this exec "eventHandlerB.sqs"}]

And change the on activation of our old 2 second delay trigger to this:

player globalChat format ["Event Handler A Index: %1", eventHandlerAIndex]; player globalChat format ["Event Handler B Index: %1", eventHandlerBIndex]

Test the mission, and read below for a detailed discussion of exactly what just happened.

Notice that adding the second script didn't negate the first. This is an important thing to remember about event handlers.

Now, here's what ""Fired" string:weapon,string:muzzle,string:mode,string:ammo" means.

It is the array of values passed to the script when the "fired" handler is triggered.

This translates to:

["fired",{[weaponType, muzzleType, fireMode, ammoType] exec "eventHandlerA.sqs"}]

Now if you where paying close attention, you should have noticed that something is funky here. The official comref is wrong!

What was REALLY in the array?

object:unitFiring, string:weapon, string:mode, string:ammo, string:muzzle

The easiest way to check these in the future: just paste the following into a unit's init field and trigger the event:

this addeventhandler["eventType", {hintC format["Return: %1", _this]}]

example: this addeventhandler["fired", {hintC format["Return: %1", _this]}]

You can figure out the types and what they mean from there for any others you may come across that are simply misdocumented.

Ok, now for remove event handler:

Quote[/b] ]

object removeEventHandler handler

Operand types:

object: Object

handler: Array

Compatibility:

Version 1.85 required.

Type of returned value:

Nothing

Description:

Removes event handler added by addEventHandler. Format of handler is [type,index]. Index is returned by addEventHandler. When any handler is removed, all handler indices higher that the deleted one should be decremented.

Example:

player removeEventHandler ["killed",0]

Create a radio alpha trigger in your mission and paste this into the command line

wSoldier1 removeEventHandler ["fired", eventHandlerAIndex]; eventHandlerBIndex = eventHandlerBIndex - 1

Test it and notice that eventHandlerA.sqs no longer executes after radio alpha fires.

The blow by blow:

wSoldier1 is the guy to remove the event handler from.

"fired" is the type of event handler to remove.

eventHandlerAIndex is the index of the event handler.

Since you removed an event handler, it is important to decrease the index of all event handlers added after the one being removed. In an actual mission, it would better to use a script to see which event handlers are higher than the one being removed, decrement them, and then remove it.

Lastly, it's time to cover removeAllEventHandlers

Quote[/b] ]

object removeAllEventHandlers handlerType

Operand types:

object: Object

handlerType: String

Compatibility:

Version 1.85 required.

Type of returned value:

Nothing

Description:

Removes all event handlers of given type that were added by addEventHandler.

Example:

player removeAllEventHandlers "killed"

Create a radio bravo trigger in your mission and paste this into the command line

wSoldier1 removeAllEventHandlers "fired"

Test the mission and you'll see that no "fired" event handlers fire after radio bravo is executed.

I don't think I need to go into further detail on this one.

Below is the mission I built writing this step by step.

mission.sqm

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

class Mission

{

randomSeed=15801347;

class Intel

{

};

class Groups

{

items=1;

class Item0

{

side="WEST";

class Vehicles

{

items=1;

class Item0

{

position[]={9692.500000,29.834999,3979.525879};

id=0;

side="WEST";

vehicle="OfficerW";

player="PLAYER COMMANDER";

leader=1;

skill=0.600000;

text="wSoldier1";

};

};

};

};

class Sensors

{

items=3;

class Item0

{

position[]={9764.033203,28.924236,3983.852539};

a=5000.000000;

b=5000.000000;

activationBy="WEST";

timeoutMin=2.000000;

timeoutMid=2.000000;

timeoutMax=2.000000;

age="UNKNOWN";

expActiv="player globalChat format [""Event Handler A Index: %1"", eventHandlerAIndex]; player globalChat format [""Event Handler B Index: %1"", eventHandlerBIndex]";

class Effects

{

};

};

class Item1

{

position[]={9766.983398,28.851793,3962.153564};

a=0.000000;

b=0.000000;

activationBy="ALPHA";

age="UNKNOWN";

expActiv="wSoldier1 removeEventHandler [""fired"", eventHandlerAIndex]; eventHandlerBIndex = eventHandlerBIndex - 1";

class Effects

{

};

};

class Item2

{

position[]={9771.083008,28.282270,3932.822510};

a=0.000000;

b=0.000000;

activationBy="BRAVO";

age="UNKNOWN";

expActiv="wSoldier1 removeAllEventHandlers ""fired""";

class Effects

{

};

};

};

};

class Intro

{

randomSeed=16241155;

class Intel

{

};

};

class OutroWin

{

randomSeed=9156099;

class Intel

{

};

};

class OutroLoose

{

randomSeed=9971715;

class Intel

{

};

};

Here is init.sqs

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">eventHandlerAIndex = wSoldier1 addEventHandler ["fired",{_this exec "eventHandlerA.sqs"}]

eventHandlerBIndex = wSoldier1 addEventHandler ["fired",{_this exec "eventHandlerB.sqs"}]

Here is eventHandlerA.sqs

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

here is eventHandlerB.sqs

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

_weapon = _this select 1

_mode = _this select 3

_ammo = _this select 2

_muzzle = _this select 4

player globalChat format["Unit Firing: ""%1""", _unitFiring]

player globalChat format["weapon: ""%1""" , _weapon ]

player globalChat format["muzzle: ""%1""" , _muzzle ]

player globalChat format["mode: ""%1""" , _mode ]

player globalChat format["ammo: ""%1""" , _ammo ]

Share this post


Link to post
Share on other sites

First of all:

I highly recommend you not to call scripts directly and unchecked from fired event handlers!

This is because scripts get loaded into memory each time they are called, which will really slow down performance on automatic rifles.

Rather use a function to check whether the right weapon is fired etc. and execute a script depending on the check, so the scripts aren't loaded everytime the unit fires a round.

Better yet would be a combined option with triggers IMO, at least in your case.

1) When West Unit Jon Doe fires then trigger activates sound sample "unit say [sound sample]"

Set up the trigger and write in its condition line 'saySound'. If you want it to be usable several times, set it to 'Repeatedly', make a copy of the trigger (where you deactivate the sound activation, of course), give the a min, average and max time of some seconds (depending on the length of your sound) and write in its onActivation line 'saySound=false'.

Now on to your unit: Write in its init line 'this addEventHandler ["fired", {if((_this select 1) == "WEAPON"= then {saySound=true; sayUnit=_this select 0}}]'. Now in either your init.sqs or some init line add the initialisation of the variables: 'saySound=false; sayUnit=objNull'.

What it does is this: When the unit fires the weapon WEAPON (change it in the sample) it activates the trigger by switching the boolean. This is totally performance-friendly. The trigger plays the sound, while the seconds pass in the second trigger which sets back the boolean afterwards, so the process can start once again.

Quote[/b] ]2) When car blows up then triggers "East units attack" or East or West Units start in waypoint or action.

Write in the cars init-line:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">this addEventHandler ["killed",{carDead=true}]

Again I recommend to initialize carDead with false in some init line or the init.sqs, you can use carDead in any waypoint or trigger condition now.

Quote[/b] ]3) Unit West or East fires AK, then trigger activates sound sample [ak sound] and or m16 fires and triggers [sound sample m16 or UnitM16 sound] something like that.

Just look at the solution for the first question and alter the fired event handler a bit. Insert the right weapon and the right code in the if-statement and everything should work out fine.

Share this post


Link to post
Share on other sites
First of all:

I highly recommend you not to call scripts directly and unchecked from fired event handlers!

This is because scripts get loaded into memory each time they are called, which will really slow down performance on automatic rifles.

Rather use a function to check whether the right weapon is fired etc. and execute a script depending on the check, so the scripts aren't loaded everytime the unit fires a round.

I second that.

Also note that in many cases you can write all needed code straight to the event handler itself so there is no need to call a function or execute a script. I think that this is the most efficient way to use event handlers because the code in the event handler must be stored within the event handler itself and thus jumps around memory locations will very likely be reduced.

Share this post


Link to post
Share on other sites

WOA! wow_o.gif This is good stuff, I'm writing this down...I will report back in a jiff

Thanks Col. Sanders, Baddo and Hardrcock, I'm going to give it a try. biggrin_o.gif

Share this post


Link to post
Share on other sites

Oh noo, do I have to get into the mission.sqm file? drat, ok.

Share this post


Link to post
Share on other sites

Uhh.... okay, I might be dragging this further off topic, but let me say my 2c on eventhandlers.

A good way I've found to deal with adding code into an eventhandler is to use an external file and the 'loadfile' command. I'll use an example. Let's say you want to do a bunch of stuff when a 'fired' eventhandler runs (the code doesn't matter, I've just used it as an illustration):

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

_array = +(GENB_IIF_data select 0);

_array = _array - [_shooter];

GENB_IIF_data set [0, _array];

_shooter domove getpos _shooter;

_shooter removeeventhandler ["fired", 0];

Okay, you could try and squeeze that into one line, and put it into the eventhandler, but it would be terribly hard to understand:

guy addeventhandler ["fired", {_shooter = _this select 0; _array = +(GENB_IIF_data select 0); .... }]

So, instead, you can put all that code into an external .sqf file. Then you would load it directly into the eventhandler like this:

guy addeventhandler ["fired", loadfile "eventhandlerstuff.sqf"]

Notice that I'm NOT putting the loadfile into a codestring! The loadfile is LOADING the codestring at the same time the EH is added!

Anyway, I doubt that helps anybody, but oh well whistle.gif

Share this post


Link to post
Share on other sites
guy addeventhandler ["fired", loadfile "eventhandlerstuff.sqf"]

Damn good idea, I must admit! wow_o.gif

Share this post


Link to post
Share on other sites

Thanks General Barron, that's a very handy tip. Helps alot with my "stuff all code straight into event handlers" obsession... tounge2.gif

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×