eventhandlers What exactly are scriptedEventHandlers? [ANSWERED but still very instructive]

[ZaellixA 383]

Hey all,

 

I am quite new to scripting and have been looking into eventHandlers a bit lately. I stumbled across the scriptedEventHandlers. I am not sure I really understand the concept of a scipted eventHandler against a "normal" eventHandler. So, what exactly is the difference between those two? I mean, that in my understanding (which I believe to be incomplete) both "kinds" of eventHandlers are called when a specific event is happened and if this is the case what is the difference then? 😕

 

So, the question I am posing here is quite broad, I know, but if there's any good text I could have a look at somewhere online, or a video or some educational material I would really like to have a look. Otherwise if anyone here could throw some clarifications (without having to spend too much time as to write down a full guide on eventHandlers) they would be extremely welcome.

 

Thanks,

 

Achilles.

Edited June 9, 2019 by ZaellixA
Changed topic's title

[Mr H. 402]

I think you are refering to CBA's scripted EH system, it basically  allows scripters to create their own event handlers. The EventHandlers in A3 are "hardcoded" you can listen to them or not, use them when they are fired etc. but not define new ones. With CBA's EH you can create new ones. This is useful for mod makers who want to create a framework for mission makers to use. For example ACE 3 creates a lot of CBA EHs.

[Grumpy Old Man 3546]

This will cover most stuff about scripted eventhandlers.

 

Cheers

[ZaellixA 383]

Thank you both for the info. It is really appreciated.

 

2 hours ago, Mr H. said:

I think you are refering to CBA's scripted EH system, it basically  allows scripters to create their own event handlers. The EventHandlers in A3 are "hardcoded" you can listen to them or not, use them when they are fired etc. but not define new ones. With CBA's EH you can create new ones. This is useful for mod makers who want to create a framework for mission makers to use. For example ACE 3 creates a lot of CBA EHs.

Well, I was actually referring to the scriptedEventHandlers BI provides. I can't really understand what they are doing differently than the "normal" EHs. I was completely unaware of CBAs EHs, which by the way, is great to find out about :).

 

1 hour ago, Grumpy Old Man said:

This will cover most stuff about scripted eventhandlers.

 

Cheers

I have already seen the info the link provides, but still didn't manage to find any practical differences between the two "types" of EHs. I apologize if I am missing something obvious, but my experience so far with similar facilities is only with some C/C++ callbacks. So I can't really understand what is the difference between scriptedEventHandler["arsenalOpened"] and eventHandler["killed"].

 

Any insight or direction would be most welcome.

 

Again, thanks for taking the time to help.

 

Achilles.

[phronk 898]

Doesn't work like a regular eventHandler which loops; this just executes when you call BIS_fnc_callScriptedEventHandler. It loops only if the 2nd parameter is one of the listed in-game scripted eventHandlers, such as "arsenalOpened" (Correct me if I'm wrong)

 

This might help:

https://community.bistudio.com/wiki/BIS_fnc_addScriptedEventHandler -- Adding a scripted eventHandler

https://community.bistudio.com/wiki/BIS_fnc_callScriptedEventHandler -- Calling a scripted eventHandler

https://community.bistudio.com/wiki/BIS_fnc_removeScriptedEventHandler -- Removing a scripted eventHandler

 

Example: (Doesn't loop)

//Adds the eventHandler... code executes only when BIS_fnc_callScriptedEventHandler is called
[true,"whatEverIWantThisToBeCalled",{if(!isAbleToBreathe player)then{hint"#ICANTBREATHE"}else{hintSilent"";};}]call BIS_fnc_addScriptedEventHandler;

//This code will call the above eventHandler/code; if player underwater without a rebreather, hint will be displayed
[true,"whatEverIWantThisToBeCalled",[player]]call BIS_fnc_callScriptedEventHandler;

 

BIS_fnc_addEventHandler function code, found in Functions Viewer in-game:

Spoiler

/*
	Author: 
		Karel Moricky, optimised by Killzone_Kid

	Description:
		Adds scripted event handler and returns id
		"ScriptedEventHandlerAdded" scripted EH is called

	Parameter(s):
		0: BOOL, NAMESPACE, OBJECT, GROUP, LOCATION, CONTROL or DISPLAY - namespace in which handler is saved. When BOOL, missionNameSpace is used.
		1: STRING - handler name
		2: CODE or STRING - code executed upon calling

	Returns:
		NUMBER - handler ID
*/

params [
	["_namespace", objNull, [true, missionNamespace, objNull, grpNull, locationNull, controlNull, displayNull]],
	["_name", "", [""]],
	["_code", {}, [{}, ""]]
];

if (_code isEqualType "") then {_code = compile _code};
if (_namespace isEqualType true) then {_namespace = missionNamespace};

_name = "BIS_fnc_addScriptedEventHandler_" + _name;
private _handlers = _namespace getVariable _name;

if (isNil "_handlers") exitWith 
{
	_namespace setVariable [_name, [_code]];
	
	[missionNamespace, "ScriptedEventHandlerAdded", [_namespace, _name, 0]] call BIS_fnc_callScriptedEventHandler;
	0
};

private _handlerID = _handlers find -1;

if (_handlerID < 0) then
{
	_handlerID = _handlers pushBack _code;
}
else
{
	_handlers set [_handlerID, _code];
};

[missionNamespace, "ScriptedEventHandlerAdded", [_namespace, _name, _handlerID]] call BIS_fnc_callScriptedEventHandler;
_handlerID 

 

BIS_fnc_callScriptedEventHandler function code, found in Functions Viewer in-game:

Spoiler

/*
	Author: 
		Karel Moricky, optimised by Killzone_Kid

	Description:
		Calls scripted event handlers

	Parameter(s):
		0: BOOL, NAMESPACE, OBJECT, GROUP, LOCATION, CONTROL or DISPLAY - namespace in which handler is saved. When BOOL, missionNameSpace is used.
		1: STRING - handler name
		2: ARRAY - arguments passed to the code
		3 (Optional): BOOL - true to expect returned value from all codes

	Returns:
		ARRAY - list of returned values or empty array
*/

#define EHID_VAR _thisScriptedEventHandler

params [
	["_namespace", objNull, [true, missionNamespace, objNull, grpNull, locationNull, controlNull, displayNull]],
	["_name", "", [""]],
	["_args", [], [[]]]
];

if (_namespace isEqualType true) then {_namespace = missionNamespace};

//-- return is needed
if (param [3, false] isEqualTo true) exitWith
{
	EHID_VAR = -1;
	(_namespace getVariable ["BIS_fnc_addScriptedEventHandler_" + _name, []]) apply 
	{
		EHID_VAR = EHID_VAR + 1;
		if (_x isEqualType {}) then 
		{
			[_args, _x] call
			{
				private ["_namespace", "_name", "_args", "_x"];
				_this select 0 call (_this select 1);
			};
		};
	};
};

//-- no return is needed
{
	EHID_VAR = _forEachIndex;
	if (_x isEqualType {}) then 
	{
		[_args, _x] call
		{
			private ["_namespace", "_name", "_args", "_x", "_forEachIndex"];
			_this select 0 call (_this select 1);
		};
	};
	
} 
forEach (_namespace getVariable ["BIS_fnc_addScriptedEventHandler_" + _name, []]);

[]

 

 

 

[ZaellixA 383]

Hhhhhmmmm..., Not sure if I am on the correct track. I am still kinda confused. What I have understood so far is summarized in the following. So, please correct me if I am wrong.

 

By adding a scriptedEventHandler I can create an event which will execute a specific "code snippet" whenever I call it (from another place and instance, in another script). So, to my understanding it kinda works the other way around compared to "normal" eventHandlers, which will be called automatically when an event is triggered and then I can program the behavior of the script that will be executed when the event happens. Thus in the first case (scriptedEventHandler) the behavior for the event is fixed, while in the second (eventHandler) I can code different behavior for each instance of execution.

 

So to summarize:

1) eventHandler: - Called whenever a specific event happens (depending on the type, "killed" for example).

                              - Program the behavior of the code that will be executed whenever this event is "triggered". Specific and possibly different to each instance.

2) scriptedEventHandler: - Create a specific event (by giving the handler a "name") that will execute a specific block of code

                                               (so the behavior is fixed for this kind of events).

                                             - Call the event (thus the specified code accompanying the event handler) whenever you see fit (or whenever the event happens) manually.

 

But then, what is the difference between executing a specific script than calling a scriptedEventHandler? 😕

 

I think now I am more confused LOL.

[ZaellixA 383]

Aaaaaaahhhhhhhhhhh..............

 

NO. It does NOT work like that. You actually add many different scriptedEventHandlers for the same event (same name), which will be executed when you call the corresponding callScriptedEventHandler!

 

Aha, now this makes a bit more sense. So in this way you can still have different behaviors for the same event. Hhhhmmmm, but then what is the difference with scriptedEventHandlers and the CBA eventHandlers? @Mr H. would you care to shed some light here?

 

Nevertheless, thank you all for your help. It was very useful. I will look a bit more into CBA's eventHandlers and whenever I manage to find a good example for the use of either (scriptedEventHandler and/or CBA's) I will make sure to post here.

 

Once more, thank you all for the help.

 

EDIT: Hahaha, I have edited the post about 4 times correcting spelling and mistypes... Maybe this explains a bit why I was not able to understand scriptedEventHandlers at first place LOL.

[GEORGE FLOROS GR 4207]

1 hour ago, ZaellixA said:

scriptedEventHandler["arsenalOpened"]

 

check also this ex .  since we are talking about it :

- and by the way , cba has each own eventhandles.

Spoiler

On 2/28/2018 at 11:13 PM, davidoss said:

initPlayerLocal.sqf

[missionNamespace, "arsenalClosed", {
	player setVariable ["Saved_Loadout",getUnitLoadout player];
	hint "Selected gear saved!"
	}] call BIS_fnc_addScriptedEventHandler;
player addEventHandler ["Respawn",{

		0 = [_this select 0] spawn {
		
			params [["_player",objNull,[objNull]]];
				waitUntil {sleep .2; alive _player};
				_player setUnitLoadout (_player getVariable ["Saved_Loadout",[]]);
				
		};
}];

https://community.bistudio.com/wiki/BIS_fnc_addScriptedEventHandler

[Larrow 2822]

I like to think of them somewhat similar to delegates.

 

Create the delegate.

Register functions to the delegate.

Invoke the delegate passing arguments.

All register functions are called, all being passed the same arguments.

 

The scripted event system is a multi delegate where the name passed is a reference.

Register functions all under the same reference name. BIS_fnc_addScriptedEventHandler

Call BIS_fnc_callScriptedEventHandler passing the reference name and arguments ( Invoke )

All register functions for the reference name are called, all being passed the same arguments.

 

Spoiler

TAG_fnc_aKeyWasPressed = {
	params[ "_keyCode" ];
	
	systemChat format[ "A key was pressed: %1", _keyCode ];
};

TAG_fnc_someKeyWasPressed = {
	params[ "_keyCode" ];
	
	systemChat format[ "Some key was pressed: %1", _keyCode ];
};

TAG_fnc_somebodyPressedAKey = {
	params[ "_keyCode" ];
	
	systemChat format[ "Somebody pressed a key: %1", _keyCode ];
};

waitUntil{ time > 0 };

[ missionNamespace, "keyPress", TAG_fnc_aKeyWasPressed ] call BIS_fnc_addScriptedEventHandler;
[ missionNamespace, "keyPress", TAG_fnc_someKeyWasPressed ] call BIS_fnc_addScriptedEventHandler;
[ missionNamespace, "keyPress", TAG_fnc_somebodyPressedAKey ] call BIS_fnc_addScriptedEventHandler;

findDisplay 46 displayAddEventHandler [ "KeyUp", {
	params[ "", "_keyCode" ];
	
	[ missionNamespace, "keyPress", [ _keyCode ] ] call BIS_fnc_callScriptedEventHandler;
}];

 

 

[ZaellixA 383]

Thanks for the reply George.

I understood the use of "arsenalClosed", but what I was not able to understand was how to use scriptedEventHandlers to create your own events. Because to me, the "arsenalOpened" scriptedEventHandler is like a common eventHandler, in the sense that it will be called automatically by the engine when the arsenal is closed.

On the contrary I was looking for a better understanding on how to use sciptedEventHandlers to call on "arbitrary" events.

 

Nevertheless, thanks a lot for the reply and the nice example.

[ZaellixA 383]

1 hour ago, phronk said:

Doesn't work like a regular eventHandler which loops; this just executes when you call BIS_fnc_callScriptedEventHandler. It loops only if the 2nd parameter is one of the listed in-game scripted eventHandlers, such as "arsenalOpened" (Correct me if I'm wrong)

 

This might help:

https://community.bistudio.com/wiki/BIS_fnc_addScriptedEventHandler -- Adding a scripted eventHandler

https://community.bistudio.com/wiki/BIS_fnc_callScriptedEventHandler -- Calling a scripted eventHandler

https://community.bistudio.com/wiki/BIS_fnc_removeScriptedEventHandler -- Removing a scripted eventHandler

 

Example: (Doesn't loop)

//Adds the eventHandler... code executes only when BIS_fnc_callScriptedEventHandler is called
[true,"whatEverIWantThisToBeCalled",{if(!isAbleToBreathe player)then{hint"#ICANTBREATHE"}else{hintSilent"";};}]call BIS_fnc_addScriptedEventHandler;

//This code will call the above eventHandler/code; if player underwater without a rebreather, hint will be displayed
[true,"whatEverIWantThisToBeCalled",[player]]call BIS_fnc_callScriptedEventHandler;

 

BIS_fnc_addEventHandler function code, found in Functions Viewer in-game:

  Reveal hidden contents

/*
	Author: 
		Karel Moricky, optimised by Killzone_Kid

	Description:
		Adds scripted event handler and returns id
		"ScriptedEventHandlerAdded" scripted EH is called

	Parameter(s):
		0: BOOL, NAMESPACE, OBJECT, GROUP, LOCATION, CONTROL or DISPLAY - namespace in which handler is saved. When BOOL, missionNameSpace is used.
		1: STRING - handler name
		2: CODE or STRING - code executed upon calling

	Returns:
		NUMBER - handler ID
*/

params [
	["_namespace", objNull, [true, missionNamespace, objNull, grpNull, locationNull, controlNull, displayNull]],
	["_name", "", [""]],
	["_code", {}, [{}, ""]]
];

if (_code isEqualType "") then {_code = compile _code};
if (_namespace isEqualType true) then {_namespace = missionNamespace};

_name = "BIS_fnc_addScriptedEventHandler_" + _name;
private _handlers = _namespace getVariable _name;

if (isNil "_handlers") exitWith 
{
	_namespace setVariable [_name, [_code]];
	
	[missionNamespace, "ScriptedEventHandlerAdded", [_namespace, _name, 0]] call BIS_fnc_callScriptedEventHandler;
	0
};

private _handlerID = _handlers find -1;

if (_handlerID < 0) then
{
	_handlerID = _handlers pushBack _code;
}
else
{
	_handlers set [_handlerID, _code];
};

[missionNamespace, "ScriptedEventHandlerAdded", [_namespace, _name, _handlerID]] call BIS_fnc_callScriptedEventHandler;
_handlerID 

 

BIS_fnc_callScriptedEventHandler function code, found in Functions Viewer in-game:

  Reveal hidden contents

/*
	Author: 
		Karel Moricky, optimised by Killzone_Kid

	Description:
		Calls scripted event handlers

	Parameter(s):
		0: BOOL, NAMESPACE, OBJECT, GROUP, LOCATION, CONTROL or DISPLAY - namespace in which handler is saved. When BOOL, missionNameSpace is used.
		1: STRING - handler name
		2: ARRAY - arguments passed to the code
		3 (Optional): BOOL - true to expect returned value from all codes

	Returns:
		ARRAY - list of returned values or empty array
*/

#define EHID_VAR _thisScriptedEventHandler

params [
	["_namespace", objNull, [true, missionNamespace, objNull, grpNull, locationNull, controlNull, displayNull]],
	["_name", "", [""]],
	["_args", [], [[]]]
];

if (_namespace isEqualType true) then {_namespace = missionNamespace};

//-- return is needed
if (param [3, false] isEqualTo true) exitWith
{
	EHID_VAR = -1;
	(_namespace getVariable ["BIS_fnc_addScriptedEventHandler_" + _name, []]) apply 
	{
		EHID_VAR = EHID_VAR + 1;
		if (_x isEqualType {}) then 
		{
			[_args, _x] call
			{
				private ["_namespace", "_name", "_args", "_x"];
				_this select 0 call (_this select 1);
			};
		};
	};
};

//-- no return is needed
{
	EHID_VAR = _forEachIndex;
	if (_x isEqualType {}) then 
	{
		[_args, _x] call
		{
			private ["_namespace", "_name", "_args", "_x", "_forEachIndex"];
			_this select 0 call (_this select 1);
		};
	};
	
} 
forEach (_namespace getVariable ["BIS_fnc_addScriptedEventHandler_" + _name, []]);

[]

 

 

 

Thanks for the example code phronk. I didn't notice it right away. That's exactly the functionality I understood. It's good to have reassurance :).

[ZaellixA 383]

Thanks Larrow. Yep, I got. It's good to see that all explanations fall exactly onto my understanding.

 

And as always, when you answer one of your questions another myriad of them come up :D. So, to follow Mr H.'s comment about the CBA eventHandlers, do they function more like the "normal" eventHandlers or the scripted ones?

 

If anyone could give a brief comment on that it could be a good starting point for my exploration of CBA's eventHandlers.

 

Once more (it's never enough with this community :)) thank you all for the help.

[GEORGE FLOROS GR 4207]

9 minutes ago, ZaellixA said:

a good starting point for my exploration of CBA's eventHandlers.

 

Maybe the best place to discuss about it , is the Cba topic :

 

 

[Larrow 2822]

51 minutes ago, ZaellixA said:

Because to me, the "arsenalOpened" scriptedEventHandler is like a common eventHandler, in the sense that it will be called automatically by the engine when the arsenal is closed.

Its not called by the engine. It is called by BI's arsenal function.

 

41 minutes ago, ZaellixA said:

So, to follow Mr H.'s comment about the CBA eventHandlers, do they function more like the "normal" eventHandlers or the scripted ones?

I may be a little off and mainly going from memory of the original Xeno extended event handlers (been a long time since I read through it Arma2) which may of had extra bells and whistles added to it by CBA team.

They are normal engine events. For each engine event available an event is added to the config via their mod to each base class. That event calls their own function. You register functions to their function (either through script and they also pass the mission config for an event structure I believe ).

When the engine event happens their code calls all the functions that where registered to their function.

Gets around the problem of some events are only really viable from the config ("Init" on an object for instance). Its basically a wrapper.

 

[ZaellixA 383]

23 minutes ago, Larrow said:

Its not called by the engine. It is called by BI's arsenal function.

One more piece of information added. Thanks Larrow.

 

24 minutes ago, Larrow said:

They are normal engine events. For each engine event available an event is added to the config via their mod to each base class.

Well, I am not really familiar with engine events. I mean, what is considered to be an event? How can you have access to them?

[Larrow 2822]

4 minutes ago, ZaellixA said:

I mean, what is considered to be an event?

Everything on this and linked pages are engine events, other than scripted event handlers. They can be used via their relative scripting commands, also shown above each section on those pages.

 

As you can see from the bottom of that page in the example for "Weapon Config Muzzle Events" events can also be subscribed to through the config via an addon.

Same for UI, although UI configs included with a mission are read by the game on mission load, where as object base classes are not and require an addon to change.

 

For instance UI...

class My_ui {
	idd = 10000;
	
	onMouseButtonDown = "[] call TAG_fnc_myUI_onMouseDown";
};

This is a UI event for when a mouse button is pressed whilst over the UI. Handled from the UI config.

Exactly the same can be done by script by saying...

createDialog "My_ui";
findDisplay 10000 displayAddEventHandler [ "mouseButtonDown", {
	[] call TAG_fnc_myUI_onMouseDown;
}];

 

Exactly the same is true for many of the classes in the game especially those under CfgVehicles. But like is said above you would need to write an addon to register for those events via config as the mission config file (description.ext) is limited in what classes can be added there( in the sense that the engine does not merge any changes into its main config ). So as a mission maker/scripted you are bound by the available scripting commands for object events.

 

Now a few events do not make sense to use from script, for instance "Init". If you have to wait for the item to spawn before you can add the event to it, its init has already come and gone. This is where XEH/CBA comes in as they already have functions registered to the events in the base classes via config from their addon. Their registered function calls your function providing the functionality that would otherwise be impossible for mission makers/scripters.

 

Thats a very quick overview. Hope that makes sense.

[ZaellixA 383]

Absolutely!

 

This is quite some information to process and I have to admit I can't assimilate all of it right away. I will have to have a better look at it in order to better understand exactly how things run around here and how each piece of information comes together.

 

Nevertheless both examples are quite instructive. One more thing I would like to ask is..., how can you actually register events? I am not sure I have understood that very well. I mean, I do understand your UI example and it does make sense to me. But, what if I want to add an arbitrary event to a class, or even an already created object? How do events work behind the scenes? For example if instead of onMouseButtonDown I wanted to use a inProximity, which could be an arbitrary event I would like to create, how could I possibly do that? How would this event get triggered?

 

Pffff..., this whole topic started from scriptedEventHandlers and ended up going a bit deeper into eventHandlers in general. Please let me know if I ask too much from people here or if I should start a different topic.

[jshock 513]

3 hours ago, ZaellixA said:

this whole topic started from scriptedEventHandlers and ended up going a bit deeper into eventHandlers in general. Please let me know if I ask too much from people here or if I should start a different topic.

 

Eh, one could argue that without fundamentally understanding event handlers in general you can't truly understand the difference between the base EHs and scripted ones . I for one have had the similar questions too.

[Mr H. 402]

8 hours ago, ZaellixA said:

Aha, now this makes a bit more sense. So in this way you can still have different behaviors for the same event. Hhhhmmmm, but then what is the difference with scriptedEventHandlers and the CBA eventHandlers? @Mr H. would you care to shed some light here?

Wasn't even aware that this was in A3 😉 I have always used cba's system!

[Von Quest 1163]

There are often duplicate and several variations of the same thing, as things evolve and get re-writen, change, become obsolete, simplied, etc.

 

Old code tends to stay listed in wiki/reference sources. There is often several ways to go about executing and accomplishing the exact same goal with varying pros/cons for different reasons. We also have different devs working on different sub-projects over years of development.

 

Computer Science is written by humans with all the issues, baggage, psychology, and other quirks we make up and drag along with us in this journey though our wacky universe (and armaverse).

 

And I'll leave with this... We can see your wheels turning. I'd recommend tackling ArmA in small bits and chunks. It's a massive hobby and labyrinth you'll be spelunking for years. Welcome to the madness that is... ArmA.

[jshock 513]

Now I haven't dug too deep into understanding the extent of CBA's system but my question is with either system is it possible to make a custom event handler for say, entering and leaving the area of a marker, without having to create any sort of while loop or OEF handler?

 

In basic vanilla EH terms (I know there are some major assumptions here):

 

player addEventHandler [ "EnterMarkerArea",
	{
		params ["_marker"];
		if (_marker isEqualTo "mySpecialMarker") then
		{
			hint "You made it!";
		};
	}
];
player addEventHandler [ "ExitMarkerArea",
	{
		params ["_marker"];
		if (_marker isEqualTo "mySpecialMarker") then
		{
			hint "You left the marker area!";
		};
	}
];

 

Because with how I understand either system atm it seems like there would still need to be some sort of loop or similar handling to call the "event" code?

 

 

[mrcurry 508]

On 6/3/2019 at 1:51 AM, ZaellixA said:

what if I want to add an arbitrary event to a class, or even an already created object? How do events work behind the scenes? For example if instead of onMouseButtonDown I wanted to use a inProximity, which could be an arbitrary event I would like to create, how could I possibly do that? How would this event get triggered?

 

Unfortunately we have little in the way of adding engine events. As for the scripted eventhandlers I think it's the same though I haven't delved deep in that topic.

 

To create your own kind of "events" you'd have to figure out your own framework to trigger said event. Most often this would revolve around running a loop to check a given condition, but you could work with triggers or piggyback off of another event. 

[ZaellixA 383]

5 hours ago, jshock said:

Now I haven't dug too deep into understanding the extent of CBA's system but my question is with either system is it possible to make a custom event handler for say, entering and leaving the area of a marker, without having to create any sort of while loop or OEF handler?

 

In basic vanilla EH terms (I know there are some major assumptions here):

 

player addEventHandler [ "EnterMarkerArea",
	{
		params ["_marker"];
		if (_marker isEqualTo "mySpecialMarker") then
		{
			hint "You made it!";
		};
	}
];
player addEventHandler [ "ExitMarkerArea",
	{
		params ["_marker"];
		if (_marker isEqualTo "mySpecialMarker") then
		{
			hint "You left the marker area!";
		};
	}
];

 

Because with how I understand either system atm it seems like there would still need to be some sort of loop or similar handling to call the "event" code?

 

 

Well, @jshock, thanks a lot for asking this, as it is exactly the point I was trying to understand when I first started messing with scriptedEventHandlers. So, I was wondering, what is the difference of running a constant loop and when the condition is met, run a script in every "concerned" unit? Now, I do understand that tracking the "concerned" units now has become a lot easier with the use of sciptedEventHandlers, but still haven't found a way to avoid this constant loop

.

As @mrcurry added (quoting below for completeness) you still have to find a way to trigger the scriptedEventHandler. Thus it's not possible (with my naive thoughts) to avoid the possible overhead of a loop. Furthermore, I am not sure that using a trigger will solve the loop thing, as triggers do run a check loop behind the scenes every 500 milliseconds (please correct me if I am wrong) [I consulted this article from killzone_kid].

2 hours ago, mrcurry said:

Unfortunately we have little in the way of adding engine events. As for the scripted eventhandlers I think it's the same though I haven't delved deep in that topic.

 

To create your own kind of "events" you'd have to figure out your own framework to trigger said event. Most often this would revolve around running a loop to chech a given condition, but you could work with triggers or piggyback of another event. 

Well, this has evolved to a very fruitful topic. Thank you all for the help and additions. There's quite some information here to try to assimilate and make use of.

 

Thank you all.

 

P.S.: Von Quest thanks for the reassurance about the vastness of the ArmAverse. I kinda realized it but it's good to have a confirmation 😉.

[Mr H. 402]

5 hours ago, jshock said:

Now I haven't dug too deep into understanding the extent of CBA's system but my question is with either system is it possible to make a custom event handler for say, entering and leaving the area of a marker, without having to create any sort of while loop or OEF handler? 

I use per frame event handler to do this where the condition is checked until it's met. But you're right about this I don't see any other way besides an OEF or a loop. (Might be wrong though).

[ZaellixA 383]

10 minutes ago, Mr H. said:

I use per frame event handler to do this where the condition is checked until it's met. But you're right about this I don't see any other way besides an OEF or a loop. (Might be wrong though).

Hhhhmmm, excuse my question @Mr H. but I am a bit unfamiliar with the "term" OEF. Would you care to shed some light????