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

[ZaellixA 383]

Well, as Dedmen posted, it's not just the structure (thus maintainability) that is affected. It does depend on the way you code but, it can indeed provide some performance increase.

5 hours ago, Dedmen said:

for a custom event you would still have to check in a loop, BUT! If you need to do the same thing in several places, you can either run N loops, or just run one loop, with one scripted event that get's triggered, and N eventhandlers.

As, I am sure you know, it's a lot more efficient to run one loop to check for the condition to invoke the handler (thus executing all scripts/functions registered to it) than running many loops to check for the same condition/event in all the places you want to be "affected"/executed when the condition becomes true.

 

So, it can provide increased performance compared to many loops checking for the same thing in different scripts.

[sarogahtyp 1108]

3 hours ago, ZaellixA said:

 

So, it can provide increased performance compared to many loops checking for the same thing in different scripts.

true and yes i already had this in mind. but i actually discovered longbows cron job manager script and with that i can get rid of those multiple loops and substitute those with only one single trigger. this technique has me impressed very much and it makes the potential performance advantage of scripted EHs redundant now. at least for me.

 

but exactly this was what i wanted to know to be sure to not choose the wrong track...

[phronk 898]

9 hours ago, Dedmen said:

regular eventhandlers "loop"?

 

@Dedmen Do they not? My understanding was that eventHandlers are constantly checking (looping) if the event (Fired, GetInMan, Explosion, etc.) is met, then checks condition for that event(s).

[jshock 513]

5 minutes ago, phronk said:

 

My understanding was that eventHandlers are constantly checking (looping) if the event (Fired, GetInMan, Explosion, etc.) is met, then checks condition for that event(s).

Well, technically everything is apart of the main game loop in the end, which I'd assume is the case with the conditions of the regular EHs, which is what I believe you meant. Dedmen may have misunderstood the scope of your statement.

[ZaellixA 383]

Well, how exactly EHs are coded in C++ we don't know (well, at least I don't). They could either be looping, or (more efficiently) be invoked (triggering all registered scripts/functions) every time an event has happened. This means that every time someone shoots a gun along with all the code that simulates the bullets, triggers the sound etc. a handle is invoked. Now, this in turn means that the handlers do NOT loop in the background and also, due to the fact that we do not have access to the engine itself, we cannot create our own eventHandlers... I mean like real event handlers, that do not have to loop (like scriptedEventHandlers have to do to find out when they should invoke all the registered scripts).

Consider this a form of interrupt, which is triggered only when the event has happened by the event itself, without having to check conditions in a loop (which would be quite inefficient in my opinion).

 

Again, I don't know how the EHs are implemented in RV so I can't really say, but it would make sense to me to work the way I described (although I am not a programmer and I don't know what the most efficient way would be...). Just presenting my intuition here, as to what is happening backstage.

[pierremgi 4904]

On 6/2/2019 at 6:53 AM, 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.

 

I'm not sure you "create" your own event handler. Imho it's just a tool playing with on each frame native EH and giving you the feeling you're writing a new EH in its presentation. I never use CBA (or ACE3) but it's perhaps easier to obtain a result with these tools. Perhaps, I'm wrong and CBA runs codes at a lower level than simple EHs or BI commands... in C++? This could be an interesting point to discuss, I don't have the answer, even after reading some topics like this one.

 

For BI "simple" EHs, there are probably some low level checks, faster than elaborated conditions (most of BI commands are already complex in term of engineering). We can guess some elementary "flags" (like bit control) for starting frames, when a unit fires,... So, this check triggers the reading of what variables are in some containers (of variables) and pass them in EH parameters. If you want to do that in a loop, with "simple" commands, waiting for a new projectile... It's hard time.

Just a though and thank you for this discussion.

[Dedmen 2716]

As usual, might already been answered but I prefer to answer everything I've missed.

 

On 6/4/2019 at 5:17 PM, sarogahtyp said:

what I don't get is what exactly is the difference between calling a function in a loop which checks if an event is happening and calling a scripted EH which does the same thing at least in my current understanding.

Main keyword is: "API"
Any mod or script can bind a handler to the event "somethingHappened" if you use scripted eventhandlers.
If you just had a loop that checks a condition. and then "call"s your specific "My_fnc_handleSomethingHappened" no other script can hook into that event and also be notified about it. Any other script who wants the same, has to run it's own check loop.

 

18 hours ago, phronk said:

Do they not? My understanding was that eventHandlers are constantly checking (looping) if the event (Fired, GetInMan, Explosion, etc.) is met, then checks condition for that event(s).

Them not actually doing that is the whole sense behind engine eventhandlers.

 

Some few things are done every frame or checked every frame. But most things aren't.
Fired eventhandler fires, when the in-engine code that spawns a bullet projectile runs.
The engine doesn't constantly check "did I just spawn a bullet?"

There is a "spawnBullet" function that runs when a bullet is spawned, why would the engine constantly check in a loop if that function might have ran, if they can just call the event inside that function.

 

17 hours ago, ZaellixA said:

we cannot create our own eventHandlers... I mean like real event handlers, that do not have to loop

Technically that is possible. Though that would be WAY above most people in this thread (unless you can write assembly code with a hex editor, I assume you don't).

 

17 hours ago, ZaellixA said:

They could either be looping

They aren't.

 

17 hours ago, ZaellixA said:

or (more efficiently) be invoked

Yep that's how they work.

 

17 hours ago, pierremgi said:

I'm not sure you "create" your own event handler. Imho it's just a tool playing with on each frame native EH and giving you the feeling you're writing a new EH in its presentation.

Really depends on the definition. A Event is just something that happens, no matter if it's fired by the engine, or some scripted loop.

 

 

[Lucullus 71]

Excellent thread, thanks @ZaellixA for your persistent questioning, thanks to all who respond to it, specifically @Dedmen, for your consistent style.

I've learned a lot, hopefully I can put that learned into practice.

[phronk 898]

@Dedmen Thanks for the explanation, good to know. 

[ZaellixA 383]

5 hours ago, Dedmen said:

Technically that is possible. Though that would be WAY above most people in this thread (unless you can write assembly code with a hex editor, I assume you don't).

Well, technically speaking I can write assembly code (not with a hex editor though...!!!) but this would be indeed way over my skills (only been doing some DSP programming on "DSP capable" microcontrollers like ARM Cortex M4 and only some specific time-critical tasks...!!!).

 

On the other hand it sounds quite intriguing to write your own ArmA eventHandlers, even if it's just for educational reasons...!!!

 

Once more thanks for all the info and the great clarifications. Your provisioning on insight is extremely appreciated

[Rosso777 22]

Two years late to the party but I just wanted to say that I *thoroughly* enjoyed this thread.
 

Achilles, your comprehension articulation is a breath of fresh air; watching someone like you (who is light years ahead of me scriptually) breakdown the issues and try to piece is it together.

 

The whole thread for me was like watching a meeting of the minds happen; names like Killzone, Dedmen, Larrow, and more are legendary in my book. You guys have managed to make Arma what it is with your own hands. The creativity that comes out through the code is so fascinating to watch; even more exciting when we’re able to experience it through the immersion that is the actual gameplay.

Bravo and thank you all for your efforts and knowledge over the years.