= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! kann er denn auch normale Wechselziele?
Die werden nicht vom IBIS gesteuert. Ist vom Matrixscript abhängig.
Richtig.
die Drucker aus dem Bremen Addon haben ja keine Ibisfunktion, funktionieren die dann zusammen mit dem Controller?
Theoretisch ja. Die Bremer Gerätschaften sind aber scriptseitig relativ spannend miteinander verschachtelt, sodass potenziell etwas mehr Arbeit dafür notwendig ist., die einzeln ans laufen zu bekommen.
Am Fahrplan selber wird die Abfahrt nur zur Stunde und Minute angezeigt. Einstellen kann man aber auch die Sekunden. Heißt es wird wahrscheinlich so sein, dass die Abfahrt um 08:18:30 ist, nicht 08:18:00.
Zwei Optionen: Negative Länge (Flippt die Normals von Splines) oder zusätzliche Texturflächen hinzufügen, die allerdings verkehrt herum verlaufen. Also statt von Punkt X zu Y von Y zu X, wenn das verständlich genug ist.
Die 19er Bustec von der VAG/ESTW/Infra im Nürnberger Raum schauen von den Fonts her tatsächlich sehr ähnlich aus. Wenn du zu denen irgendwie Zugang bekommen kannst, dann schau vielleicht mal bei den Bustec-Fonts nach, ob da was Passendes dabei ist.
Selbiges muss dann auch bei allen anderen Einträgen, die mit (M.V.ST anfangen, ebenfalls gemacht werden.
wie soll man allein mit Scripten die Kollision mit der Spurführung abfragen?
In der 2.2 könnte man das wahrscheinlich mit GetHeightAbovePoint lösen, wie man es bei Stromabnehmern für Straßenbahnen gemacht hat. Bleibt allerdings die Frage, ob das in der 2.3 noch so funktionieren würde, ich nehme mal an nein..
Dann hat Cooper die offensichtlich irgendwann mal entfernt. Hab in meinen Bussen noch die 1.2 drin.
In der 1.622 steht in der Zeile 450 folgendes:
In der 1.2 in Zeile 308 ziemlich exakt das gleiche, wobei der Constfile-Wert in der 1.622 hardcoded ist:
Ergo: Die 3 in Zeile 450 gibt deine Wechselzeit an.
Ist dafür nicht der Constfile-Eintrag Matrix_PageDuration zuständig?
Danke, es gibt in einem Font des Busses eine fertige Grafik. Diese wollte ich verwenden mit Ziel.
Entweder ° oder ÷.
Da werden sicher irgendwelche Variablen doppelt vorhanden sein. Such mal in den vom Bus verwendeten varlists nach IBIS_Linie_complex und IBIS_TerminusIndex, dann findest du schnell, welche bzw. wo die doppelt drinnen sind. Hast du zufällig die Varlist vom Atron nicht rausgenommen?
War einer der Fehler zufälligerweise nicht erklärbare Omsi-Abstürze beim Beenden/neu laden?
nur halt die wichtigsten im OMSIversum wären schön
Die da wären? Hamburg ist (zumindest aus meiner Sicht) eigentlich nur für Hamburger wichtig, der Rest fährt es halt (gerne) mal zwischendurch. Da gibt es einige fiktive Maps, die zumindest im Screenshot-Thread wesentlich häufiger zu sehen sind, z.B. Ahlheim, Städte3eck oder Lahnau. Für die kann man aber wohl schwer dedizierte Varianten machen, weil die Bus-Ausstattung dementsprechend auch fiktiv wird.
Außerdem: Wer soll sich für eine Hamburger Version denn bitte die Mühe machen? dafür müsstest du dann auch erst einmal den Innenraum komplett anpassen, Scripts überarbeiten und das gesamte Fahrgastinformationssystem komplett von 0 auf neu bauen, zwecks Copyright und so. Weißt du eigentlich, wie viel Arbeit das ist?
Die Entwickler kommen aus Berlin und haben sich dementsprechend dazu entschlossen, die dortigen Busse als Vorbild zu nehmen. Ist auch komplett verständlich. Wenn dir die bereitgestellten Versionen nicht passen, musst du halt selbst Hand anlegen. Ob du das schaffst oder nicht, ist nicht das Problem der Entwickler.
Die Einträge im Frame-Teil fehlen. Müsste irgendwie (M.L.EvendPC2_frame) oder so heißen. Schau da mal im Bremer MAN nach und nimm die Einträge.
Ja, habe ich. Mehrere. Nein, Omsi ist auf keiner davon.
Nochmal zum Mitschreiben:
Omsi ist langsam. Sollten wir inzwischen alle mitbekommen haben.
Im Task-Manager kann man im Tab "Details" mit einem Rechtsklick auf ein entsprechendes Programm die Prozesspriorität verändern.
Wenn man bei der Omsi.exe die Prozesspriorität auf "Hoch" stellt, sorgt dies u.a. dafür, dass Dateizugriffe (und alles, was dazugehört) seitens Omsi schneller abgearbeitet werden. Das kann man insbesondere beim Omsi-Start im Task-Manager sehr schön verfolgen und vergleichen.
Dadurch lädt Omsi beim Start deutlich schneller.
Jegliche durch Hardware verursachte Laderuckler verschwinden dadurch natürlich nicht. Sollte eigentlich auch klar sein.
Die Hardware wird in ihrer Konfiguration dadurch logischerweise auch nicht verändert. Wenn die Platte von Haus aus langsam ist, wird sie dadurch nicht automatisch schneller.
Durch Omsi selber verursachte Laderuckler können dadurch potenziell verkürzt werden. Damit habe ich mich aber bislang nicht befasst.
Allgemeine Performance-Probleme, die auf eine Schwache CPU oder GPU zurückzuführen sind, lassen sich dadurch natürlich auch nicht beheben.
Es geht hierbei rein um die Ladegeschwindigkeit seitens dem Programm Omsi und einer Methode, mit der man diese etwas beschleunigen kann. Nicht mehr, nicht weniger.
Das Ergebnis ist sehr leicht und deutlich reproduzierbar. Das kannst du gerne mal ausprobieren.
Hat für mich und einige andere auf jeden Fall eine merkbare Verbesserung gebracht...
Das bezieht sich auch nicht auf die Hardware, sondern auf Omsi selbst. Da ist der Unterschied beim Laden sehr deutlich spür-, mess- und sichtbar, wenn alle anderen Parameter gleich sind.
Jein. Es wird einen Unterschied geben, aber preislich ist der Unterschied zwischen Priorität auf hoch und NVMe-SSD nicht vertretbar. Das macht einfach keinen Sinn. Da bist du nicht mehr durch die Hardware limitiert, sondern durch Omsi selbst.
Hast du die entsprechenden Makro-Einträge in der Main.osc eingetragen?
Alternativ kann man Omsi auch mit Prozesspriorität hoch starten. Hat so ziemlich den gleichen Effekt, ist aber wesentlich billiger.
ALU (privat modifiziert) | MAN A23 (Sobol, privat modifiziert)
