Verzögerung in Trigger einbauen

Willkommen in der OMSI-WebDisk!
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet: = Englisch [EN], = Deutsch [DE], = Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch!
  • Moin!
    Ich würde gerne in gewisse Tastatur-Trigger im Script eine Verzögerung einbauen. Der Trigger soll nachdem er ausgelöst wurd eine kurze Zeit nicht auf weiteres Drücken der Taste reagieren. Der Hintergrund wäre der, dass ich einige Funktionen gerne auf das Rädchen beim G29-Lenkrad lege (Scheibenwischer) oder bei meiner LaWi-Seitenkonsole auf das dortige Scrollrad (Lichtsteuerung oder Menü-Blättern). Beides ist leider so sensibel, dass da beim Betätigen ganz leicht zwei mal der Trigger ausgelöst wird. Das würde ich gerne nun verhindern.. Ich dachte da an die Trigger in den Scripten, denn ich wüsste nicht wie ich das zum Beispiel in JoyToKey lösen könnte. Zumindest um es auszuprobieren würd ich gerne eine Scriptseitige Lösung mal austesten.

  • Ich bin mir nicht 100% sicher, ob ich dein Problem bzw. Anliegen richtig verstanden habe. Du willst also eine Art "Timeout" haben, dass, wenn ein Trigger einmal ausgelöst wird, er für eine Zeitspanne von x Sekunden quasi blockiert und nicht ausgeführt wird, bis diese Zeitspanne eben um ist. Quasi ein Cooldown. Das kannst du relativ einfach mit etwas Gescripte lösen.

    Hier mal ein Beispiel:

    Folgende Variable (kannst sie letztendlich auch anders nennen) muss in die Varlist eingetragen werden:

    Code: varlist.txt
    dein_trigger_cooldownTimer

    Die gewünschte Cooldown-Zeit legst du am elegantesten in einer Constfile fest:

    Code: constfile.txt
    Hier die gewünschte Cooldown-Zeit (in Sekunden) für deinen Trigger eintragen (hier z.B. eine Sekunde)
    [const]
    dein_trigger_cooldownTime
    1

    Ich hoffe, das ist alles so verständlich, sonst frag' gerne nach.

  • Es muss irgendwo hin, wo der Code in jedem Frame ausgeführt wird.

    Auf Nummer sicher gehst du auf jeden Fall, wenn du das direkt in den {frame}-Bereich des Busses direkt irgendwo einfügst.

    Allerdings haben ja auch manche "Buskomponenten" eigene Frame-Makros, die aus dem {frame} heraus aufgerufen werden.

    Dort könntest du es theoretisch genau so eintragen. Das ist ziemlich Banane.

  • One can also forego the need for continuous / per-frame timing, by opportunistically, on a per-trigger-invocation basis, comparing GetTime against its value recorded during the previous (completed) trigger run (if any):

    Pros:

    • Might spare the odd microsecond due to not running on each and every frame (can be improved even further by splitting the if-statement into a bunch of if-elses -- to the further detriment of readability)
    • Generally speaking (beyond triggers), GetTime-based timing is advantageous when it comes to AI vehicles, as these might experience halts in script execution owing to despawns / respawns, hence being provided with no hard guarantee that their {frame} will indeed run uninterruptedly once per game frame

    Cons:

    • (Subjectively) less readable
    • Extra logic needed to account for the edge case of the OMSI situation getting saved / reloaded during a cooldown period
    • Harder for other code to observe the state of timing and take concurrent action (think e.g. inter-trigger coordination)
  • Es muss irgendwo hin, wo der Code in jedem Frame ausgeführt wird.

    Auf Nummer sicher gehst du auf jeden Fall, wenn du das direkt in den {frame}-Bereich des Busses direkt irgendwo einfügst.

    Allerdings haben ja auch manche "Buskomponenten" eigene Frame-Makros, die aus dem {frame} heraus aufgerufen werden.

    Dort könntest du es theoretisch genau so eintragen. Das ist ziemlich Banane.

    Gestern auf die schnelle noch ausprobiert im NLC beim Display, das ganze hatte aber dazu geführt dass das Display komplett den Dienst aufgegeben hatXD Ich hatte den frame in die MAN_Cockpit.osc integriert wo die Trigger sind. vielleicht war das das Problem.


    ist aber schon gaga ein Script zu ändern weil die Hardware eine Macke hatXD Aber sonst wüsste ich nicht wie und das Rädchen wäre unbenutzt.

  • Versuche, den Frame-Teil beim NLC z.B. in das Macro "cockpit_frame" einzufügen (Bei mir Zeile 1792 in der cockpit.osc).

    Einfach am Anfang (oder Ende) des Makros mit hinzufügen, in etwa so: