[...] Zudem verstehe ich X39s Abneigung gegenüber dem onEachFrame EH nicht, es wäre durchaus interessant zu erfahren auf welchen Erfahrungen/Wissen diese beruht, man lernt ja schliesslich nie aus. [...]
Du hast es dir bereits selbst beantwortet:
[...] dort war es aber auch noch so dass man um onEachFrame, onPlayerConnected, etc. besser einen grossen Bogen gemacht hat, da sich diese EventHandler gegenseitig überschrieben. [...]
Die möglichkeit existiert noch immer
die funktionen machen nämlich nichts anderes als sich gegenseitig zu überschreiben und das macht das dingen generell gefährtlich (zudem ist die nutzung von onFooBar befehlen der nutzung von EventHandlern weit nach hinten zu stellen! EventHandler sind schlicht die bessere möglichkeit gerade weil ArmA hier die bessere kontrolle hat und im grunde so performance auch einsparen könnte (zumindest in der theorie))
zudem sind die onFooBar EHs schlicht weg relikte aus alter zeit sind die nur wegen der abwertskompatibilität noch nicht rausgeflogen sind und schon längst durch ordentliche native event handler (und nicht die eigenwillige scripted solution die man mit AddStackedEventHandler erreicht (die zudem auch noch einen zu großen SQF overhead hat)) ersetzt worden
[...] In einem vorherigen Post, schriebst Du noch:Das hörte sich (zumindest für mich) so an, als hättest Du dies bereits ausprobiert und wärst zu eben dem beschriebenen Ergebnis gekommen. [...]
sowas steht meist im wiki sodass man es nicht mehr selbst testen muss
[...] Also gehe ich recht in der Annahme, dass es sowohl mit addStackedEventHandler + onEachFrame funktioniert, als auch mit addMissionEventHandler + Draw3D und zwar ohne dass man die Funktion überlisten kann?[...]
korrekt
die preferierte methode sollte jedoch natives SQF sein und nicht eine SQF funktion die verhalten auf teufel komm raus erzwingt (wie es addStackedEventHandler macht)
greets
X39
