add '_thisArgs', '_thisId', '_thisType' and '_thisFnc' and to CBA events

[commy2]

Closes: #374

Adds the same meta data CBA_fnc_addBISEventHandler has to the CBA events.

• adds optional parameter to CBA_fnc_addEventHandler to assign arguments to the event.

_thisArgs - Arguments passed when adding the event handler.
_thisId - Id that can be used to remove the event via CBA_fnc_removeEventHandler
_thisType - the name of the event ("testEvent" in ["testEvent", ...] call CBA_fnc_addEventHandler)
_thisFnc - function that is executed when the event happens

Note: If the arguments passed to CBA_fnc_addEventHandler are an array, they are stored as array reference and not as copy. That means you can modify these arguments even after the event was added.

Needs some more testing, will do later ...

[Killswitch00]

Should the macro argument "params" be renamed so as to not collide with the reserved word (command) params?

[commy2]

Yes. That collided with the params command I added ...

[commy2]

One time event handler printing "hello world"

["test1", {
    systemChat str _thisArgs;
    [_thisType, _thisId] call CBA_fnc_removeEventHandler
}, "hello world"] call CBA_fnc_addEventHandler;

...

"test1" call CBA_fnc_localEvent

Problem is that you are modifing an array of GVAR(eventsNamespace) while iterating through it via forEach which is undefined ... Searching for a work-around.

[commy2]

done

[PabstMirror]

I'm really not sure if any of this is necessary, my main concern is that there will be a performance cost to adding these args.

For 10x localEvent calls for something with 3 added ehs:

Old: 0.218436 ms 0.216403 ms 0.217628 ms
New: 0.326691 ms 0.327654 ms 0.324465 ms

[commy2]

Good point. It's performance vs. functionality. I have no idea with what we should go here.
+0.10 ms isn't that bad though honestly

[PabstMirror]

ACE calls multiple EHs for each bullet fired, so 50% increase isn't good

I think we can do most of what we need by using a function wrapper. Check out my demo code here (not tested, more of an idea): https://github.com/CBATeam/CBA_A3/compare/addEventHandlerWrapper?expand=1

[commy2]

Is it a 50% increase even when measuring with the actual event function you are calling?

[PabstMirror]

Prep:
["test", {x1=_this;}] call CBA_fnc_addEventHandler;
["test", {x2=_this;}] call CBA_fnc_addEventHandler;
["test", {x3=_this;}] call CBA_fnc_addEventHandler;

Test:
["test", []] call CBA_fnc_localEvent;
["test", []] call CBA_fnc_localEvent;
["test", []] call CBA_fnc_localEvent;
["test", []] call CBA_fnc_localEvent;
["test", []] call CBA_fnc_localEvent;
["test", []] call CBA_fnc_localEvent;
["test", []] call CBA_fnc_localEvent;
["test", []] call CBA_fnc_localEvent;
["test", []] call CBA_fnc_localEvent;
["test", []] call CBA_fnc_localEvent;

[commy2]

My point was that {x1=_this;} is an extremly simple function. The bigger the event function is, the smaller the share of the overhead of CBA_fnc_localEvent becomes.

[commy2]

@PabstMirror I read the link you posted.
I like that idea. It would mean having no additional overhead by default, but an alternative addEventHandler function that would apply all these variables.
Any naming suggestions for FUNC(addBigEH)?

CBA_fnc_addEventHandlerArguments ??
CBA_fnc_addArgumentsEventHandler ??

I'd still have to copy the array though, but that is only once per event call and not once per event per call.

[Killswitch00]

addEventHandlerArgs, addArgsEventHandler

An alternative/wrapper function sounds like the best way forward, so as to not compromise performance of the original function. Now, to think of a suitable name...

[commy2]

Done.

I'm going with addEventHandlerArgs instead of the usual addXEventHandler, because it isn't actually a new thing on it's own. It also uses the same removeEventHandler function.