= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! Kleiner Tipp: Wenn die Scripttexturen kein 2^n-Format haben, entstehen beim Situation neu laden sehr schnell verzogene Texturen, weil Omsi die nicht-2^n-Textur aufs 2^n-Format zu ziehen. Das schaut dann so aus:
Das Problem "behebt" sich quasi "von selbst", wenn wieder auf die Scripttextur geschrieben wird, sollte aber dennoch berücksichtigt werden.
Das ist bei dem Interface mit den vielen verschieden großen Schriften wohl eher suboptimal, da wäre die Option mit dem Zusammenfassen der Textfelder deutlich angenehmer in der Umsetzung. Bei dem Interface lässt sich das auch schön Zusammenfassen und Kombinieren, sodass pro Menü insgesamt nur etwa vier Texttexturen notwendig sind (inklusive den statischen Feldern oberhalb der gelben Linie).
Zu dem eTicket:
Da muss es definitiv eine Möglichkeit geben, das irgendwie abzufragen, sonst würde der Ticketscanner im New Flyer zum Beispiel nicht funktionieren. Schau dir vielleicht mal an, wie das dort gelöst ist. Alternativ... Kann der Scanner im eCitaro das vielleicht auch?
Die Umsetzung mit dieser Art String-Ports wird dir bei den meisten Innenanzeigen nicht viel bringen, weil:
-Für die ganzen TFTs braucht man eigentlich immer nochmal ein bisschen extra-Ansteuerung, weil sie mindestens eine Ansteuerung für die Tauschtexturen brauchen.
-Komplexere Innenanzeigen wie z.B. die aus dem NLC oder die von Chrizzly nutzen sowieso eigene Scripts, die sich nur die aktuelle Linie, Route (und vielleicht Ziel) aus den regulären IBIS-Variablen holen, ebenso wie ein Wechselsignal, dass weitergeschalten wurde. Um diese Scripts anzusteuern, brauchst du wieder eigene Scripts, die die Druckervariablen auf die Innenanzeigen-Variablen umsetzen.
Besser wäre es da, wenn du im Frame, egal ob Strom an oder aus, ein Innenanzeigen-Makro aufrufst (Name z.B. einfach Innenanzeige) und dieses Makro dann in eine eigene .osc packst. So wird der Einbau in unterschiedliche Busse einfacher, weil man nur eine zusätzliche Scriptdatei einbinden und nichts am eigentlichen Script ändern muss. Wenn man z.B. keine Innenanzeige haben will, kann man dann auch problemlos die zusätzliche Scriptdatei einfach nicht in die Busdatei eintragen, ohne größere Probleme zu verursachen. So habe ich das beim IBISController umgesetzt, läuft ohne Probleme.
Zum eigentlichen Drucker:
Das Modell gefällt mir sehr gut, die Textur für den Rahmen um den Bildschirm wirkt aber etwas hell (Könnte aber auch am Shader liegen). Mich stören die abgeschnittenen Haltestellennamen und die Liniennummer oben links schon ziemlich, da wäre es schön, wenn du die Textfelder noch etwas verlängern würdest und die Anzahl der möglichen Zeichen für die Strings im Script begrenzen würdest.
Appropos Textfelder: Wie viele Texttexturen nutzt der Drucker eigentlich?
Omsi lädt extrem viele kleine (ok, Ausnahme Texturen und vielleicht Sounds) Dateien, dementsprechend merkt man den Sprung von einer HDD zu einer SSD durchaus (Reaktionszeit, bei einer SSD maximal wenige Millisekunden, bei einer HDD durchaus schon mal 1-2s). Bei dem Sprung von einer offensichtlich-NVMe-SSD mit 2GB/s Lesen auf 7GB/s wirst du da kaum was spüren, die Ladezeiten verkürzen sich da eigentlich nicht mehr wirklich. Bei der Geschwindigkeit ist Omsi selber wahrscheinlich schon der Flaschenhals.
Der Eintrag ist dafür da, damit der entsprechende Code-Schnipsel zum Ansteuern oder Übersetzen für die Innenanzeige (liegen in den mitgelieferten zusätzlichen .oscs) ausgeführt wird. Die entsprechende .osc muss in der Busdatei unter der IBISController.osc eingetragen werden. Die Fehlermeldung kann aber ignoriert werden, dadurch entstehen keine Fehler, wenn man keine Innenanzeige nutzt.
Aktuell nein, mehr Linien-Sondersymbole kommen aber (irgendwann) noch, wenn ich die Motivation dafür finde.
Nächste Tour, diesmal etwas weniger ansprechendes Vehikel.
Städtedreieck21 | Bus ziemlich selbsterklärend.
Vor der Bescherung nochmal schnell die erste kurze Testfahrt machen. Natürlich stilecht mit lang, laut und langsam.
Städtedreieck21 | MB Citaro Irvine G CNG (etwas angepasst)
Hier:
Anstelle von Matrix_Sparrung steht bei dir vermutlich eine Zahl. Die gibt den maximalen Zeichenabstand in Pixeln (zusätzlich zu möglicherweise im Font fest eingebauten Abständen) an.
Hi, ich bekomme mit dem Conecto und dem Matrixpack aus dem Adventskalender die folgende Fehlermeldung in der Logfile:
Code
Error: command "(M.L.Matrix_CheckSymbol)" (vehicles\Citybus 628c 628g LF by Kajosoft\\script\DGM\matrix.osc) macro name is invalid!
Kannst ignorieren, das ist ein Überbleibsel aus dem Originalscript. den entsprechenden Teil plane ich, später wieder hinzuzufügen.
Die Matrizen möchten auch nicht in Haettenschweiler schildern bzw. bleibt es bei der Standard-Schriftart, wenn ich die Option auf dem Konfigurationszettel anklicke, egal, welche Matrix aktuell ausgewählt ist.
Die Hättenschweiler ist eine einzelne zusätzliche Schriftart, die sich zwischen der 13x9 und der 11x8 einordnet, wenn die entsprechende Setvar gesetzt ist. Logischerweise muss das Ziel auch die richtige Länge haben (bzw. bei der großen Mobitec das *B vorhanden sein), damit diese Font auch verwendet wird. Wenn der Text zu lang oder zu kurz ist, werden die anderen Fonts verwendet.
Das ist was ich weiß ein Bug in der Scriptversion, die beim Facelift/Citaro v5 mitgeliefert wird. Ohne einen entsprechenden Fix oder ein anderes IBIS kann man also keine Suffixe in diesen Bussen schildern, wenn die Liniennummer nicht gerade vom Ziel vorgegeben wird.
Braucht man Fonts unbedingt und wenn nicht, was passiert dann?
An sich nein, es funktioniert alles auch ohne Fonts. Die Fonts sind einfach die darzustellenden Schriftarten. Wenn die nicht vorhanden sind, bleiben die entsprechenden Textfelder einfach leer. Das lässt sich ans sich recht einfach fixen, dafür muss man im Prinzip nur Ersatz-Fonts finden. Im Falle des Druckers im Neoman Overhaul sollten die Fonts vom EvendPC2 aus dem Bremer Lion's City auch verwendbar sein, für das Problem mit der Matrix gibt es entsprechende Mods in der Filebase (und im Adventkalender).
Meinst du diese Karte im JPG Format im Dokumentations Ordner?
Doch, das ist die. Dort sind die ganzen Endstationen und die beiden Betriebshöfe eingezeichnet, an der kannst du dich orientieren.
Solche Hilfspfeile wie die in deinem Beispiel sind bis auf die ingame-Hilfspfeile allerdings nicht möglich/in der aktuellen Form nicht umsetzbar.
Reicht schon, die Dateipfade in der Busdatei zu korrigieren:
121 13:55:39 - - Warning: Error while loading file vehicles\NEOMAN_Overhaul\\Script\DGM\matrix_varlist.tx
122 13:55:41 - - Warning: Error while loading script file vehicles\NEOMAN_Overhaul\\Script\DGM\matrx_Aesys.oscSollten sein:
Der Pfad von der Constfile passt übrigens auch nicht.
Korrekt.
Da gibts einige. Boards, die man per Software konfigurieren kann, wie es beim Arcaze der Fall ist, kenne ich aber keine weiteren.
Umsetzbar wäre das unter anderem mit:
-Raspberry Pi Pico (3,3V, MicroPython oder CirquitPython, Arduino IDE)
-Arduino Leonardo/kompatible (5V, Arduino IDE)
-Arduino Nano RP2040 (3,3V, Arduino IDE, möglicherweise auch MicroPython oder CirquitPython)
-Teensy 3.x/4.x/LC (3,3V, Arduino IDE)
-Irgendein Joystick-USB-Board von Amazon/Ebay (3,3V/5V, nur über die Omsi-Controller-Einstellungen konfigurierbar, nicht weiter)
Bis auf die letzte Option können alle genannten Boards Maus, Joystick und Tastatur simulieren, teilweise sogar alle drei gemeinsam.
Der Kürzeste im Bunde.
Grundorf Umbau | Solaris Alpino 8.6
Hast du zufällig, kurz bevor das Problem angefangen hat, den Monitor/die Auflösung/Windows-Skalierung geändert? Habe diesbezüglisch schon gehört, dass sich das Ändern der Skalierung auf den Fahrplan auswirkt.