Beiträge von DerGrafikfehler

Ein if-else if ist in der Omsi-Programmiersprache nicht möglich. Am enfachsten wäre es wahrscheinlich, wenn du z.B. das Register 6 auf den Wert 1 setzt, wenn eine entsprechende Hofdatei ausgewählt ist und dann dieses abfragst:

{macro:auftragsschild_frame}
    0 16
    (L.$.Yard) "Ahlheim 5" $= {if} "Auftragsschild\Auftragsschild_AVG.dds" (S.$.auftragsschild) 1 s6 {endif}
    (L.$.Yard) "Ahlheim_Laurenzbach_Updated" $= {if} "Auftragsschild\Auftragsschild_SLZ.dds" (S.$.auftragsschild) 1 s6 {endif}
    (L.$.Yard) "Gerolstein_2025" $= {if} "Auftragsschild\Auftragsschild_VBK.dds" (S.$.auftragsschild) 1 s6 {endif}
    (L.$.Yard) "Waldhofen 2013" $= {if} "Auftragsschild\Auftragsschild_BWh.dds" (S.$.auftragsschild) 1 s6 {endif}
    l6 !    
    {if}
            "Auftragsschild\Auftragsschild_Wolf.dds" (S.$.auftragsschild)
    {endif}
{end}

Noch einfacher wäre es natürlich, einen der globalen Strings in der Hofdatei zu nutzen. Wenn der leer ist, kann die Standardtextur verwendet werden, sonst eben die aus der Hof. Wäre dann auch etwas einfacher in der Handhabung, weil dafür das Script nicht immer angepasst werden muss.

Die Materials sind in Blender so ausgelegt, dass die Texturen von Omsi dann aus einem Unterverzeichnis geladen werden. Damit kommt Blender aber beim Export nicht klar, wodurch die Materials "falsch" exportiert werden und der verlängerte Dateipfad fehlt. Du musst entweder den Textur-Unterordner überall rausnehmen (in der model.cfg bei allen Einträgen den Ordner vor dem Dateinamen entfernen) und die Texturen ins Haupt-Textur-Verzeichnis legen oder die einzelnen .x-Dateien bearbeiten und den richtigen Texturpfad nachtragen. Die .x-Dateien sind einfache Textdateien, können also "gefahrlos" bearbeitet werden.

Ja.

Für die K++ müssen die Wechselziele mit 20xxx aufwärts durchnummeriert werden. In deinem Fall also z.B. 20103, 21103, 22103.

Krefrath v3 | MB O530LE (Kajott-DLC, DGM Update WIP)

EvendPC_Scripttex_Index auf 3

EvendPC_ScripttexHell_Index auf 4

setzen.

Nein. Die Scripttextur-Einträge in der model.cfg sind von Omsi automatisch durchnummeriert. Der erste Eintrag hat den Index 0, der zweite Index 1 und so weiter.

Der Scripttextur-Eintrag muss, wie in der Anleitung beschrieben, in der model.cfg eingefügt werden.

Da ist die Auflösung der Scripttextur falsch. Ersetze die durch die im Paket enthaltenen.

Die Scripttextur-Indizes funktionieren nur dort, wo tatsächlich eine Scripttextur hinterlegt ist. Wenn in der model.cfg fünf Scripttexturen hinterlegt sind, wird kein Wert >4 funktionieren.

Funktioniert einwandfrei. Du darfst halt nicht Linie 10 Kurs 00 eingeben, sondern als Kurs 1000.

Richtig.

Ja. Die Umlauf-Einträge sind eigentlich Haltestellen. [infosystem_ivu] gibt es nicht. Die müssen unter [addbusstop_list] stehen.

(L.$.IAnz_Text_L2) "" $= durch 1 ersetzen.

Eine dedizierte Einstellung dafür ist nicht vorgesehen.

Du kannst aber den Inhalt der Zeile 191 durch die Zahl 1 ersetzen, dann wird nur noch Zeile 1 angezeigt.

Woran genau scheitert es? In der Hofdatei sind nur ein paar Routen drinnen, aber nichts für Umläufe.

Richtig.

Darauf kann ich keine Garantie geben. Aber die 29(!) MB große Logfile ist eigentlich Aussage genug, dass da ordentlich was schief läuft.

Wenn die Logfile so groß wird, ist es nicht unüblich, dass auch andere Probleme auftreten.

Omsi bitte über Steam reparieren. Der Standard-NL/NG dürfte ein Problem haben. Eventuell geht damit auch der Fehler weg.

Sind die Elemente aus der Ferne schwarz oder gar nicht vorhanden?

4GB-Patch installiert?

Zitat von 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.

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.