chammy 7 Posted April 18, 2006 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
ColonelSandersLite 0 Posted April 18, 2006 What exactly are you needing to do? Share this post Link to post Share on other sites
chammy 7 Posted April 18, 2006 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
ColonelSandersLite 0 Posted April 19, 2006 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
hardrock 1 Posted April 19, 2006 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
baddo 0 Posted April 19, 2006 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
chammy 7 Posted April 19, 2006 WOA! 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. Share this post Link to post Share on other sites
chammy 7 Posted April 19, 2006 Oh noo, do I have to get into the mission.sqm file? drat, ok. Share this post Link to post Share on other sites
General Barron 0 Posted April 20, 2006 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 Share this post Link to post Share on other sites
hardrock 1 Posted April 20, 2006 guy addeventhandler ["fired", loadfile "eventhandlerstuff.sqf"] Damn good idea, I must admit! Share this post Link to post Share on other sites
baddo 0 Posted April 20, 2006 Thanks General Barron, that's a very handy tip. Helps alot with my "stuff all code straight into event handlers" obsession... Share this post Link to post Share on other sites