= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! Eine ams-Datei ist einfach eine ZIP-Datei mit "falscher" Dateiendung.
Du kannst im Dateiname also einfach das ".ams" durch ".zip" ersetzen und die Datei dann mit jedem handelsüblichen Archivprogramm öffnen. (Windows-Explorer, 7zip, WinRAR oder was du auch immer verwendest) 
Moin,
leider gibt es diese Möglichkeit nicht direkt. Du musst im Editor immer alle Objekte einzeln löschen.
Was du jedoch machen könntest, wäre, mit einem Suchen-und-ersetzen-Tool (ich persönlich empfehle FNR: https://findandreplace.io/download), die Hilfspfeile auf der ganzen Map durch andere (Dummy-)Objekte zu ersetzen. Somit sind sie im Editor möglicherweise leichter auffindbar und anklickbar.
Die Hilfspfeile selbst haben ja in dem Bezug die etwas nervige Eigenschaft, dass sie zum einen nur von einer Seite sichtbar sind und zum anderen durch die Eigentleuchtkraft sich beim Auswählen nicht färben. Dadurch kann man schnell einen übersehen oder versehentlich ein anderes Objekt löschen.
Das macht man sich beim vorherigen Ersetzen durch andere Objekte möglicherweise etwas einfacher.
Ich vermute, du hast das Simple Streets Addon nicht ordnungsgemäß installiert. Wirf dort nochmal ein Blick in die Readme. Du musst dort manuell Texturen in einen anderen Ordner kopieren.
Zum Script-Backend: Im Prinzip ist es fast noch etwas abstrakter:
Letztendlich kannst du jeder Phase eine beliebige Zahl zuweisen (0-12 sind eben allgemein verwendet und werden vom Kreuzungseditor so unterstützt, im Prinzip müsste man in der SCO aber jede beliebige Zahl eintragen können).
Die Ampelobjekte können dann in ihrem Script über die Variable TrafficLightPhase den aktuellen Wert einfach abfragen und entsprechend behandeln (heißt, eine bestimmte Lampe aktivieren).
Die mehreren Werte pro Phase dienen dann dazu, verschiedene Signalbilder zu aktivieren.
So könnte man z.B. ein "T-Signal" (Türen schließen) über eine zweite Rotphase definieren.
Das hieße dann 0 entspricht einfach "rot", 1 dann "Rot mit Türen schließen". Die normale rote Ampel (also der Querbalken) würde dann eben auf jeden Wert zwischen 0 und 2 anspringen, das T hingegen nur beim Wert 1.
Das funktioniert tatsächlich auch so.
Also, wie man es genau verwendet, ist dann tasächliche Sache der jeweiligen Ampelobjekte, die man verbaut bzw. wie diese die Phasen eben interpretieren (müsste man in Dokumentation oder entsprechende Scripte mal reinschauen).
Aber die allgemeine Konvention ist eben diese:
0-2: Rot
3-5: Gelb
6-8: Grün
9-11: wieder gelb
12: aus.
So gibt es pro "Farbe" drei mögliche Zustände, die man dann noch individuell untergliedern kann.
Allerdings muss man beachten, dass die KI eben nur bei den Werten 6-8 und >= 12 fährt und bei allen anderen stehen bleibt.
Das ist tatsächlich in OMSI auch so hardgecodet und nicht per Script oder so beeinflussbar.
Edit:
grade bei Marcel gefunden: Die DDR-Ampeln nutzen es z.B. leicht anders:
Was steht in deiner options.cfg unter [font_typewriter]?
Falls da etwas anderes steht, trag bitte mal Courier New unter dem Befehl ein. Das ist die Standardeinstellung
Du kannst mal versuchen, in den Eigenschaften von der omsi.exe bei der Option "Vollbildoptimierungen deaktivieren" das Häckchen aktivieren.
Ansonsten ist auch der Kompatibilitätsmodus für Windows 7 sehr empfehlenswert:
Bei Ahlheim V4 kann man außerdem durch den KI-Verkehr recht viel Performance rausholen (bzw. eben auch verschenken).
Standardmäßig nutzt die Map zum großen Teil den Facelift als KI-Bus. Der ist in der Masse dann doch recht inperformant, was zumindest bei mir gerade in den Bereichen der Kontenpunkte (Eichenhöhe, Hbf, Kranenburg, Rosental), wo viele Linien fahren, die FPS dann doch ganz schön in den Keller gezogen hat.
Ich habe jetzt aber eine AIList mit Spandau-MAN als KI. Damit läuft die Map bei mir einwandfrei.
Natürlich kann man auch andere performancefreundliche KI-Fahrzeuge verwenden.
Moin zusammen,
ich bin gerade dabei, mein Haltestellenschild mit einer Alpha-Fläche auszustatten, die sich über das Haltestellenschild legt, um eine Art "Ausgeblichenheit" (durch lang anhaltende Sonneneinstrahlung usw.) darzustellen.
Um dies möglichst dynamisch halten zu können und nicht 70 verschiedene SCO-Dateien zu benötigen, habe ich mich dazu entschieden, die Deckkraft dieser Fläche (und damit den Grad der Ausgeblichenheit) dynamisch per [alphascale] anzugeben. Das Vorgehen ist dann eigentlich recht simpel: Über eine Scriptvariable kann man im Editor über das "Beschriftung"-Fenster eine gewünschte Ausgeblichenheit zwischen 0 und 1 eingeben, ein kleine Script wandelt diesen String einmal in eine Zahl um und speichert sie in eine entsprechende Zahlenvariable, die dann mit alphascale die Deckkraft der Ausgeblichenheit bestimmt.
(Farbe und Form des "Ausbleichungsdings" bitte erstmal ignorieren, das ist bisher nur ein Prototype und irrelevant für mein "Problem")
Das Script nochmal ganz simpel:
{frame}
(L.L.init) !
{if}
'Ausgeblichenheit einmalig setzen und dann über "init" merken, damit es nicht in jedem Frame wieder ausgeführt wird (Performance)
(L.$.Ausgeblichenheit) $StrToFloat (S.L.Ausgeblichenheit)
1 (S.L.init)
{endif}
{end}Mein Haltestellenschild besteht aber nicht nur aus einem Objekt, sondern aus mehreren Einzelteilen, die im Editor modular zusammengebaut werden können (im Wesentlichen die große Haltestellentafel mit dem Haltestellennamen sowie zusätzlich Linieneinschübe). Diese werden alle per attach to an den Mast (der alleinstehend ein eigenes Objekt ist) geheftet.
Das sieht dann so aus:
Auch diese einzelnen Einschübe haben natürlich die Ausbleichungs-Mechanik, d.h. ebenfalls das Mesh und entsprechende Variablen. Tafel und Einschübe nutzen jedoch nicht die gleiche Stringvarlist, da sie verschiedene Beschriftungsstrings haben, allerdings heißt die "Ausbleichungsvariable" überall gleich.
Und jetzt kommt das überraschende: Wenn ich beim "ersten" Objekt, also der Tafel, einen beliebigen Wert eintrage und die Variable aber bei den Einschüben darunter leer lasse, scheint das oberste Objekt seinen Variablenwert die nachfolgenden zu vererben. In rot habe ich jeweils daneben geschrieben, welchen Wert die einzelnen Objekte bei der Ausbleichung eingetragen haben:
Allerdings lässt es sich scheinbar auch unter gewissen Kriterien überschreiben, dies wird dann auch nach "unten" hin weitergegeben:
Jedoch findet die Vererbung scheinbar nicht zwingend nur von "oben nach unten" (in der Reihenfolge der Objekt-IDs, also der Platzierungsreihenfolge) statt:
Objekt "3" scheint an Objekt "1" zu vererben, aber Nummer 2 nicht anzutasten, da es einen eigenen Wert hat:
Das ganze funktioniert sogar auch, wenn die Objekte garnicht per attach to das gleiche Elternobjekt haben. Diese beiden Dinger wurden vollständig separat nacheinander platziert:
Auch hier funktioniert die Vererbung in beide Richtungen, d.h. egal, welchem Objekt ich einen Wert gebe, das andere ohne Wert nimmt den des ersten an...
Ich frage mich, ob dieses Verhalten irgendwie bewusst in OMSI programmiert wurde bzw. ob das irgendjemandem schon bekannt ist oder vielleicht sogar aktiv genutzt wird oder dazu genaueres bekannt ist.
Grade diese Tatsache, dass die Vererbung scheinbar in beide "Richtungen" von den IDs her klappt, wirft bei mir dann doch Fragen auf, weil mir nicht klar ist, von wo ein Objekt seinen Wert im Zweifelsfall nimmt...
Scheinbar scheint das ganze auch nicht direkt am String-Wert zu liegen sondern eher der dahinterliegende Zahl-Wert vererbt zu werden, wenn dieser "-1" ist (?)
Die Funktion $StrToFloat parst laut Wiki den obersten Stringstack-Wert in einen Float bzw. gibt "-1" aus, wenn die Konvertierung fehlschlägt, z.B. weil der String keine gültige Zahl darstellt (was - denke ich mal, bei einem Leerstring der Fall ist).
Wenn ich jedoch folgende Prüfung in meinem Script hinzufüge, verhindere ich damit, dass eine "-1" ausgegeben wird und interpretiere somit jegliche ungültige oder leere Eingabe als "0":
{frame}
(L.L.init) !
{if}
(L.$.Ausgeblichenheit) $StrToFloat (S.L.Ausgeblichenheit)
'NEU: Interpretiere eine ungültige Eingabe als "0":
-1 = {if} 0 (S.L.Ausgeblichenheit) {endif}
1 (S.L.init)
{endif}
{end}Diese kleine Änderung sorgt jedoch nun dafür, dass die gesamte Vererbung nicht mehr funktioniert bzw. nicht mehr aktiv ist, daher meine Hypothese dass OMSI "-1" in einer Zahlvariable interpretiert als "ungesetzt, hol dir den Wert von woanders".
Wie gesagt, mich würde mal interessieren, ob es irgendeine Person in der OMSI-Community gibt, er dieses Verhalten bekannt ist und vielleicht mehr darüber weiß...
Edit/Nachtrag:
Ich habe grade, um es genauer zu verstehen, mir mal die Variablenwerte direkt auf das Objekt im Textfeld ausgeben lassen. Das führt zu der Erkenntnis:
Der Variablenwert selbst im Rahmen der Scriptsystems scheint nicht direkt vererbt/überschrieben zu werden, die Variable an sich ist und bleibt tatsächlich "-1". Jedoch scheint OMSI dann bei der Verarbeitung und Darstellung des alphascales (und vielleicht auch noch bei anderen Dingen) den Wert dann nicht zu verwenden, sondern ihn von woanders zu suchen.
In diesem Fall habe ich links verschiedene Werte eingetragen. Rechts bliebt die ganze Zeit leer, daher wird der String als "-1" eingelesen und angezeigt:
Nicht für für "-1", sondern jeden Wert unter 0 ist das Verhalten so:
Ungültige Werte über 1 (ergibt ja an sich auch keinen Sinn für eine Deckkraft) werden aber hingegen wie "1" behandelt:
Ah stimmt, das ergibt in der Tat schon einmal Sinn.
Danke für den Gedankengang 
Moin zusammen,
ich wollte mal an die erfahrenen Scripter und alle anderen hier in die Runde fragen, ob irgendjemand mir mal erklären kann oder überhaupt weiß, welchen Sinn die Script-Variable InUse hat bzw. wonach sie sich verhält.
Die Variable ist in allen Szenerieobjekten vordefiniert und ist für Skripte ReadOnly, man kann die also nur abfragen, aber nicht selber setzen.
Die Erklärung im alten Omsi-Wiki lautet wiefolgt:
ZitatIst das Objekt "aktiv"? Die Sporthallen sind bspw. nur an Schultagen vormittags "aktiv", sodass die Soundeffekte an diese Variable gekoppelt werden können - auf diese Weise wird verhindert, dass die Soundeffekte auch in den Ferien oder nachts zu hören sind.
Allerdings muss ich da doch gestehen, dass das für mich noch nicht so ganz einleuchtend ist. Was soll das denn genau heißen, ob ein Objekt "aktiv" ist bzw. wonach entscheidet sich das? Kann ich das als Objektbauer irgendwie beeinflussen?
Eine Theorie von mir war, dass das quasi mit dem NightMapMode zusammenhängt, dazu habe ich auch diesen Thread gefunden. Allerdings ist das für mich auch noch nicht wirklich aufschlussreich, zumal es zum Abfragen der Nightmap-Aktivität ja schon die VariableNightLightA gibt, also warum sollte es nochmal eine andere Variable für eigentlich das gleiche geben?
Vielleicht weiß da jemand mehr, was sich OMSI bei dieser InUse-Variable "denkt" und nach welchen Parametern sie aktiviert oder deaktiviert wird.... 
Leider ist der offizielle Download nicht mehr verfügbar. Die Domain existiert nicht mehr.
Ich habe auch grade mal im WebArchive geguckt. Dort findet man zwar die Download-Seite, aber die tatsächliche Download-Datei wurde auch dort nie gesichert.
Moin, das liegt an der Kodierung.
OMSI speichert die global.cfg-Datei in der UTF-16-Kodierung mit LE-BOM-Markierung.
Aus dem Screenshot wird nicht genau erkennbar, welchen Texteditor du verwendet hast, aber er scheint UTF-16 nicht zu kennen und zeigt die Datei stattdessen als UTF-8 an, was dazu führt, dass immer eine Lücke zwischen den Zeichen ist, weil (wie der Name schon vermuten lässt) UTF-8 nur 8 Bytes pro Zeichen verwendet, UTF-16 aber eben 16.
Ich persönlich empfehle Notepad++. Das kann auf jeden Fall die Kodierung richtig erkennen und sollte die Datei dann auch richtig anzeigen.
In deinem Screenshot startest du die Map mit "Letzten Stand der Karte laden". Hast du es auch, wenn du ohne Busse laden auswählst?
Ja, ist geplant, allerdings werden wir eigene (auch funktoinsfähige) Blitzerobjekte entwickeln.
Oh, da war ich wohl falsch informiert. Danke für die Klarstellung.
Ich habe das Spiel jetzt auch mal ein paar Runden gespielt und muss sagen: Es macht Spaß. Mir gefällt es sehr gut.
Ich bin kein absoluter U-Bahn-Experte, daher kann ich zum Realismus von Sounds, Steuerung, Physik usw. nicht all zu viel sagen, aber es wirkt auf mich stimmig. Dazu eine mMn. wirklich sehr gute Grafik.
Sicherlich ist der Realismusgrad nicht auf dem gleichen Level wie OMSI, aber da ist OMSI auch nach wie vor echt mehr oder wenige alleine.
Besonders gefällt mir, dass durchaus die verschiedenen Steuerungen der Züge wie in der Realität umgesetzt wurden und sich dadurch jedes Fahrzeug auf etwas anders steuert und verhält, sowie auch die teilweise unterschiedlichen "Abläufe" zwischen Hamburg und Berlin. (Berlin hat eine "zurückbleiben bitte"-Ansage, Hamburg nicht, die Berliner Fahrpläne sind ganz anders als die Hamburger usw.)
Also ich finde, man merkt einfach, dass hier nicht einfach nur eine neue Berliner Strecke mit neuen Fahrzeugen + teilweise Copy Paste gemacht wurde, sondern dass man wirklich das teilweise andere Berliner U-Bahn-System gut integriert und entwickelt hat. Das macht das Spiel sehr abwechslungsreich.
Mir fällt allerdings auch auf, dass sich das Bremsverhalten des DT5 in Hamburg extrem verändert hat. Die Bremsen wirken super schwach (auch im Vergleich zu den Berliner Fahrzeugen) und man muss sehr früh sehr stark Bremsen und passend zum stehen zu kommen. Allerdings kenne ich auch hier die Realität nicht bzw. kann es nicht einschätzen. Also gut möglich, dass die schwächeren Bremsen durchaus realistisch sind und das Update hier die Physik verbessert...
Und einen ganz kleinen aber unproblematischen Fehler habe ich noch gestern im DT5 gefunden. Der im Cockpit hängende Zettel mit den Haltestellencodes trägt noch das Subway-Sim-1 (bzw. -Hamburg)-Logo. 
Selbst probiert habe ich es nicht. Da ich aber weiß, dass Fernbus Simulator auf der Unreal Engine basiert, sage ich dennoch mal was dazu.
Vorweg: Rein technisch könnte das klappen, wichtig ist aber, dass du immer das Urheberrecht beachten musst. Niemand kann dir verbieten, die Daten privat auf deinem Rechner zu extrahieren und für private Zwecke zu verwenden. Sobald du es aber in irgendeiner Form weitergibst oder veröffentlichst (da können schon Screenshots reichen) greift natürlich das Copyright! Heißt: Du brauchst eine offizielle Genehmigung des Autors, in diesem Falle wahrscheinlich der Entwickler "TML Studios".
Aber jetzt zum rein Technischen:
Die Unreal Engine speichert alle Assets (Models, Texturen, Materialien, Sounds usw.) in sogenannten *.pak-Dateien. Das sind spezielle Archive, ähnlich wie man .zip oder .7z von allgemeinen Dateiarchiven kennt, ist pak ein spezielles Archiv-/Paketformat für Unreal-Engine-Assets.
Diese pak-Dateien kannst du ganz regulär entpacken und die Inhalte extrahieren. Das ist auch prinzipiell nichts illegales oder so. Es gibt dafür von Epic Games (den Entwicklern der UE) ein offizielles Kommandozeilentool namens UnrealPak. Das findest du hier.
Damit kannst du die einzelnen asset-Dateien im uasset-Format (auch ein Dateiformat von der Unreal Engine) extrahieren.
Diese uasset-Dateien kannst du dann im Unreal Editor oder inoffiziellen Tools wie UModel bzw. UE Viewer öffnen und in allgemeine Dateiformate (dds, png, obj, fbx usw.) umwandeln, die du dann auch z.B. in Blender öffnen und als o3d speichern kannst.
Beachte aber, dass das natürlich eine Menge an Arbeit ist und dass man da auch viel selbst machen muss. Es ist definitiv keine ein-klick-Konvertierung von UE nach OMSI. Dazu arbeiten beide Systeme auch viel zu unterschiedlich bzw. haben unterschiedliche Anforderungen. Die Assets aus der UE werden wahrscheinlich erstmal viel zu detaillierte Modelle, viel zu hochauflösende Texturen und viel zu komplexe Materialien haben als das OMSI damit in der Masse ansatzweise klarkommen würde.
Außerdem ist es Entwicklern auch möglich, die pak-Dateien zu verschlüsseln, dann kommst du da legal tatsächlich nur mit dem entsprechenden Schlüssel ran, den die Entwickler normalerweise eher nicht "einfach so" zur Verfügung stellen. Außerdem möchte ich nochmal das Rechtliche vom Anfang betonen.
Heißt also: Es dürfte durchaus technisch möglich sein. Das gilt es, auszuprobieren, aber diese Inhalte in irgendeiner Form im Original oder weiterverarbeitet weiterzugeben oder zu veröffentlichen, ist wohl kaum möglich, es sei den TML stellt dir eine Genehmigung aus.
Ich kann es leider auch nicht reproduzieren.
Ebenso Firefox, aktuellste Version.
Allerdings handelt es sich hier ja, zumindest im Dark Mode, um die Font "Open Sans", die habe ich nun leider bewusst auf meinem System installiert. Vielleicht tritt das Problem auf, wenn man die Schriftart nicht selbst installiert hat... Wie sieht das bei dir aus Busfan Bayern?
Edit: Mit den Firefox-Tools grade mal testweise explizit das Laden von Systemfonts komplett deaktiviert, sodass er gezwungen ist, die Webfonts zu laden, auch das funktioniert as expected...
Die Plane auswählen, im Face-Auswahlmodus, dann X drücken und "Faces" auswählen
Es können auch mehrere Flächen sein, musst du dann mit Shift gedrückt halten alle auswählen oder mit dem Pinsel-Tool (Taste "C") alle auswählen.
