how does eventhandlers beheave, technically?

[demonized 20]

How does eventhandlers beheave?

What are they? scripts waiting or something activated upon action?

primarily im asking for Single Player usage, and not the specifics in how to use a eventhandler.

is running a waitUntil in a script just as efficient and reliable as a eventhandler?

does one or the other use more CPU?

example not caring for any return value as killer in a killed eventhandler, only caring about if and when the unit is dead.

killed eventhandler VS waitUntil {!alive unit}

1: wich is quickest in returning dead unit?

2: wich is using more CPU than the other if any?

3: what technically is a eventhandler and how does it run? is it always active?

4: 50 killed eventhandlers VS 50 waitUntil {!alive unit} scripts, are there stacking penaltys when using multiple of one or the other, in terms of CPU usage/lag?

anyone have any insight into this, a dev maybe?

PS: i know fully how to use eventhandlers, im just wondering if waitUntils are 100% equal in terms of performance or not.

and technical details about their beheaviour.

---------- Post added at 07:58 PM ---------- Previous post was at 07:38 PM ----------

tests indicate waitUntil is faster, i dont know how to find difference in lag/CPU usage:

named a unit test.

placed code in init of test.

waitUntil test: - returned "0.0439453"

_null = [] spawn {
sleep 5;
_start = diag_tickTime;
test setDammage 1;
waitUntil {!alive test};
_stop = diag_tickTime;
diag_log format ["%1",_stop - _start];
};

killed eventhandler: - returned "0.0478516"

this addEventHandler ["killed", {
_stop = diag_tickTime;
diag_log format ["%1",_stop - DMZstart];
}];
_null = [] spawn {
sleep 5;
DMZstart = diag_tickTime;
test setDammage 1;
};

i think maybe my testing is not optimal, maybe it causes delays when collecting the global value of DMZstart.

[st_dux 26]

I honestly don't think it makes any noticeable difference performance-wise. Event Handlers are just more convenient.

[Muzzleflash 111]

They are not equivalent at all, and therefore do not make much difference if the performance it not the same. You can't get information about the killer from a waitUntil loop.

I also believe that an event handler does not take up cpu time except from the handler code and the actual addEventHandler call, while a "sleep-less" waitUntil is processed for each game frame. And if that is the case then you could add an event handler to a 1000 different units, taking no resource at all, while you would need to spawn a 1000 continously running scripts, each running some check-code often, to do it with a waitUntil.

I use event handlers whenever they can solve my problem.

Edited July 7, 2011 by Muzzleflash

[demonized 20]

example not caring for any return value as killer in a killed eventhandler, only caring about if and when the unit is dead

i specified this in OP.

I know im bikkering into very minor details, but it would be usable info to know how the process is run.

anyhow, logic tells me this:

how does the game know when a unit is dead? it must either be monitored or something is executed automatically upon unit death, again, still needs to be monitored to know when unit is dead to execute whatever kind of eventhandler it is.

there is no magic, its cause and effect.

maybe all units already have eventhandlers running anyway and we just get "acess" to them via the command addeventhandler.

units gets added into allDead array automatically without using eventhandlers, thus something is "watching" and "moving" when dead.

if above was true, then a waitUntil would just add to existing processes running increasing lag.

but im suspecting that if the eventhandlers is always running then the would probably be run in their own seperate space for max performance.

scripts run in another space etc..

would be very helpful if a dev or something could answer how a eventhandler works.

anyway, tnx for input guys.

[xeno 234]

An eventhandler only triggers when an event occurs.

Like for example the engine triggers the killed eventhandler only when an object gets killed.

A script with waitUntil {!alive something} does always run, it will check constantly (if the scripting engine allows it, each frame) if something is not alive.

Now what can happen is that the waitUntil script can be delayed several frames (even up to several seconds) if FPS are low or something else eats up

the time the scripting engine has each frame (since A2 there is a time limit for all scripts in each frame). This does not happen with code in eventhandlers.

Beside that, code in an eventhandler (doesn't matter which type of eventhandler) is not running as we call it in the scheduled environment

(scheduled = scripts executed with execVM or spawn). So it won't be delayed and run in the same frame the event is triggered (as long as you don't spawn or execVM from an eventhandler).

Edit: You won't notice much difference if you don't have much AI, not much demanding scripts running, and so on.

Xeno

Edited July 7, 2011 by Xeno

[demonized 20]

Thank you Xeno, that makes alot of sense.