Beiträge von Entdecker666

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!

  • Zieltext abgeschnitten

    Schön, dass es funktioniert! Mir fällt nur gerade auf, dass ich bei meiner Erklärung etwas verwirrt habe. Gut, dass du aber selber so schlau warst und es trotzdem hinbekommen hast. :"D
    Ich habe immer von Matrix_PrintBitmapPixelXX gesprochen, aber da ich bei der Matrix aus dem Solaris die Makros wohl alle umbenannt habe in die jeweilige Anzahl der übertragenen Pixel und nicht mehr den Exponent für die Benennung genutzt habe, würde das gar nicht wie in dem Code meines Beitrages beschrieben funktionieren. Hab da ausversehen mit einem anderen Skript erklärt, wo ich das nicht getan hatte. Aber da hat ja dann evtl. die lange Erklärung doch beim Verständnis geholfen.
    Ich hoffe, du hast jetzt nicht allzu lange rumgerätselt, sorry. :covereyes:

  • Zieltext abgeschnitten

    Ah, also das mit der Helligkeit ist darauf zurückzuführen, dass die Mipmaps der .dds-Dateien beim Vergrößern auf 240x32 wieder gelöscht oder zmd. wieder mit den automatisch erzeugten Mipmaps überschrieben wurden. Wenn du dir die Originaltexturen aus dem Solaris mal in GIMP (!) ansiehst, wirst du auf den unteren, kleineren Mipmaps sehen, dass irgendwann alles komplett weiß wird, was bei der modifizierten Textur nicht mehr so sein wird. Normalerweise wird bei den automatischen Mipmaps die Textur nämlich deutlich grauer und sieht somit deutlich weniger hell aus, da die Originaltextur in voller Größe einige dunklere Zwischenräume hat, die zusammen mit den eigentlichen Pixeln beim Verkleinern zu einem Grau heruntergemischt werden.
    In der Ferne werden dann die kleineren, dunklen Mipmaps angezeigt (Nah: Größte Mipmap, Fern: Kleinste Mipmap -> dazwischen werden jeweils die Abstufungen mit Übergang zur nächst größeren oder kleineren Mipmap angezeigt). Damit es nun aber nicht nur von Nahem, sondern auch in der Ferne noch schön hell und weiß aussieht, muss man die Mipmaps jeweils manuell aufhellen bzw. ab einem bestimmten Grad einfach komplett weiß färben in GIMP.

    Ich hänge dir hier mal die beiden .dds-Dateien an, also Lightmap und normale Textur, wo das ganze bereits für die 240x32-Matrix geschehen ist.


    Zum Thema Skript: Dort reicht es aus im Makro Matrix_SetCoords bei (L.L.Matrix_Modul) 0 = die Matrix_Width auf 240 zu setzen und am Ende des Skripts die in meinem letzten Post genannten Änderungen fürs Übertragen der ersten Skripttextur auf die zweite Skripttextur anzuwenden.

    Dazu kommen dann nur noch die Änderungen im Modell der vorderen Anzeige, das proportional breiter gemacht werden müsste, also mit dem Faktor 240 / 200 = 1,2 skaliert werden muss. Das Mapping der Textfläche muss dann nur noch um 40 "Pixel" bzw. eigentlich 320 Pixel weiter nach rechts erweitert werden. Der Hintergrund der Anzeige besteht aus einer geloopten Textur, die ebenfalls um 320 Pixel nach rechts erweitert werden muss.
    Das sollte es dann schon gewesen sein. ^^

  • Zieltext abgeschnitten

    Also ich weiß zwar nicht, was dich an meiner Anzeige aus dem 300er Solaris gestört hat, aber darum geht es ja hier nicht. ^^

    Das Problem liegt jedenfalls in zu wenigen Durchläufen beim pixelweisen Übertragen der ersten Skripttextur auf die zweite Skripttextur mit einer höheren Auflösung (doppelte Höhe+Breite soweit ich weiß). Diese werden im Skript unten im Makro Matrix_PrintBitmap festgelegt:



    Dabei wird geguckt, welche Anzeige (Vorne, Fahrerseite/Heck oder Linie) gerade übertragen werden soll. In jedem Fall wird aber die Pixelanzahl der Linienanzeige übertragen (siehe Zeile 3-6), was 48 x 26 = 1248 Pixel sind. Die Variable Matrix_Modul entscheidet nun, wie viele Pixel noch für die jeweilige Anzeige übertragen werden müssen. Beim Wert 0 handelt es sich um die Frontanzeige, also die Anzeige, die nun um 40x32 Pixel größer geworden ist. Übertragen werden aber nur 200 x 32 = 6400 Pixel, es müssten aber nach der Vergrößerung 240 x 32 = 7680 Pixel sein, es fehlen also 1280 Pixel. Das sind 5 und 1/3 Reihen, wie auch auf dem Bild von dir zu sehen.
    Die Makros Matrix_PrintBitmapPixelXX definieren nun also die Anzahl der Durchgänge. Dabei gilt: Anzahl = 2^XX. Somit muss man die Zahl 7680 nach Abzug der 1248 Pixel von der Linienanzeige in eine Binärzahl umwandeln. 6432 sieht in binärer Schreibweise so aus: 1100100100000. Nun muss man also von hinten an mit 0 beginnend (!) abzählen, wo eine 1 steht. Dabei kommen die Zahlen 5, 8, 11 und 12 raus. Nun einfach viermal das Makro Matrix_PrintBitmapPixelXX unter (L.L.Matrix_Modul) 0 = und dem darauffolgenden {if} mit den genannten Zahlen für XX aufrufen lassen und es wird genau die korrekte Anzahl an Durchgängen durchgeführt, sodass kein Pixel am Ende in OMSI auf der Anzeige fehlt (sofern ich keinen Rechenfehler hatte :D):


    Ich hätte die Lösung jetzt auch in zwei Sätzen ohne weitere Erläuterung schreiben können, aber ich wollte, dass man versteht, wie sich das ganze zusammensetzt. Evtl. findet es ja sogar jemand interessant, wer weiß. ^^

  • Matrix mit Laufschrift?

    Zitat von ToastMan

    Eine getrennte Schreibweise für Front- und Seitenmatrix ist bei der CoD-, DGM- und bei der C2 von Mx200-Matrix möglich. Da dürften es für die Frontanzeige String 1 und 2, sowie 13 und 14, und für die Seitenmatrix String 15 und 16 sein.

    Soweit ich das im Skript sehe, nutzt die Matrix im C2 nicht String 13 und 14, sondern 23 und 24. Evtl. ist es bei dir privat anders, aber in der öffentlichen Version ist das so.
    String 13 und 14 wird dafür aber bei meiner Matrix genutzt, die im GE20 enthalten ist. Diese kann im Übrigen auch Wechselziele (einfach die Zielnummer +20000, für weitere Wechselziele wieder +20000 usw.; in String 10 kann zudem jeweils die Wechselzeit zum nächsten Ziel festgelegt werden, falls die 4 Sekunden aus der Constfile nicht passen), unterschiedliche Schreibweise für Front- und Seitenmatrix mit den von dir genannten Strings, automatische Ersatzverkehr-Ziele (erste Zeile des Ziels ist "Ersatzverkehr" oder "Ersatzverkehr ->" ), Bitmaps und weitere spezielle Formatierungsoptionen wie andere Fonts und Sperrungswerte, wobei ich das bisher nirgends öffentlich gesagt und dokumentiert habe.

  • DerGrafikfehlers Bastelstube | Einbauanleitung: einzelner Bildschirm im New Lion's City

    Nunja, Macros sind ja Funktionen/Methoden im Skript und keine Variablen. Somit gehören in die Varlist auch nur Variablen und keine Macros.


    Aus deiner Logfile geht hervor, dass mehrere Skripte nicht geladen werden können:

    Code
    315 11:55:29 -  -     Warning:       Error while loading script file vehicles\MB_O530_Facelift_Modded\\script\Iscript\DGM\matrix.osc
316 11:55:29 -  -     Warning:       Error while loading script file vehicles\MB_O530_Facelift_Modded\\script\DGM\matrix_Bustec.oscanz.osc
317 11:55:29 -  -     Warning:       Error while loading script file vehicles\MB_O530_Facelift_Modded\\

    Ich würde daher nochmal überprüfen, ob jeweils Pfad und Dateiname bei den Skripts in der .bus-Datei korrekt sind. Außerdem wirkt es in Zeile 317 so, dass die Zahl in der .bus-Datei, die die Anzahl der Skriptdateien angibt, eine Zahl zu groß ist und er dadurch noch die Leerzeile als Skript-Pfad interpretiert.

    Wenn du das getan hast, musst du mal gucken, ob sich alle weiteren Fehler bereits behoben haben oder doch noch Macros fehlen.

  • Ibis Daten aus OMSI extrahieren?

    Die laststn.osn zu nutzen, erscheint mir wenig sinnvoll. Diese Datei hat den Nutzen, beim Zwischenspeichern der Situation den derzeitigen Zustand festzuhalten und diesen beim Laden der Situation wieder herzustellen. Das Speichern geschieht aber entweder nur per manuellem Befehl über STRG + S oder auch beim Anhalten, sofern dies in den Einstellungen aktiviert ist.

    Ich kenne den Zweck und Nutzen für das Schreiben in eine Textdatei zwar nicht, jedoch vermute ich mal, dass du damit eine Art Schnittstelle zwischen OMSI und einer anderen Software herstellen willst, die diese Daten ausließt und entweder an echte Geräte wie ein IBIS weiterleitet oder auf dem Bildschirm deines Computers anzeigt.

    Das Stichwort Plugin ist gar nicht mal so falsch, jedoch eben nicht im Zusammenhang mit der laststn.osn, sondern mit OMSI selbst. Wenn du wirklich einfach nur 1:1 die angezeigten Daten auf dem IBIS in OMSI auslesen möchtest, reicht ein recht simples OMSI-Plugin aus, das bestimmte Variablen aus OMSI empfängt und dann in eine Textdatei schreibt. Wie so häufig bei OMSI ist relativ eingeschränkt dokumentiert worden, wie genau ein Plugin für OMSI aussehen muss. In der OMSI-Wiki stehen aber zmd. grundlegende Infos für ein Plugin in Pascal bzw. Delphi. Bei C++ liegt offiziell kaum etwas vor. Aus eigener Erfahrung kann ich dazu aber sagen, dass es mit ein wenig Rumprobieren auch funktioniert. Ich habe mir ein Plugin geschrieben, das Haltewunsch und den Text der LCD-Innenanzeige direkt an ein Arduino-Board und die Anzeige schickt. Das erfordert evtl. mehr Aufwand, führt aber zu einer Übertragung und Anzeige in Echtzeit. Beim Zwischenspeichern in einer Textdatei wirst du immer mit Verzögerungen rechnen müssen.

  • Zieltext abgeschnitten

    Moin, also zunächst muss ich dich enttäuschen: Die Matritzen in den MAN NLC von Schröder Reisen und DB Regio Nord-Ost haben alle eine Auflösung von 240x32, also 40 Pixel mehr als die reguläre 200x32-Matrix, wie man sie von aktuell allen BVG-Fahrzeugen kennt.


    Ich vermute mal, du hast als Grundlage die Matrix aus dem MX C2 genommen. Es ist in jedem Fall nötig, im Script ein paar Änderungen vorzunehmen. Evtl. reicht es jedoch schon aus, die 200 durch eine 240 zu tauschen und es geht alles wie gewollt.


    Da die Textur 256 Pixel breit ist, brauchst du gar keine breitere Auflösung, denn 240 < 256. Also gehen auch 1024 weiterhin für die hochskalierte Textur. Übrigens mag OMSI gerne Texturen mit 2er-Potenzen als Auflösung. 1024x1024 geht, aber auch sowas wie 512x64, es müssen also nicht quadratische Texturen sein.

  • Situation Zwischenspeichern geht nicht mehr

    Hast du auch schon überprüft, ob nicht einfach die rote Meldung fehlt, sprich es eigentlich doch geht? Also hast du mal in den jeweiligen Map-Ordner geschaut und das Änderungsdatum der laststn.osn überprüft? Ich kann mir nämlich gut vorstellen, dass auch SHIFT + Z (rote Schrift durchschalten) in dem Moment nicht funktioniert hätte, da hat OMSI manchmal so seine Probleme.

  • Blender für Anfänger: Achsen vertauscht beim Export?

    Dieses Problem habe ich bei anderen Objekten auch schon gehabt. Aufgetreten ist es bei mir aber nur mit dem o3d-Exporter von Road-hog123, da scheint ein Fehler beim Export der Transform-Matrix zu sein. Evtl. nutzt du diesen auch. Falls ja, empfehle ich dir stattdessen den Im- und Exporter von space928, dort funktioniert zmd. bei mir alles reibungslos mit den Achsen und es wird so exportiert wie es auch importiert worden ist. Ich nutze übrigens Blender 3.5.

  • Scripttexture inklusive Farbe anzeigen lassen

    Das Problem wurde gelöst. Ich hatte die bmp-Texturen als 32-bit abgespeichert, es geht aber nur mit 24-bit, da hatte OMSI etwas Probleme beim Lesen. Aber viel entscheidender waren die ST-Macros.
    Zuvor war es vom Ablauf her:

    (M.V.STNewTex)

    (M.V.STLock)

    (M.V.STLoadTex)

    (M.V.STTextOut)

    (M.V.STUnlock)

    (M.V.STFilter)



    nun ist es:

    (M.V.STLoadTex)

    (M.V.STLock)

    (M.V.STTextOut)

    (M.V.STUnlock)

    (M.V.STFilter)

    (M.V.STLock)

    (M.V.STUnlock)

    (M.V.STFilter)



    Ob es nötig ist, die Textur doppelt zu filtern, weiß ich nicht, aber alles davor ist auf jeden Fall relevant und entscheidend. Es scheint so, also würde man (M.V.STLoadTex) sozusagen genau wie (M.V.STNewTex) benutzen. (M.V.STSetColor) ist übrigens auch nicht nötig gewesen.


    EDIT: Es ist zmd. in meinem Fall nicht nötig, am Ende noch ein zweites Mal rendern zu lassen, es reicht also (M.V.STUnlock)  und (M.V.STFilter) nach dem Beschreiben.

  • Scripttexture inklusive Farbe anzeigen lassen

    Der erste Teil ist ein Ausschnitt aus dem Frame. Die Funktion TFT_Monitor_Display_change setzt die Variable TFT_Monitor_texture. Falls nötig, kann ich auch das komplette Skript reinstellen.

  • Scripttexture inklusive Farbe anzeigen lassen

    Also das Konzept funktioniert, aber sowohl bei .tga, .png als auch bei .bmp als Texturformat für den Hintergrund kriege ich haufenweise Fehlermeldungen, die dazu führen, dass keine Skripttextur generiert wird und die FPS stark runtergehen. Wenn ich die Zeile auskommentiere, die den Hintergrund auf die Skripttextur malt, dann gibt es keine Fehlermeldungen. Auch der 4GB-Patch hilft da leider nicht. Kommt das evtl. jemandem bekannt vor oder weiß jemand, woran das liegen könnte? Die Textur ist übrigens 2048x1024 groß.

    Code
    257 18:21:08 -  -   Error:           Zugriffsverletzung bei Adresse 005D6BAB in Modul 'Omsi.exe'. Schreiben von Adresse 38BAAC60: CV.Calculate - J3 (vehicles\MB_C2_EN_BVG\MB_C2_E6_Solo_BVG.bus)
258 18:21:08 -  -   Error:           Systemfehler.  Code: 8.
Zur Verarbeitung dieses Befehls sind nicht genügend Speicherressourcen verfügbar: CV.Calculate - J3 (vehicles\MB_C2_EN_BVG\MB_C2_E6_Solo_BVG.bus

  • Scripttexture inklusive Farbe anzeigen lassen

    Naja, das frisst ja dann im Prinzip die kompletten Alpha-Werte weg, die Schrift sieht damit unschön aus. Habe es jetzt trotzdem mal in OMSI ausprobiert, aber von nahem sieht man es leider doch gut. Die einzigen Möglichkeiten sind für mich daher nur, wirklich alle Fonts mit Farbbitmap, die die richtige Schrift- und Hintergrundfarbe enthält, zu versehen und dann in OMSI ohne Vollfarbe schreiben zu lassen oder einfach [matl_transmap] beizubehalten.

  • Scripttexture inklusive Farbe anzeigen lassen

    Also bei mir funktioniert es nur zur Hälfte. Ich habe es mit einer .tga ausprobiert, dort wird alles genauso übernommen, auch die Transparenzen. Was jedoch Probleme macht, ist das Schreiben mit Text darauf. Dort wird einfach der neue Alpha-Wert auf die Skripttextur geschrieben, ohne dass der darunterliegende Pixel beachtet wird. Gibt es dafür auch eine Lösung? Falls das nicht zu verstehen war, hier mal ein Ausschnitt:

  • Scripttexture inklusive Farbe anzeigen lassen

    Wie hast du dieses Keyword denn herausgefunden? In der omsi.exe etwas gewühlt oder einfach rumprobiert? War ja bisher wohl nicht bekannt, dass das überhaupt existiert. :covereyes: Das sollte der Wiki definitiv hinzufügt werden.


    Aber mal sehen, ich werde es definitiv in nächster Zeit, evtl. heute, ausprobieren und dann sehen, wie es aussieht. Leider gibt es seit diesem Jahr nur noch die Innenanzeige mit Darkmode hier, also dunkler Hintergrund und helle Schrift. Aber vielleicht gibt es dort ja noch einen Wert, der die Darstellung verbessert.


    Danke auf jeden Fall für deine Erforschungen und das Teilen dieser! 8)

  • Matrix formatiert falsch

    Achso, ja beim STTextOut Makro steht an der Stelle für die Sperrung eine 0. Die Stelle für die Sperrung liegt eine Zeile über dem zu schreibenden Text, hier (L.$.Matrix_TerminusL1_write). Um nun den berechneten Sperrungswert auch auf die Skripttextur zu schreiben, muss l3 statt der 0 in der Zeile für die Sperrung stehen.

    So, jetzt müsste es aber klappen! 😄

  • Matrix formatiert falsch

    In dem Teil ist nirgendwo die Variable Matrix_Zeichenabstand gesetzt worden. Der Wert bleibt also bei 0, wenn auch nirgends anders die Variable gesetzt wird. Setz doch einfach mal eine 3 dort ein und schreib in der .oft eine 1 hin beim Abstand zwischen zwei Zeichen.

  • Matrix formatiert falsch

    Moin,

    was mir sofort auffällt ist, dass vor dem {if} durch 44 (S.L.Matrix_Xpos) die Zahl 44 in den Stack geladen wird, anstatt, wie gewollt, die verfügbare Breite mit der benötigten Textbreite zu vergleichen und somit eine 1 oder 0 auszugeben. Stattdessen wird hiermit also immer der selbe Wert geprüft, hier 44, der die Bedingung immer wahr werden lässt, also eine kleinere Schriftart wählt.

    Die Lösung ist wahrscheinlich ganz einfach. Einfach 44 (S.L.Matrix_Xpos) mit (L.$.Matrix_TerminusL1) (L.L.Font_Lawo_LED_32) s1 (M.V.TextLength) s2 l0 > vertauschen. Somit steht nun der ausgegebene Wert von 0 oder 1 wieder direkt vor dem {if}.

    Ich hoffe, das hat das Problem gelöst. :)

  • Funktion von "" "DEBUG" vor (M.V.GetBusstopString) in AFR4.osc vom BRT C2

    Hallo,

    aktuell probiere ich mich in das AFR4 Script vom BRT C2 reinzulesen, um dieses dann letztendlich stark zu modifizieren. Das meiste daraus habe ich bereits verstanden, jedoch gibt es noch eine Sache die ich nicht genau verstehe. Unzwar gibt es im Script die Zeile (L.L.Route) (M.V.GetRouteIndex) 0 "" "DEBUG" (M.V.GetRouteBusstopIdent) 0 (M.V.GetTTBusstopName) $= && und ich frage mich, was "" "DEBUG" für eine Funktion hat, denn eigentlich ist es meiner Meinung nach nicht nötig. Besonders ob das "DEBUG" ein internes OMSI Feature ist oder ob das nur im Script so festgelegt wurde. In einer anderen Zeile steht etwas ähnliches: (M.V.GetRouteIndex) s4 (M.V.GetBusstopCount) 1 - s5 l4 l5 (M.V.GetRouteBusstopIdent) (M.V.GetBusstopIndex) 3 "" "" (M.V.GetBusstopString) $=. Dort frage ich mich ebenfalls was "" "" hier macht, denn für (M.V.GetBusstopString) benötigt es dies nicht, sondern nur die 3 und den BusstopIndex von davor.

    Falls jemand eine Ahnung hat, würde ich mich sehr über eine Antwort freuen. :)