Vorschläge zur Bedienung der Ereignisverwaltung (EV)

[Hawkeye]

Hallo @Neo, 

ich hätte zwei Wünsche für die Bedienung in der EV.

1. Wenn einer Bedingung eine Beschreibung hinzugefügt wird, dann überschreibt die Beschreibung die Bedingung.

Ist-Zustand: Die Bedingung wird angezeigt, wenn keine Beschreibung existiert.

 

Wird eine Beschreibung als Text eingefügt, wird nur noch die Beschreibung angezeigt, die Bedingung entfällt.

Deshalb die Frage, ob nicht beides untereinander angezeigt werden kann?  Also Bedingung und Beschreibung? 

2. Es ist sehr hilfreich zur Fehlersuche ins Ereignisprotokoll per print()- Anweisung Text einzugeben oder den Stand/Wert von Variablen abzufragen. Das ist z.Z. aber nur per Lua-Anweisung möglich.

Ist es daher machbar, eine EV-Anweisung unter dem Punkt "Kommentar" (der ja nur hilfreich in der EV-Ansicht ist),

einen zusätzlichen EV-Eintrag "Eintrag ins Ereignisprotokoll schreiben" hinzuzufügen?   

Der Vorteil dabei wäre, das bei den print()-Anweisungen, die im Ereignisprotokoll in "grün" dargestellt werden, per Doppelklick mit der linken Maustaste sich sofort auch das dazugehörige Ereignis in der EV öffnet. So wie bei "blauen"-Protokolleinträgen.    Bei den "schwarzen Einträgen ist das nicht der Fall. 

 

Viele Grüße,

Hawkeye

Bearbeitet 1. Oktober 2021 von Hawkeye
Ergänzung

[Neo]

Hallo Hawkeye,

vor 59 Minuten schrieb Hawkeye:

Deshalb die Frage, ob nicht beides untereinander angezeigt werden kann?  Also Bedingung und Beschreibung?

das wäre möglich, allerdings ist das so ein Punkt, den andere womöglich genau so wollen, weil sie mit der Kurzzusammenfassung nichts anfangen können. Du kannst die Kurzzusammenfassung ja selber mit in die Beschreibung aufnehmen.

vor einer Stunde schrieb Hawkeye:

einen zusätzlichen EV-Eintrag "Eintrag ins Ereignisprotokoll schreiben" hinzuzufügen?  

Ist dir die Möglichkeit bekannt, Lua-Skripte und die grafische EV zu mischen?

Damit kannst du beliebige print-Aufrufe einbinden. Eine eigene grafische Aktion ist womöglich etwas zu viel, weil dann auch wieder schnell Wünsche zur Formatierung usw. aufkommen und wir dann doch wieder bei Lua landen. Für die Überwachung von Variablen empfehle ich dir übrigens die Ereignisprotokollierung.

Viele Grüße,

Neo

[Hawkeye]

vor 20 Minuten schrieb Neo:

Ist dir die Möglichkeit bekannt, Lua-Skripte und die grafische EV zu mischen?

Hallo Neo, 

ja diese Möglichkeit nutzt ich auch ständig und sehr intensiv. Da arbeitet man aber in Lua, das schreckt viele Nutzer ab, hier ohne Fehler eine Anweisung einzugeben.

Mir geht es auch nicht um mich, sondern um diejenigen Nutzer, die sich mit Lua eben nicht beschäftigen wollen, oder können!

Hier könntest du ihnen eine Möglichkeit bieten, zumindest „Text“ per print() im Protokoll zur Verfügung zu stellen, ohne das sie sich mit Lua beschäftigen müssen. 

Das ist die Absicht des Vorschlages.

Viele Grüße

Hawkeye

 

[Andy]

Hallo Hawkeye,
die Fehler bei den Anweisungen können auch in der Grafik passieren. Die Parameter im print-Befehl sind so flexibel, dass alle Möglichkeiten mit der Grafik gar nicht erfaßt werden können. Alles andere sind dann wieder Einschränkungen, wo der nächste Wunsch nicht lange auf sich warten lassen wird. Sinnvoll wäre wohl ein Tutorial über den print-Befehl für Nichtprogrammierer, denen Syntaxbeschreibungen nicht geläufig sind. Also - ein sanftes Heranführen. Mehr als einen Einzeiler wird das Skript dann ja nicht benötigen. Damit verbunden sein könnte eine Erklärung, warum z.B. Fahrzeug in Lua vehicle heißt und äquivalente Objektzugriffe.

Gruß
  Andy

[HaNNoveraNer]

Interessanter fände ich eine "ANLAGE PAUSIEREN" in der EV mit der Möglichkeit fortzufahren.
Wie in einem richtigen Debugger.
Vielleicht könnte man dann auch einen Debug Mode ein/ausschalten, der bei "aus" die Pausierungen ignoriert.
Die Ereignisprotokollierung zeigt eigentlich schon alles an, was man dann an der Stelle wissen muß.

[Hawkeye]

Hallo @Neo,

zu diesem Thema noch ein Wunsch.  

Es gibt viele Animationen, die zur Ausführung eine gewisse Zeit in Anspruch nehmen.  Hier als Beispiel ein Pantograf einer Lok.

Nachdem eine Animation gestartet wurde, ("= true") werden andere Ereignisse weiter ausgeführt. Ist der Zeitbedarf für die Ausführung der Animation beendet, wird das Ende der Animation "=false" in das Ereignisprotokoll eingetragen. Also als Ereignis festgehalten. 

Hier würde ich mir die Möglichkeit wünschen, das dieses Ereignis eine Bedingung in der EV wird. z.B. "Animation beendet" oder "Animation gestoppt",  um nach/ durch Abschluss der Animation ein anderes Ereignis ausführen zu können.   z.B. an der roten Stelle.

Hallo @Andy,

vor 10 Minuten schrieb Andy:

Die Parameter im print-Befehl sind so flexibel, dass alle Möglichkeiten mit der Grafik gar nicht erfaßt werden können

Ist ja auch nur ein Vorschlag, den ich hier mal zur Diskussion stellen wollte.  Ob das für viele Nutzer interessant/ sinnvoll ist, oder ob Neo das umsetzt oder nicht, bleibt Ihm doch überlassen. Das Thema lautet doch Feature-Wünsche. Es geht doch darum Ideen auszutauschen, auch wenn viele davon letztlich dann doch nicht realisiert werden, oder gar nicht realisiert werden können.

Viele Grüße, 

Hawkeye 

[Goetz]

Hallo Hawkeye,

vor 8 Minuten schrieb Hawkeye:

um nach Abschluss der Animation ein anderes Ereignis ...

auszuführen, musst du die Zustandsänderung der Animation bitte selbst als Ereignis nutzen. Nicht als Bedingung.

 

Um Anfang vom Ende einer Animation zu unterscheiden, setze bitte im Objekt ein Flag, wenn du die Animation anstößt. 

Viele Grüße
Götz

[Hawkeye]

vor 2 Minuten schrieb Goetz:

Um Anfang vom Ende einer Animation zu unterscheiden, setze bitte im Objekt ein Flag, wenn du die Animation anstößt. 

Hallo Götz,

kannst du das bitte etwas genauer erklären. Was verstehst du unter einem „Flag“?

 

VG

Hawkeye

[Goetz]

Gerade eben schrieb Hawkeye:

Was verstehst du unter einem „Flag“?

Oh, Verzeihung Hawkeye.

Mit "flag" meinte ich eine boolsche Variable. Die kennt nur zwei Zustände: wahr oder falsch.
Kannst du als Objektvariable anlegen.

In der grafischen EV hast du für die Veränderung dieser Variable dann ein weißes Kästchen, welches du entweder aktivierst oder deaktivierst.

 

Und in der Bedingung prüfst du den Zustand um zu unterscheiden, ob die Zustandsänderung ein Start oder Stopp war.

 

Viele Grüße
Götz

 

[Hawkeye]

Hallo Götz,

ein interessanter Weg um das Ziel zu erreichen.

vor 8 Minuten schrieb Goetz:

Und in der Bedingung prüfst du den Zustand um zu unterscheiden, ob die Zustandsänderung ein Start oder Stopp war.

Dieser Umweg erreicht das Ziel mit den jetzigen Möglichkeiten in der EV. Werde ich mal testen.

Sollte Neo dieses Ereignis „Animation ….  =false“ aber gleich als Bedingung aufnehmen würde dieser Umweg entfallen. 
 

VG

Hawkeye

[Goetz]

Hallo @Hawkeye,

Grundsätzlich kann eine Bedingung nicht darauf warten, dass etwas eintritt.
In keiner Programmiersprache.

Eine Bedingung unterscheidet nur. Sie verzweigt. Je nachdem, wie eine Prüfung ausgefallen ist.

Du kannst nicht mitten im Ablauf darauf warten, dass eine Bedingung erfüllt wird.
Was du in deiner Beispiel EV versuchst, ist auch mit Änderungen nicht realisierbar.

Die Bedingung "Zeitpunkt überschritten" prüft einmalig, ob das jetzt wahr oder falsch ist. Ob die Zeit um ist oder nicht.
Sie wartet nicht, bis der Zeitpunkt überschritten ist. 

Viele Grüße
Götz

Bearbeitet 1. Oktober 2021 von Goetz
Ergänzungen

[HaNNoveraNer]

Es gibt ja Verzögerungen.
Man kann sich die Laufzeit einer Animation merken und die Verzögerung entsprechend einstellen.
Dann läuft der Scheduler weiter und niemand wartet.
Das funktioniert aber nur bei immer gleichem "Weg" der Animation, sollte aber für die meisten Fälle ausreichen.

Gruß
Thomas

 

Bearbeitet 1. Oktober 2021 von HaNNoveraNer

[Neo]

Hallo,

ein Flag für das Ereignis "Animation gestartet/gestoppt" wird nicht benötigt, das Ereignis selbst bringt bereits so ein Flag als Auslöser "Animationszustand" mit, womit du unterscheiden kannst, ob die Animation gestartet oder gestoppt wurde.

vor 1 Stunde schrieb HaNNoveraNer:

Interessanter fände ich eine "ANLAGE PAUSIEREN" in der EV mit der Möglichkeit fortzufahren.

Mitten in einem Ereignis zu pausieren wird schwierig, weil du danach den Zustand der Anlage verändern könntest. Wird das Ereignis anschließend wieder fortgeführt, könnten sich Ereignisparameter (Auslöser) geändert haben und es käme zum Crash (ein Debugger stoppt ja die gesamte Programmausführung).

Mit der Lua-Funktion "error" könntest du zumindest eine Pausierung der Anlage erreichen:

error("Pause")

Viele Grüße,

Neo

[Hawkeye]

vor 4 Minuten schrieb Goetz:

Grundsätzlich kann eine Bedingung nicht darauf warten, dass etwas eintritt.
In keiner Programmiersprache.

Hallo Götz, 

habe ich hier einen Denkfehler gemacht?

vor 3 Minuten schrieb Neo:

ein Flag für das Ereignis "Animation gestartet/gestoppt" wird nicht benötigt, das Ereignis selbst bringt bereits so ein Flag als Auslöser "Animationszustand" mit, womit du unterscheiden kannst, ob die Animation gestartet oder gestoppt wurde.

Oh, das ist interessant! Kannst du dafür bitte mal einfaches Beispiel geben, wo man das in der EV  findet, bzw. abfragt?

Wer suchet , der nicht immer findet.

Viele Grüße

Hawkeye

[Goetz]

 

Hallo Hawkeye,

vor 25 Minuten schrieb Hawkeye:

habe ich hier einen Denkfehler gemacht?

Ich fürchte, ja. 
Das wurde an deiner roten Unterstreichung von "Zeitpunkt überschritten" im Zusammenhang mit dem Text darüber deutlich.

 

vor 25 Minuten schrieb Hawkeye:

Wer suchet , der nicht immer findet.

Da ging es mir auch nicht besser als dir.

Deshalb hatte ich dir den Umweg vorgeschlagen.

Aber jetzt, wo ich wusste, dass es da ist, habe ich es auch gefunden:

Die Bedingung ist Eigenschaft besitzt den Wert

Dann wählst du über das Zahnrad den Auslöser aus.
Der steht automatisch auf "Objekt".
Du kannst stattdessen aus der Liste den "Animationszustand"der triggernden Animation zum Vergleich heranziehen.
Das ist ein Boolean und "true" bedeutet: Die Animation läuft.

Viele Grüße
Götz 

Bearbeitet 1. Oktober 2021 von Goetz
Ergänzungen

[HaNNoveraNer]

Kann man auch den Wert der Animation abfragen? 

Der liegt ja zwischen 0 und 1.

[Hawkeye]

Yeah, genau das habe ich gesucht! Perfekt! Dank an euch, @Neound @Goetz. 👏

 

Jetzt muß ich nur noch daran tüftelt, das der Animationszustand von einer bestimmten Animation als Auslöser für ein Folgeereignis definiert wird.

Aber das kriege ich dann wohl alleine hin. 
 

Danke und viele Grüße,

Hawkeye

Bearbeitet 1. Oktober 2021 von Hawkeye
Leerzeichen entfernt

[Goetz]

Hallo Thomas,

vor 5 Minuten schrieb HaNNoveraNer:

Kann man auch den Wert der Animation abfragen? 

Bisher nicht. 

Viele Grüße
Götz

[Hawkeye]

vor 7 Minuten schrieb HaNNoveraNer:

Der liegt ja zwischen 0 und 1.

Hallo Thomas, 

so wie ich das jetzt verstanden habe ist das ein Boolscher-Wert = true oder false. Also nicht 0 oder 1.

[HaNNoveraNer]

vor 8 Minuten schrieb Hawkeye:

Hallo Thomas, 

so wie ich das jetzt verstanden habe ist das ein Boolscher-Wert = true oder false. Also nicht 0 oder 1.

Das meine ich nicht. Ich meine den Zustand der Animation. Die Position wäre interessant. Dann weiß man wo sie gestoppt hat und kann darauf unterschiedlich reagieren. Beispielsweise bei einem Bagger an verschiedenen Orten. 

[Hawkeye]

vor 51 Minuten schrieb HaNNoveraNer:

Ich meine den Zustand der Animation.

Ok. Also wo die Animation gestoppt hat in einem Bereich zwischen 0 und 1? Meinst du das?

Mit V7 hat Neo doch die Möglichkeit geschaffen, eine Animation per Lua auch in einem bestimmten Bereich bzw. Von Anfang oder Ende bis zu einem gewissen Punkt abzuspielen. Den kannst du doch selbst in einer Variablen definieren. 

siehe unter Punkt:

• Abspielen von Animationen in einem benutzerdefinierten Bereich (per Lua)

hier die neue play-Anweisung in Lua:

Ich denke es sollte damit möglich sein, wenn du eh schon einen vorher definierten Punkt (z.B 0,5 oder 0,3) hast, an dem die Animation stoppen soll, dann kennst du doch den Wert zwischen 0 und 1, weil du ihn doch selbst vorgibst oder vorgeben kannst. Dann weiß du auch wo die Animation gestoppt hat. So denke ich mir das zumindest.

Ich bin aber noch nicht dazu gekommen, das auszuprobieren. Fahrstraßen zu testen war erstmal interessanter.

Viele Grüße

Hawkeye

 

Bearbeitet 1. Oktober 2021 von Hawkeye
Ergänzung

[BahnLand]

Hallo zusammen,

vor 11 Stunden schrieb Hawkeye:

Es ist sehr hilfreich zur Fehlersuche ins Ereignisprotokoll per print()- Anweisung Text einzugeben oder den Stand/Wert von Variablen abzufragen. Das ist z.Z. aber nur per Lua-Anweisung möglich.

Ich habe hier einmal ein paar Möglichkeiten zusammengestellt, wie man die Print()-Funktion (oder auch stattdessen "nur" ein benutzerdefiniertes Ereignis) in das Ereignisprotokoll einbauen kann. Hierzu gibt es auch eine kleine Beispiel-Anwendung:

Print-Ausgaben im Ereignisprotokoll.mbp

Die hier gezeigten Schalter erzeugen jeweils beim Umschalten eine oder mehrere Protokollzeilen im Ereignisprotokoll.

Die einfachste Möglichkeit ist die Eingabe der Print()-Anweisung direkt in Lua, die man aber auch in die Aktion "Script ausführen" einschalen kann.

Die Ausgabe ist dann die besagte "grüne Zeile".

Packt man diesen Lua-Print()-Aufruf in ein benutzerdefiniertes Ereignis (hier die Ereignisdefinition Print 0"), ...

... wird diese zusätzlich protokolliert.

Bei beiden Varianten ist jedoch der Text fest einprogrammiert und kann nicht variiert werden.

Das benutzerdefinierte Ereignis bietet jedoch die Möglichkeit, Parameter zu spezifizieren, ...

... über die man dann beim Aufruf verschiedene - insbesondere auch automatisch bestimmte - Werte übergeben kann.

Beim Protokoll stört aber meiner Ansicht nach die doppelte Ausgabe durch die Auflistung des Aufrufs (in blau) und der tatsächlich erfolgten Print-Ausgabe (in grün).

Ich habe deshalb auch eine Variante gebastelt, bei der das benutzerdefinierte Ereignis zwar Parameter für die Eingabe der zu protokollierenden Werte anbietet, aber keinen ausführbaren Inhalt - also insbesondere keine Print-Anweisung - besitzt.

Der Aufruf dieses Ereignisses unterscheidet sich (bis auf die Anzahl der Parameter) nicht von dem Beispiel davor.

Im Protokoll erscheinen nun aber nur noch die in blau protokollierten Aufrufe, welche dieselbe Information enthalten, die im vorausgehenden Beispiel nochmals in grün ausgegeben wurde. Trotz der fehlenden "hervorhebenden" grünen Farbe ziehe ich persönlich diese Variante vor, weil das Protokoll hierdurch zumindest auf mich übersichtlicher wirkt.

Viele Grüße
BahnLand

[Hawkeye]

Hallo @BahnLand,

ein schönes Beispiel, aber aus meiner Sicht schon zu weit gedacht.

Ich hatte eher an eine Hilfe in verschachtelten Bedingungen gedacht, da eine ausgeführte Bedingung im Ereignisprotokoll eben nicht dargestellt wird. 

Hier mal ein Beispiel:

für z.B. für Bedingung 2 nur der Text:

  

und im Protokoll erscheint, welche Bedingung ausgeführt wurde.

 

Daran kann man bei einer Fehlersuche schnell erkennen, ob die richtige Bedingung auch ausgeführt wurde.

Viele Grüße

Hawkeye