= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! Hier habe ich fix mal einen neuen Link hinterlegt. Hätte nicht gedacht, dass noch jemand sich für meine mittlerweile schon etwas in die Jahre gekommenen Repaints interessiert. VG
Moin, leider ist der neue Link bereits nicht mehr verfügbar, da, die Datei zumindest im kostenlosen Plan laut des Upload-Dienstes nach dem ersten Download automatisch gelöscht wird.
Vielleicht magst du es so hochladen, dass es dauerhaft verfügbar bleibt. Das geht auch direkt hier in der WebDisk. 
Oh stimmt, man kann ja mit dem Kilometerzähler arbeiten... 
Moin,
die Haltestellenweiterschaltung kannst du nicht direkt beeinflussen, die ist in OMSI fest programmiert, ab welcher Distanz auf die nächste Haltestelle geschaltet wird.
Was du allerdings im Drucker umsetzen kannst, ist eine Zeitverzögerung einzubauen, dass die Ansage also nicht sofort beim weiter schalten der Haltestelle abgespielt wird, sondern das Script beispielsweise noch 10 Sekunden wartet.
Das jedoch tatsächlich von der gefahrenen Distanz abhängig zu machen, ist jedoch in OMSI nicht so ohne weiteres direkt möglich, da das Scriptsystem dir nicht die Möglichkeit gibt, die Distanz zur vorherigen oder nächsten Haltestelle abzufragen.
Der Atron im Mx200-C2 schafft das zwar, allerdings wird das dort relativ kompliziert berechnet, indem die Fahrplanzeiten der letzten und nächsten Haltestelle (die man per Script abfragen kann), sowie aktuelle Uhrzeit und derzeitige Verspätung miteinander verglichen werden. Dadurch lässt sich ungefähr bestimmen, wo genau der Bus sich zwischen zwei Haltestellen gerade befindet (also wieviel "Prozent der Strecke") von A nach B abgeschlossen wurden. Wenn man das dann mit einem durchschnittlichen Haltestellenabstand multipliziert, kann man ungefähr berechnen, wieviele Meter die nächste Haltestelle entfernt ist. Damit bekomme ich aber auch nur einen ganz grob angenäherten Wert, der gerade bei sehr kleinen oder großen Haltestellenabständen auch ganz schön daneben liegen kann.
Ganz theoretisch: Wollte man es exakt machen, könnte man alle Haltestellenabstände im Druckerscript hardcoden. So würden tatsächlich alle Abstände exakt berechnet werden können, allerdings ist das natürlich 1.) ein extremer Aufwand und 2.) vermutlich auch nicht gerade performancefreundlich, wenn ein massiver Scriptblock, der eigentlich nur Daten speichert, geladen und ausgeführt werden muss.
Moin,
ich würde mal davon ausgehen, dass der Download leider nicht mehr so ohne weiteres auffindbar ist.
Zumindest habe ich durch Googeln auf die Schnelle auch keinen anderen gefunden.
Auf der Seite im MOF steht auch nichts weiteres zum Copyright der Repaints, eventuell steht in der Readme mehr. Im Zweifelsfall ist das erneute hochladen oder weiterschicken natürlich dennoch nicht erlaubt.
Mit viel Glück findet sich hier vielleicht jemand, der es noch auf der Platte rumliegen hat und einen Blick in die Readme werfen kann. Wenn das Copyright es erlaubt, könnte man es hier natürlich erneut teilen.
Dann versuche einfach, dein ganzes Repaint mit einer Deckkraft von bswp. 10% zu speichern.
Moin, die einfachste Lösung wäre, die Deckkraft des Busses weit runter zu stellen (auf z.B. 10-15%).
Wenn du sauber arbeiten willst, musst du mal im Repaintordner schauen, dort dürfte es irgendwo einen Templates-Ordner geben (ich habe den E-Citaro nicht, von daher hier am E-Citaro G des Linie20-Teils:
Die mit "AL" bezeichnete Datei ist die Alphamaske, sie legt fest, wo auf dem Bus wieviel Alphakanal (normalerweise für die Transparenz) vorliegt.
Die sauberste Lösung wäre also, genau diese Datei als Alphamaske über dein Repaint zu legen. Ich kann dir aber leider gerade nicht genau sagen, wie das in Paint.net am besten geht, da ich das Programm normalerweise nicht verwende.
Unterwegs auf den Linien 41/42 mit dem Subunternehmner...
Map: Region Südniedersachsen (WiP)
Bus: MB O530 Facelift
Matrix: BROSE 19x126 (by Lenn, WiP)
Für mich liest sich das so, als ob das Spiel selbst startet, allerdings deine ausgewählte Map nicht.
Naja, zumindest, wenn das oben gepostete Logfile vollständig ist, ist da eigentlich relativ offensichtlich, dass es beim Punkt "Download Internet Textures..." plötzlich abrupt endet.
Deine Antwort ist jetzt für mich gerade etwas widersprüchlich bzw. unverständlich:
ach und ich hab keine passagiere die auf der map spawnen auch keine autos aber mit der ai liste stimmt alles
Wie konntest du das feststellen, wenn dein OMSI garnicht startet? Oder wie soll ich das verstehen.
ich kann leider die itx dateien nicht löschen.
Wieso kannst du sie nicht löschen? Du kannst auch die Dateiendung sonst einfach von "itx" auf etwas anders ändern, sodass OMSI die Datei ebenfalls nicht mehr erkennt (z.B. "_itx").
Sofern dein oben gepostetes Logfile vollständig ist, bricht es nämlich bei dem Punkt "Downloading Internet Textures" ab. Das ist ein relativ typischer Fehler, der zum abstürzen, von OMSI bereits beim Start führt, wenn dort ein Problem vorliegt. Und da itx-Dateien die Dateien sind, in denen die Internettexturen definiert sind, hilft es normalerweise, genau diese außer Kraft zu setzen.
Moin,
ich tippe auf ein Problem mit Internettexturen bei dir.
Geh mal in deinem OMSI-HVZ in den Texture-Unterordner (also OMSI 2\Texture) und schau, ob du da irgendwelche *.itx-Dateien findest.
Falls ja, lösche sie testweise, bzw. schiebe sie irgendwo anders auf deine Festplatte als Backup, wo OMSI sie nicht mehr findet und versuche es dann nochmal.
Moin,
dir fehlt ein Haufen an Variablen. Bist du sicher, dass du die in der Readme angegebenen Voraussetzungen korrekt installiert hast:
Zitat von Readme.txt- MB Citaro Facelift von Helvete (mindestens) v1.4
- Morphis Soundpack für den Facelift (mindestens) v1.1
Da das jetzt in deiner Nachricht nicht ganz eindeutig rüber kam: Hast du in deinen Einstellungen mal geguckt, ob du alle Texturkanäle aktiviert hast (siehe zwei Posts weiter oben)
Du meinst hier (Nr. 4)?
Spätschicht im Nachtverkehr
Hab zugegeben auf den Fahrten stadtauswärts die Verfrühung auch nicht mehr abgewartet, weil eh absolut niemand um 2:30 groß mit wollte und konnte am Ende rund 5 Minuten früher nach Eichenhöhe einrücken. 
Auf einer Fahrt in der Gegenrichtung davor bin ich Nochem mit +11 richtung Hbf gefahren, weil ich meinen Bus noch reparieren musste, habe es aber trotzdem mit etwas zügig fahren locker geschafft, bis zum Hauptbahnhof die Verspätung auf ca. +3 runterzufahren. 
Ahlheim V4 | Nachtlinie NE8 | Setra S415NF
Alles anzeigen373 12:40:31 - - Error: Fehler: im Befehl "(M.L.language_update)" (vehicles\CW_IVECOBUS_LOWENTRY_FAMILY\\script\cockpit.osc) ist der Macroname ungültig!
374 12:40:31 - - Error: Fehler: im Befehl "(M.L.language_update)" (vehicles\CW_IVECOBUS_LOWENTRY_FAMILY\\script\cockpit.osc) ist der Macroname ungültig!
375 12:40:37 - - Warning: vehicles\CW_IVECOBUS_LOWENTRY_FAMILY\model\00_li13_120_TFT.cfg, line 12808: Mesh with Ident zahltisch not found!
376 12:41:27 - - Error: Fehler: im Befehl "(M.L.Innenanzeige)" (vehicles\CW_IVECOBUS_LOWENTRY_FAMILY\\script\Mobitec_ICU602\icu602.osc) ist der Macroname ungültig!
377 12:41:29 - - Error: Fehler: im Befehl "(M.L.language_update)" (vehicles\CW_IVECOBUS_LOWENTRY_FAMILY\\script\cockpit.osc) ist der Macroname ungültig!
378 12:41:29 - - Error: Fehler: im Befehl "(M.L.language_update)" (vehicles\CW_IVECOBUS_LOWENTRY_FAMILY\\script\cockpit.osc) ist der Macroname ungültig!
379 12:41:29 - - Error: Fehler: im Befehl "(M.L.IBIS_frame)" (vehicles\CW_IVECOBUS_LOWENTRY_FAMILY\\script\IVECW_main_ICU_TFT.osc) ist der Macroname ungültig!
380 12:41:29 - - Error: Fehler: im Befehl "(M.L.IBIS_init)" (vehicles\CW_IVECOBUS_LOWENTRY_FAMILY\\script\IVECW_main_ICU_TFT.osc) ist der Macroname ungültig!
Du hast hier eine Reihe von Scriptfehlern, die darauf hindeuten, dass du mindestens eine Script-Datei nicht richtig eingebunden hast, da einige Macros nicht gefunden werden können.
Moin liebe OMSI-Gemeinde,
Dass im Zusammenhang mit Fahrzeugen oder Szenerieobjekten manchmal auf einem bestimmten Mesh eine statische Textur nicht ausreicht, sondern es stattdessen notwendig wird, während des Spiels zwischen verschiedenen Texturen zu wechseln, ist erstmal nichts besonderes und findet häufig Verwendung (man denke z.B. an Repaints bei Bussen, Fahrscheindrucker mit verschiedenen Menüs oder Haltestellenwerbungen bzw. seperate Werbetafeln, gerade bei letzterem soll oft auch eine zufällige Textur gewählt werden).
Gerade weil das ein relativ triviales Problem ist, biete OMSI gleich mehrere Möglichkeiten an, einen solchen Texturtausch umzusetzen, zwei davon sind (würde ich mal sagen) relativ weit verbreitet und bekannt, allerdings gibt es noch eine dritte Möglichkeit, die scheinbar in der OMSI-Community bisher noch kaum Verwendung findet, die ich deshalb hier nun einmal kurz vorstellen möchte. - Vielleicht gibt es hier den ein oder anderen der das Prinzip schon kennt, in meinem ganzen OMSI-Verzeichnis habe ich jedoch keinerlei Objekte und Fahrzeuge finden können, die es verwenden - mit Ausnahme des Spandauer Doppeldeckers von Marcel eben - dort wird es verwendet, um die Rollbandtexturen durchzuwechseln.
Bevor ich jetzt damit anfange, vielleicht nochmal eine ganz kurze Übersicht über die anderen Möglichkeiten:
Die mMn. simpelste und am einfachsten zu verstehende Möglichkeit ist die Verwendung des [matl_freetex]-Befehls, damit können wir einfach eine auf einem Mesh bestehende Textur als Variabel definieren und mit einer Stringvariable verbinden, die Stringvariable kann dann während des Spiels beliebig von einem Script verändert werden und somit sehr einfach die Textur durchgetauscht werden. [matl_freetex] findet vor allem bei Fahrscheindruckern Anwendung, um die Bildschrimtexturen (=Menüs) durchzuschalten - je nach dem, was gerade angezeigt werden soll. Der Vorteil hier ist, dass man sehr flexibel ist, da man im Script in die jeweilige Variable quasi alles eintragen kann, weshalb es vor allem praktisch ist, wenn man aus einem Pool von sehr vielen (teilweise in Unterordnern sortierten) Texturen auswählen muss. Allerdings ist die Gefahr auch groß, versehentlich eine Textur zuzuweisen, die garnicht existiert, was im Spiel dann natürlich unschön aussieht. Außerdem ist es mit Freetex ziemlich aufwendig, eine Textur zufällig auszuwählen (man würde dafür ein recht komplexes Script mit vielen if-Blöcken benötigen - je nach dem, wie viele mögliche Texturen es gibt.
Daher gibt es noch eine andere, sehr bekannte, Möglichkeit:
Überlicherweise bei Fahrzeugen für das Repaint verwendet - aber auch bei Objekten (z.B. Werbetafeln) oft gesehen bzw. selbst früher immer dafür verwendet. Das "CTC"-System. Das Prinzip ist hier etwas anders: Man definiert separat in einer CTI-Datei ein Texturschema und legt die Datei in einem Ordner ab. Per Script kann dann über eine Index-Variable einfach entschieden werden, welches Farbschema aktiviert werden soll (für zufällige Texturen weist man dann eben eine zufällige Zahl in richtiger Range zu). Auch hier gibt es noch zwei weitere große Vorteile gegenüber dem Freetex-System (abgesehen von der einfacheren Umsetzbarkeit von Zufallstexturen):
Zum einen ist das ganz sehr einfach mit neuen Texturen erweiterbar: Ich kann einfach neue Texturen im Ordner ablegen, eine cti-Datei erzeugen, mein Repaint entsprechend eintragen und zack - fertig ist es. Keine Notwendigkeit, irgendwo im Script, der model.cfg oder dergl. etwas herum pfuschen zu müssen (gut bei Zufallstexturen müsste man ggf. noch die Range bei der Generierung der Zufallszahl anpassen, aber trotzdem: mit freetex wäre es um einiges einfacher).
Außerdem ist dies die einzige, elegante Möglichkeit, Texturwechsel als "Paket" zu definieren. Wir kennen das alle von Bus-Repaints. Wir haben eine Textur für den Wagenkasten, aber dann noch eine weitere für den Innenraum, Sitze nochmal separat usw. Dennoch sollen alle diese Texturen als ein Paket zu verstehen sein und gemeinsam ausgetauscht werden. Auch das geht hier natürlich sehr leicht.
Doch es gibt auch hier natürlich aus meiner Sicht auch einen Nachteil: Aufgrund der hohen Flexibilität ist die erstmalige "Einrichtung" einer CTC relativ aufwendig - gerade bei Objekten ist das konfigurieren in der sco, sowie das anlegen der Werbungen in cti-Dateien relativ viel Schreibarbeit für ein paar Tauschtexturen. Geht das nicht einfacher? Lange dachte ich "nein", aber doch es geht! Und wie? Das zeige ich jetzt:
Hier haben wir nun die neue "Entdeckung". Das Prinzip der texchanges ist ähnlich, wie bei CTC. Es wird eine separate Konfigurationsdatei angelegt, in der alle eintauschbaren Texturen eingetragen und mit einer Zahlvariable verbunden werden können. Über diese Variable kann dann einfach indexbasiert gesteuert werden, welche Textur verwendet werden soll. Im Gegensatz zu CTC können wir hier keine Texturpakete definieren, sondern immer nur einzelne Texturen tauschen, das ist aber in den meisten Fällen (z.B. bei Haltestellenwerbungen ja auch völlig ausreichend). Dafür ist das ganze doch um einiges kompakter und dennoch relativ Robust, da wir die Texturnamen dennoch separat in einer Datei festlegen und nicht (wie bei freetex) direkt in das Script schreiben müssen.
Als Beispiel und zu Demonstrationszwecken soll nun mal eine Werbeteafel mit vier verschiedenen Testwerbungen erstellt werden. (Bitte nicht über das Model beschweren, das ist hier ein spontaner "One Minute Craft" - es geht ja nur um das Prinzip.
Wichtig ist - wie eigentlich - immer, dass ich in Blender auf der Texturfläche, die später getauscht werden soll, eine entsprechende Textur zuweise, überlicherweise verwendet man für so etwas eine Dummy- oder "Leer"-Textur, in meinem Fall habe ich nun einfach die erste Werbung "Werbung_01.dds" zugewiesen. An sich ist das völlig egal. Ihr müsst nur genau wissen, welche Textur ihr in Blender zugewiesen habt.
Ansonsten habe ich einfach nur ein ganz normales Szenerieobjekt mit sco-Datei, model-Ordner mit o3d-Datei und texture-Ordner mit meinen Werbungen erstellt. In meinem Fall liegen alle Werbetexturen direkt im Texture-Ordner und heißen "Werbung_01.dds" bis "Werbung_04.dds". Natürlich kann man auch noch einen Unterordner verwenden, das geht genau so. Man muss dann eben nur die Texturpfade entsprechend anpassen.
Aber jetzt kommt die Magie:
Zusätzlich zur sco-Dateie erstelle ich noch eine cfg-Datei, die ich nun "Werbetafel_chtex.cfg" nenne. Auch hier gilt. Der Name ist aber völlig egal, ich muss ihn nur gleich richtig in der sco einbinden.
Diese cfg-Datei bekommt nun folgenden Inhalt:
[newtexchangemaster]
Werbung_01.dds
WerbungIndex
[entries]
4
texture\Werbung_01.dds
texture\Werbung_02.dds
texture\Werbung_03.dds
texture\Werbung_04.ddsWas bedeutet das jetzt? Oben unter [newtexchangemaster] wird als erstes eine Textur angegeben. Hier muss die jeweilige Textur eingetragen werden, die ihr in Blender auf das Objekt gemappt habt. D.h., wenn ihr eine Dummy-Textur verwendet habt, tragt ihr hier den Dummy ein, damit Blender weiß, welche Textur überhaupt auszutauschen ist (im Zweifelsfall kann man auch direkt die o3d in einem Texteditor öffnen, relativ weit unten, sind die Texturen im Klartext zu finden, die dort angegebene Textur muss exakt mit der eingetragenen übereinstimmen.
Darunter folgt eine Variable - in meinem Fall WerbungIndex - die dient als Steuervariable, mit der wir festlegen, welche der Unten angegebenen Texturen verwendet werden soll. (Natürlich tragen wir die nachher noch richtig in eine Varlist ein. ^^)
Tja, und dann folgt unter [entries] einfach nur eine Auflistung meiner "registrierten" Tauschtexturen. Zuerst die Anzahl der folgenden Einträge, dann die Einträge selbst. Wichtig ist hier, dass diese Pfade immer ausgehende von der cfg angegeben sein müssen. Ich könnte die Datei theoretisch auch genau so gut mit in den texture-Unterordner legen, dann müsste bei allen Einträgen das texture\-Präfix jedoch wegfallen.
Dann tragen wir diese cfg-Datei noch in der sco unter unserem Mesh-Eintrag, wiefolgt ein:
Auch hier nochmal als reminder: Wenn ich die cfg-Datei mit in den texture-Ordner gelegt hätte, müsste ich hier dann natürlich texture\Werbetafel_chtex.cfg schreiben.
Zuletzt müssen wir jetzt nur noch die Variable und ein Script definieren, das die Variable steuert. Dazu erzeuge ich eine Varlist und ein Script im script-Unterordner und trage beide Dateien auf dem bekannten Wege in der sco mit ein:
In der Varlist wird einfach nur die vorhin verwendete Variable WerbungIndex eintragen:
Im Script kann ich nun eine beliebige Logik programmieren, mit der die Variable einen Wert bekommt, der dann einfach als Index entscheidet, welche der Texturen in der cfg verwendet werden soll.
Da es sich in meinem Fall um eine Werbetafel handelt, die bei der Initialisierung einmal eine zufällige Textur bekommen soll, sieht mein Script wiefolgt aus:
Die 4 steht dort, weil wir insgesamt vier Werbungen haben und somit eine zufällige Zahl zwischen 0 und 3 ausgewählt wird (nullbasierter Index). Diese Zahl müsste ich also ändern, wenn ich weitere Werbungen hinzufüge. Allerdings könnte man ihn auch z.B. in eine constfile auslagern.
Das ist tatsächlich schon alles. Die Werbetafel funktioniert und erhält jedes mal eine zufällige Textur:
Man sieht also, das ganze ist deutlich einfacher und "schlanker" als ein CTC, aber dennoch auch robuster und somit ebenfalls in gewisser Weise einfacher als mit freetex zu arbeiten.
Übrigens. Es ist ohne Probleme möglich, in einer chtex.cfg-Datei auch mehrere [newtexchangemaster]-Einträge mit jeweils eigenen Entries einzutragen, wenn man verschiedene Variablen verwendet, kann man dann auch mehrere Tauschtexturen separat voneinander umsetzen.
Ich empfehle dazu nochmal einen Blick in die folgende Datei aus der OMSI-Basisinstallation: OMSI 2\Vehicles\Anzeigen\Rollband_SD79\chtex_rollband.cfg
Ich hoffe, das hilft einigen weiter. Es ist - aus meiner Sicht - gerade für Werbetafeln oder Haltestellenhäuser wirklich eine viel einfachere Möglichkeit, Tauschtexturen umzusetzen und es funktioniert bei Objekten genau wie bei Fahrzeugen.
Als Referenz findet ihr auch nochmal meine komplette Werbetafel im Anhang als Download zum angucken und nachvollziehen.
Ah stimmt, man sollte mal paar Posts darüber lesen. 
Was mir spontan als einziges noch einfallen würde wäre, dass das irgendwie komisch in der Situationsdatei steht. TrainFW hast du mal eine komplett neue Situation (Karte ohne Busse laden) probiert und nicht die letzte Situation wieder neu geladen?
Anhand der Logfile-Meldung 241 17:10:20 - - Error: 'IVU_freier_Port_11' ist kein gültiger Gleitkommawert: AMUAV.CNAVO.MV.E würde ich eher vermuten, dass der (durchaus korrekte Variablenname "IVU_freier_Port_11" in einer anderen Datei, z.B. der Model.cfg an einer Stelle eingetragen wurde, an der keine Variable erwartet wird und verarbeitet werden kann, sonden tatsächlich ein konstanter Zahlwert erwartet wird.
Würde die Variable nicht definiert, aber im Script verwendet werden, wäre die Fehlermeldung eher so etwas, wie Fehler im Befehl (L.$.IVU_freier_Port_11) - der Variablenname ist ungültig (habe gerade den genauen Wortlaut nicht so im Kopf ,:)
Stimmt, das würde sich vielleicht tatsächlich mal lohnen.
Ich muss das Ding eh aufmachen, weil ich noch eine Festplatte einbauen will.