Nicht nachvollziehbares Verhalten durch unregelmäßige Verschiebung von Text beim Schreiben von Script-Texture

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!
  • Hallo zusammen,


    ich stehe vor einem Problem und weiß leider nicht mehr weiter und hoffe hier auf Schwarmintelligenz - vielleicht hat jemand noch eine Idee oder eine Debuggingmöglichkeit, die ich noch nicht ausprobiert habe im Kopf oder sogar einen Lösungsvorschlag.


    Szenario:

    Ich baue für das C2-Update an einer neuen AFR4-Software, soweit so gut, bis ich jetzt vor ein Problem gestoßen bin.


    Grundlegender Aufbau des Skripts: Ich führe im Frame-Teil des Scripts jeden Frame zuerst das Makro (M.L.AFR4_Modes_Frame) aus, darin läuft dann abhängig von der AFR4_Mode-Variable der entsprechende Modus. Anschließend läuft das (M.L.AFR4_Modes_Change)-Makro, dort wird, wenn die Variable (L.L.AFR4_Mode_Change) größer gleich null ist, der Modus gewechselt. Die AFR4_Mode-Variable wird angepasst, die Script-Texture durch den Befehl (M.V.STNewTex) geleert und das (M.L.AFR4_Modes_Frame)-Makro für die Ausführung des Modus läuft, sowie die Makros für die Buttons, den Text und die Uhrzeit oben rechts. Sofern kein Modus geändert werden soll, wird davon nichts ausgeführt. Damit realisiere ich einen sauberen Moduswechsel, inkl. saubere Anpassung der Script-Texturen.


    Problem:

    Problematisch ist die Ausführung der Menüs RBL_Umlauf und RBL_Fahrtauswahl_Master. Beide können auf unterschiedlichen Wegen ausgeführt werden und nur einer der beiden Wege ist problematisch.

    • Weg 1: AFR4 fährt hoch -> Anmeldung -> Anmeldung beendet -> durch Entfernen der SystemCard (Trigger) öffnet sich die Kurseingabe (Mode Makro) -> Kurs wird eingegeben -> Fahrtauswahl öffnet sich mit Klick auf Enter Button (Trigger)
    • Weg 2: AFR4 fährt hoch -> ... -> Kurs ist angenommen, Drucker ist eingerichtet -> Einstellungen -> Schicht-Menü -> Kursauswahl (um Kurseingabe zu öffnen) oder Fahrtauswahl (um Fahrtauswahl_Master zu öffnen), jeweils über Trigger ausgeführt >>> ! FEHLER !


    Der Fehler nun im Weg 2 ist, dass der Text beim Laden der Menüs RBL_Umlauf und RBL_Fahrtauswahl_Master in schätzungsweise 80% der Fällen nicht korrekt angezeigt wird, er wird auf der Script-Texture verschoben. Da die Script-Texture relativ groß sein muss, ist der Platz auch vorhanden - ich bekomme jedoch auch manchmal Zugriffsverletzungen, die ich darauf zurückführen würde, dass der Text über den Rand der Script-Texture verschoben werden sollte. Meistens ist der Text entweder um genau 1024px nach rechts verschoben (siehe Bild 1) oder in der Höhe ein bisschen nach oben oder unten verschoben.

    Das Interessante dabei ist, dass wenn ich in der Umlaufeingabe einen Kurs über die Tasten eingebe, dass dann der Text in 100% der Fälle wieder korrekt angezeigt wird - es wird das selbe Makro wie bei der Initialisierung des Modes ausgeführt. Bei der Fahrtauswahl ist das genauso, dort ist der Text wieder korrekt, sobald ich die Liste hoch- oder runterdrücke oder ich eine andere Fahrt auswähle (dadurch aktualisiert sich der Text und die selben Makros wie bei der Initialisierung werden ausgeführt).


    Erkenntnisse:

    1. Das selbe Makro jeweils zum Schreiben des Textes wird verwendet, der Menüwechsel wird ebenfalls immer über das selbe Makro initiiert. Lediglich das Setzen des Wertes für das neue Menü (Variable (S.L.AFR4_Mode_Change) für den nächsten Frame wird von einem Mode-Makro (Weg 1) und von einem Trigger (Weg 2) gesetzt. - Sollte meiner Einschätzung nach kein Problem darstellen, da das nur das Setzen der Variable ist.


    2. Doppelte Ausführung des Text-Makros (da es bei der Initialisierung nicht funktioniert, sobald der Text durch eine Interaktion neu geschrieben wird, aber ja schon) funktioniert ebenfalls nicht, eher im Gegenteil ich hatte noch häufiger Zugriffsverletzungen, mMn durch Verschieben des Textes auf außerhalb der Script-Texture.


    3. Es lässt sich kein Muster erkennen, wann das Initialisieren des Textes über die Buttons im Einstellungsmenü in den entsprechenden Menüs richtig funktioniert und wann nicht. Ungefähre Einschätzung, 20% der Versuche funktionieren fehlerfrei.


    4. Man könnte annehmen, dass im Script die Werte für das Schreiben auf die Script-Texture verändert werden. Ich habe bei Weg 1 und Weg 2 im Makro zum Schreiben (angehangen im Spoiler) geloggt, welche Werte für s0 (x-Beginn), s1 (x-Ende), s2 (y-Beginn) und s3 (y-Ende) entgegen genommen werden, um dann von (M.V.STTextOut) verarbeitet zu werden.

    Das Interessante ist, dass der Vermutung nicht so ist - bei beiden Wegen werden exakt die selben Werte (im Beispielbild manchmal ein bisschen anders durch unterschiedliche Textlängen und Zentrierung) an (M.V.STTextOut) übertragen.


    5. Ich habe den x-Wert (s0) angepasst, um zu sehen, ob der Text immer genau gleich verschoben wird. Ja ist der Fall (siehe Bild)


    Als Anhang noch die 3 Makros zum Schreiben des Textes für beide Menüs

    Code: ST Text RBL_Umlauf-Makro
    {macro:AFR4_ST_Text_RBL_Umlauf}
        (L.L.AFR4_var_Monitor) 0 = {if}   0 s0   0 s1   0 s2   0 s3 ""   (M.L.AFR4_ST_Font_Text) s4 {endif}
        (L.L.AFR4_var_Monitor) 1 = {if} 384 s0 560 s1 155 s2 189 s3 "23" (M.L.AFR4_ST_Font_Text) s4 {endif}
        2 s5 1 s6 (L.$.AFR4_TXT_Umlauf) (S.$.AFR4_ST_Text) (M.L.AFR4_ST_Write_Text)
        
        (L.L.AFR4_var_Monitor) 0 = {if} l0 s1   0 s0   0 s2   0 s3 {endif}
        (L.L.AFR4_var_Monitor) 1 = {if} l0 s1 384 s0 186 s2 187 s3 {endif}
        l7 255 0 0 0 (M.V.STSetColor)
        l7 l0 l2 l1 l3 (M.V.STDrawRect)
    {end}


    Sorry, für die komplizierte Erklärung des Codes. Leider ist der nicht so ganz einfach zu verstehen. Danke an Jeden, der versucht ihn oder das Problem zu verstehen. Ich hoffe ich habe soweit alles notwendige verständlich erklärt. Falls doch noch mehr Fragen auftauchen oder Code erklärt werden soll oder benötigt wird, kann ich den auch gerne erklären und/oder posten.


    Ansonsten bis auf das Problem funktioniert jede Logik und das gesamte System ohne mir bekannte Probleme, d.h. alle genannten Funktionen (oben), welche grundlegend von mir nur für die Erklärung des Problems genannt wurden, funktionieren.


    Ich freue mich, falls jemand eine Idee oder Ähnliches hat, ansonsten danke fürs Durchlesen und Gedanken machen.


    Viele Grüße,

    Brandenburger

  • Interessante Lösung, die Werte über solche Debug-Prints auszugeben. Wie genau bekommst du die aus Omsi raus?

    Zweite Frage: Warum genau brauchst du eine so große Scripttextur? In welchem Bezug auf verschiedene Bildschirme?

    Wäre auch das, was ich am ehesten empfehlen würde:

    x- und y-Koordinate für den Text abfragen (>=Bildschirmrand), wenn größer, dann in die Variable schreiben. So kann man schön "triggern", wenn man einen solchen Fehler nicht unbedingt einfach in der Laufzeit-Umgebung abfangen kann.


    Sonst probier mal, die x- und y-Koordinaten modulo Höhe/Breite der Bildschirmauflösung zu nehmen, bevor die Werte an STTextOut übergeben werden. So kannst du zumindest schauen, ob es an falschen Koordinaten liegt oder doch woanders.

  • Danke erstmal für deine Antwort! :)


    1. Ich bin natürlich zuerst davon ausgegangen, dass das Script die Werte (also statt x=214 dann x=214+1024=1238) selbst generiert und daher die Verschiebung kommt. Daher dachte ich mir, lasse ich mir l0 (x-Beginn), l1 (x-Ende), l2 (y-Beginn) und l3 (y-Ende) mal ausgeben und vergleiche diese Werte zwischen den zwei Wegen, wo der Text einmal korrekt und einmal verschoben angezeigt wird.

    Letztendlich sind es ganz normale Strings und ich habe sie über AUXI entnommen, geht aber natürlich auch einfach über Situation speichern und aus der laststn.osn ziehen.


    Das habe ich durch folgende Zeilen im Makro gelöst, wo der Text zum Schluss mittels STTextOut auf die ST geschrieben wird:

    Code: Makro "AFR4_ST_Write_Text"
    (L.$.devstr) "MAKRO: " $+ (L.$.AFR4_ST_Text) $+ " POSITION (0,1,2,3): " $+ l0 $IntToStr $+ "," $+ l1 $IntToStr $+ "," $+ l2 $IntToStr $+ "," $+ l3 $IntToStr $+ ".     " $+ (S.$.devstr)
    
    ...
    
    (L.$.devstr) "WRITE: " $+ (L.$.AFR4_ST_Text) $+ " POSITION (0,1,2,3): " $+ l0 $IntToStr $+ "," $+ l1 $IntToStr $+ "," $+ l2 $IntToStr $+ "," $+ l3 $IntToStr $+ ".     " $+ (S.$.devstr)
    
    l7 l0 l2 l4 2 0 (L.$.AFR4_ST_Text) (M.V.STTextOut)

    (Die zwei Ausgaben einmal names "MAKRO" und einmal "WRITE" habe ich daher gewählt, da dazwischen mit den Werten zwecks Positionierung noch gearbeitet wird.)


    2. Der AFR4 hat zwei Bildschirmvarianten, welche beide umgesetzt und per Klickspots tauschbar sein sollen. Der kleine Bildschirm hat eine Auflösung von 800x480 und der große Bildschirm eine Auflösung von meines Wissens 1200x764. Eine 2^n-ST muss dementsprechend 2048x1024 groß sein, auch wenn zumindest beim kleinen Bildschirm ein großer Teil davon nicht genutzt wird.


    Zu deinem Lösungsvorschlag, das habe ich mithilfe dieser Loggingfunktion bereits gesehen, dass es nicht an den Werten liegt.

    Auf folgendem Screenshot sieht man ja die entsprechenden Werte, welche direkt an STTextOut weitergegeben werden. Die Werte sind übereinstimmend und korrekt - trotzdem ist der Auszug links von einem erfolgreichen Versuch und der Auszug rechts von einem fehlgeschlagenen Versuch, bei dem der Text um 1024px auf der x-Achse verschoben wurde.

    Meiner Interpretation nach werden die Positionswerte also korrekt eine Zeile vor der STTextOut-Zeile wiedergegeben und damit doch dann auch korrekt an STTextOut weitergegeben, oder liege ich da mit meinen Gedanken falsch? Trotzdem findet eine Verschiebung statt und ich kann sie mir nicht erklären.

    306556-pasted-from-clipboard-png


    Viele Grüße!

    Brandenburger

  • 1200x764

    Ich würde eher auf 1280x720 oder 1280x800 tippen, weil standard-Auflösung. Eher sogar 1280x800.


    Die Protokollierung habe ich soweit auch verstanden. Mir war nicht bewusst, dass man sowas mit Auxi loggen kann.

    Dennoch würden für mich genau zwei Optionen als Fehlerquelle Sinn machen:

    -Text hat ein Zeichen vorangestellt, welches den ganzen Text um 1024px verschiebt (mehrere Leerzeichen?)

    -Koordinaten werden falsch an STTextOut übergeben


    Erster Fall ließe sich mit der lastsn.osn recht gut untersuchen (bzw. vielleicht auch mit Auxi), schaut aber eher nicht danach aus.

    Zweiterer Fall ließe sich - nebst Logging - auch mit der Modulo-Funktion abfangen. Wenn die x-Koordinate %1024 sich nicht (großartig) ändert und der Text immer angezeigt wird, kommt eine falsche Koordinate daher.

    Und den Fall kann man dann auch mit einer entsprechenden If-Abfrage abfangen und herausfinden, was ausgegeben wird.


    Ist im Wesentlichen nur Debugging ohne Auxi. Ich weiß leider nicht, wie sich das verhält in der Laufzeit. Wäre aber zumindest ein Ansatz.

  • Die Protokollierung habe ich soweit auch verstanden. Mir war nicht bewusst, dass man sowas mit Auxi loggen kann.

    AUXI kann einfach nur alle String- und Float-Variablen auslesen. Mehr ist das ja auch nicht.

    -Text hat ein Zeichen vorangestellt, welches den ganzen Text um 1024px verschiebt (mehrere Leerzeichen?)

    -Koordinaten werden falsch an STTextOut übergeben

    Beides kann der Screenshot meiner Meinung nach ausschließen, die Koordinaten sind dort entsprechend aufgeführt und der Text steht am Anfang in Anführungsstrichen geschrieben, dort sind keine Leerzeichen. Außerdem wird der Text komplett 1-zu-1 verschoben, bei der Benutzung mehrere Fonts aufgrund mehrerer Schriftgrößen sind auch die Leerzeichen unterschiedlich und dementsprechend würde das nicht als Gesamtpaket verschoben dargestellt werden. Bezüglich der Übergabe an STTextOut kann ich nur sagen, dass das Macro grundlegend funktioniert, aber irgendwie in diesem Anwendungsfall nicht - grundlegend wird es aber wohl richtig übergeben.


    Zweiterer Fall ließe sich - nebst Logging - auch mit der Modulo-Funktion abfangen. Wenn die x-Koordinate %1024 sich nicht (großartig) ändert und der Text immer angezeigt wird, kommt eine falsche Koordinate daher.

    Und den Fall kann man dann auch mit einer entsprechenden If-Abfrage abfangen und herausfinden, was ausgegeben wird.

    Danke für den Ansatz. Habe ich ausprobiert und folgende Logik (Zeilen 20, 21 und 22) in mein Write-Makro eingebaut:

    Leider hat es keinen Erfolg gebracht, auch die Variable "dev1024" ist bei 0 geblieben, d.h. dass es keine l0 größer 1000 gegeben hat.