Beiträge von Brandenburger

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!

    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.

    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

    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

    Neben weitreichenden Veränderungen zum heutigen Fahrplanwechsel im TKS (Teltow-Kleinmachnow-Stahnsdorf)-Netz gibt es auch eine neu aufgelegte Buslinie im Landkreis Potsdam-Mittelmark.


    Die Linie 613, welche bislang nur mehr oder weniger für Schülerfahrten benutzt wurde, verbindet nun neu die Orte Caputh - Michendorf - Saarmund und Potsdam direkt miteinander. Am neu angeschlossenen Saarmunder Bahnhof besteht dabei Anschluss zur Regionalbahn, mit direkter Verbindung zum Flughafen BER.


    In Caputh wurde die neue Linie präsentiert. Dafür wurde einem 2022er C2 Solo Hybrid eine passende Werbung für die Linie spendiert.


    PM-RB 183 (MB O530 C2 Ü - C2-Pack by Mx200, in der Realität C2 Solo Hybrid; Türkonfiguration jedoch 1-2) | Caputh-Potsdam

    Nachdem die Werbung für die Stadtlinie Bad Belzig auf den C2 K umgesetzt wurde, hat sie auch auf den Facelift Ks von regiobus, welche die Werbung für eine relativ kurze Zeit hatten, auch in OMSI Einzug gehalten.


    PM-RB 305 (MB O530 Facelift K, Bj. 2008 - privat) | BRT Berlin

    Das ist schön zu hören.

    Aber nochmal nachfragen muss ich leider zu der realen Anpassung an die BVG. Fasse ich das richtig auf, dass es nicht geplant ist, den BVG Fahrtbildschirm des Atrons real umzusetzen?

    Wird das Atron zumindest leicht nochmal scriptmäßig überarbeitet bzw. eher an den aktuelleren Stand angepasst? Ich denk da nur so ein paar Bugfixs, wie dass man tlw. einen schwarzen Bildschirm hatte, wenn man eine falsche Route eintippt, den falschen Button zum falschen Zeitpunkt drückt o.ä. und dass bei der BVG im Fahrtmenü nicht nur die letzte und die nächste Haltestelle angezeigt werden?

    Die Fehler gibt es ja seit dem BRT C2 und müsste dort eigentlich alles auch schon mehrmals von Usern gemeldet worden sein. Und eine kleine Anpassung an den aktuellen Stand fände ich sehr schön, dann ist es wenigstens nicht 1zu1, wie das BRT C2-Atron (abgesehen von der Version des kleinen Monitors). 🤔

    Säderik sowas ist schwierig umzusetzen, da OMSI pro Bus-Datei nur eine Passengercabin-Datei zulässt. Also entweder sitzen die Fahrgäste in der Luft bzw. falsch auf dem Sitz oder jeder Bus, der die Konferenzecke per setvar bekommt muss als Bus-Datei doppelt angelegt werden - beides unschön…

    Da bin ich leider auch ein bisschen ratlos. Vom Troubleshooting-Gedanken her würde ich so ran gehen, mal auszutesten, ob er ein "N" bspw. alleine darstellen kann. Dafür einfach mal im Script alles rauslöschen (Backup nicht vergessen^^) und einfach "N" (S.$.dieVariableDieFürDieLinieAnDerPositionVerwendetWird) austesten.

    Ich glaube beim Originalwert von 700 ist 300 bis 1000 okay. Ich sehe da keinen großen Sinn dahinter, noch größere oder kleinere Werte auszuprobieren.


    Wenn ich dazu komme, kann ich mir die HH-DFI mal anschauen und selber testen. 🤔

    Bei mir trat der Fehler auch bei der Erstellung von DFIs auf, wenn die von OMSI erstellte Schrift (vorstellbar als Bild) zu breit für das Textfeld war, dass er dann einfach protestiert hat und nichts mehr in dem Textfeld angezeigt hat. Probier mal in der sco-Datei den Bereich für die Linie bei der Texttexture enger zu machen. Dann passt mehr Text rauf und X, N, usw. sollten auch dargestellt werden können.

    Eigentlich egal, solange sie in der Bus-Datei aufgerufen wird. Am Sinnvollsten ist es aber, die Varlist und Stringvarlist zu benutzen, von dem Script wo der Aufruffehler durch Nicht-Definition auftritt oder bspw einfach für alle die VDV Varlist/Stringvarlist.

    Wie ich bereits schrieb, ist die Verspätungslage, etc. immer Sache der Einstellungen. Auf einem NE21/22 fahren realistisch gesehen nicht sehr viele Menschen mit und das stell ich mir dann auch so ein.

    Fahrzeiten sind ja immer so ein Thema. Für den Einen ist es zu knapp, für den Anderen zu viel. Allgemein finde ich aber, dass ihr die Fahrzeiten auf Ahlheim 4 gut hinbekommen habt. Tlw. ein bisschen zu viel Zeit, tlw. genau richtig und tlw. ein bisschen zu wenig. Aber genau so ist es in der Realität auch oft.

    Nachdem das Beispiel NE21/22 genannt wurde - das ist für mich ein Beispiel der perfekten Fahrzeiten. Auf der gesamten Linie steigen bei mir vielleicht 5-10 Fahrgäste ein, durch die relativ engen Zeiten kann man super entspannt durchrollen. Hätte man mehr Zeit, würde man an jeder 3. Haltestelle stehen und Zeit abwarten müssen. Und ab 4-5 Haltestellen vor Eichenhöhe Bf hat man dann meistens wieder ganz gut Zeit, sodass man sich wieder ein bisschen Verfrühung (für den Feierabend ;)) einfahren kann. Besser geht es nicht!

    Bitte Logfile lesen und Fehler abarbeiten.


    1) Fehlende Texturen ergänzen (bspw. „Did not find texture file "su18_ii_glas_misc.dds"!“

    2) Fehlende Variablen ergänzen (bspw. „Fehler: im Befehl "(L.L.Vehicletype)"“ - alles mit L.L. und S.L. muss in eine Varlist, alles mit L.$. und S.$. in eine Stringvarlist.)


    3) Genauere Beschreibung der Probleme, Screenshots. Dadurch lassen sich Probleme besser erkennen und dir helfen.

    4) Genau erklären, welche du Scripts du eingefügt hast.