= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! Omsi an sich zieht bekanntlich genau gar keine Leistung, heißt die meisten Laptops schaffen Omsi heute ohne Probleme. Wirklich Spaß macht es aber erst mit einer halbwegs potenten CPU, also keine Pentium/Celeron/Atom/Athlon/Ax.
Ein halbwegs aktueller Core i3 ab der 11. Generation mit mindestens 8GB RAM und, je nach eigenem Ermessen, 500GB oder 1TB SSD-Speicher reicht schon vollkommen aus.
Das wird über die Constfile (Busordner\Scripts\DGM\matrix_constfile.txt). Dort muss unter Matrix_LinieZiel_kombiniert eine 0 stehen.
Es reicht schon, die Variable auszutuashcen, z.B. auf number.
Ein 13-Jähriger OMSI-Einsteiger ist heute so alt, wie das Spiel selbst.
Omsi würde ich sogar als noch älter einstufen. Die ersten Kommentare in den Scripts sind auf Anfang 2007 datiert. Also inzwischen über 17 Jahre.
Der Mainzer nutzt noch das Busfanat-Matrixscript aus Omsi 1-Zeiten. Das basiert auf Texttexturen. Heißt die Einträge dort müssen auch raus.
Fehler in Zeile 88 heißt übrigens Fehler in Zeile 89. Omsi zählt nullbasiert.
Knapp daneben. Ist der C2G aus dem Pack von Mx200 (Freeware).
Ändert am Gesamtbild aber relativ wenig. Der ist von den Proportionen her genauso komplett daneben.
Hab das ganze bei mir angetestet. An die Grafikbeschleuniger-Optional-Grafik von Omsi kommt die neue Engine in Sachen Performance logischerweise nicht ran, die Performance lässt aber dennoch zu wünschen übrig. Mit meinem R5 3600 und einer RX5500XT mit 8GB bekomme ich zwar wesentlich bessere Performance als mit der alten Engine (gut, ist nicht sonderlich schwer, wenn die alte Engine beim Laden gleich abstürzt und den Grafiktreiber killt), mit 10FPS um worst case (Rheinhausen) bis 60FPS im best case ist die Performance aber dennoch nicht sonderlich berauschend. Selbst Tramsim läuft auf höchsten Einstellungen mit an die 20FPS im worst case wesentlich besser. Da muss definitiv noch etwas gemacht werden.
Laderuckler habe ich keine gehabt, dafür hat das Laden der Assets sehr lange gedauert (Installiert auf einer Samsung 870 Evo 2TB), sodass dei Assets beim Überfliegen der Karte oft erst direkt vor der Kamera erscheinen.
Den gibt es so ähnlich im Bremer Lion's City (dort ohne IBIS Funktion) und im Ruhr Solaris
Sind beide EvendPC zweite Generation. Die sind optisch komplett anders als die erste.
Hast du die Fonts schon mal neu installiert?
Würde es dazu reichen, in der Hofdatei die Haltestellen umzubenennen
Ja.
Man kann es sogar so weit treiben, dass man für jede Linie einen eigenen Ansagen-Ordner hat. Dazu muss der Name den Dateipfad ab dem Ansagen-Ordner beinhalten:
Hat für die weitere Funktion der Hofdatei keine Auswirkungen.
Das funktioniert aber nur, wenn der Drucker/das IBIS sich die Ansagen/Routen aus der Hofdatei und nicht aus dem Fahrplan holt.
Edit: Eventuell auch eigene Routen für uhrzeitabhängige Umsteigemöglichkeiten. Beispielsweise fährt auf Rheinhausen die Linie 31 zwischen 19 und 5 Uhr auch Juliansberg an. Dabei könnte ich bei der Linie 51 zu diesen Uhrzeiten an der Endstation auch die Linie 31 ansagen lassen.
Das geht mit unterschiedlichen Routen je nach Tageszeit auch. Automatisch ändern lässt sich das nicht ohne erheblichen Aufwand, wäre aber irgendwie sicher möglich. Da müssten dann aber auch Feiertage und co. berücksichtigt werden, was dann nicht mehr wirklich funktioniert.
Also Du meinst ich müsste alle Buchstaben (bis auf die mit Unterlänge) vergrößern? Man könnte sie ja nach unten lang ziehen, das verzerrt aber glaub ich die Schrift. Für mich wirkts eher als hätte man die g's und y's einfach gestaucht. Wäre doch auch einfacher?
Eben nicht, weil die Schrift dann die falsche Höhe hat.
Ich finds faszinierend wie das Script bei nicht vorhandener Unterlänge das perfekt einpasst und auch die obere Zeile vergrößert. Ist wohl eine Wissenschaft für sich
Nicht wirklich. Man checkt einfach den Zieltext auf diese Buchstaben. Wenn vorhanden, dann andere Schrift.
Die Variable matrix_BoldMode steuert die Zieltext-Formatierung für die Zusätz *B und *K. Wenn du die Abschnitte für matrix_BoldMode=10 und matrix_BoldMode=11 bei den Font-Abschnitten für die 16er Höhe entfernst und die if-Abfrage für matrix_BoldMode=0 rausnimmst, passiert das auf der Seiten- und Heckmatrix nicht mehr, dafür aber auch nicht auf der Frontmatrix mit 16 Pixel Höhe.
Ich müsste dazu den Font entsprechend modden, aber glaube kaum dass es da ausreicht nur die betroffenen Buchstaben zu stauchen, oder? Und außerdem würde ich das wenn dann als Zusatzoption machen wollen. Oder hat es schon jemand entsprechend gemacht?
Die Font ist eine mit 8 Pixel Höhe ohne Unterlänge. Die im DGM-Pack verwendete ist 8 Pixel hoch mit Unterlänge. Heißt eigentlich müssten alle anderen Buchstaben vergrößert werden.
Das ganze als Setvar änderbar machen geht genauso wie bei den schmalen Liniennummern bzw. den erweiterten Schriftsätzen bei der Mobitec.
Ich blick auch den Font Aufruf iom Script nicht so ganz. Da finde ich nirgends 200x24 Fonts, höchstens 16x16 oder 16x24.
Die Zahlen geben die Breite der Buchstaben an, nicht die Auflösung. 16x24 hat 16 Pixel breite und 24 Pixel hohe Buchstaben.
Maximal Textur/2. Anders rum macht es keinen Sinn. Die Zahlen geben die Auflösung der Scripttextur an, also bei dir 165 Pixel breit und 164 Pixel hoch. Erfahrungsgemäß verträgt Omsi solche Auflösungen als Scripttextur überhaupt nicht, die muss im 2^n-Format sein, also z.B. 256x256 oder 256x512 Pixel.
Die Zahlen zwischen Scripttextur 0 und 1 brauchen an sich keine direkte Relation. Das Script nimmt den Inhalt der Scripttextur 0 und vergrößert ihn um einen fest eingestellten Faktor (auch bekannt als Integer-Scale). In deinem Fall also wahrscheinlich von 165x164 Pixeln auf 660x656 Pixel. Das ist viel kleiner als die 8200x8200 Pixel, die du eingestellt hast. Heißt dein Matrix-Inhalt wird irgendwo ganz klein links oben in der Ecke stehen, wo er faktisch nicht sichtbar ist.
1) Ohne Logfile und vollständigem model.cfg-Eintrag wird selbst die Glaskugel keine sinnvolle Antwort liefern können.
2)
Alles anzeigen###################
Script-Texturen:
###################
0: Krüger-Speicher
[scripttexture]
165
164
1: Krüger-Flipdot-Alphakanal
[scripttexture]
8246
8192
Die Zahlen ergeben für mich absolut keinen Sinn, weil die in keiner Relation zueinander stehen. Zudem... Wofür brauchst du 8200 Pixel in Höhe und Breite?
Ohne Anpassung des Skalierungsfaktors im Script kann das übrigens nichts werden, bei dem Unterschied in der Auflösung.
GU240 [...] , da dieses ja zumindest irgendwie ein HP500 darstellen soll.
Soll eins sein, ist aber keins. Genauso wie beim NL205/NG235.
Ich würde dies gerne in Omsi auch durchsetzen und meine erste Frage wäre vorab mal, wäre sowas möglich?
Mit keinem vertretbaren Aufwand.
Dabei würde das "via" wiederum stehen bleiben und die Haltestellen würden nach und nach gezeigt. Sprich, zuerst ist Spryndorf Rathaus dran, dann verschwindet diese Haltestelle und es erscheint Spryndorf Ost usw.
Würde sich mit Wechselzielen umsetzen lassen. Fraglich ist aber, welches Script aktuell unterschiedliche Strings für Vorne und Seite unterstützt...
Da ist der Fehler. Der Pfad für die Textur zeigt standardmäßig auf den Ordner Omsi 2\Texture. Heißt entweder den Lightmap-Pfad bei allen Einträgen in der model.cfg anpassen oder die Textur in den Ordner kopieren.
Liegt die Lightmap-Textur im Ordner Omsi 2/Texture?
Die matrix.osc ist zwei Mal eingetragen, ein Mal mit falschem Pfad. Die muss im jeden Fall über den anderen vier stehen deswegen die Fehler.
