Beiträge von S.A.D.

Guten Morgen,

vorab: Ich schreibe diesen Beitrag ohne das Pack (in egal welcher Version) gefahren zu sein.

Meine Anmerkungen beziehen sich ausschließlich auf eine kurze Analyse der Fahrpläne mit dem Omsi-Helpmaker.

Die Ergebnisse sind auch im Anhang als .zip verfügbar.

Allgemein: Bevor ich eine neue Map oder Fahrplanmodifikation fahre schaue ich mir zumeist die Fahrpläne entweder durch mitgelieferte Planungsunterlagen oder den mithilfe des Omsi-Helpmakers an, um einen besseren Überblick über tatsächliche Takte und Umläufe zu erhalten.

Leider musste ich feststellen, dass die Fahrpläne diese Linienpacks zwar durchaus isoliert betrachtet eine gute Planung der Umläufe im Einzelnen, jedoch in der Gesamtschau eher eine chaotische, nicht Fahrgastfreundliche Taktgestaltung darstellen.

Das Hauptproblem: Die Umlaufzeit der Linien(kombis) passt nicht zum Takt.

Umlaufzeit S1 und S12+E12 Tag: 90 Minuten, Linientakt(Plan): 20 Minuten, Tatsächliche Taktung: 20:20:20:20:10 (S12 Hochtann-VGA-Spryndorf: 20:20:20:0:30)

Umlaufzeit S1 und S12 Nacht: 90 Minuten, Linientakt(Plan): 40 Minuten, Tatsächliche Taktung: 40:50

Umlaufzeit RE9(X)+E9: 85 Minuten, Linientakt(Plan): 30 Minuten, Tatsächliche Taktung: 30:30:25

Umlaufzeit RB27: 50 Minuten, Linientakt(Plan): 20?/30? Minuten, Tatsächliche Taktung: 25 Minuten

Ob die Fahrzeiten passend sind kann ich nicht durch eigene Fahrerfahrungen beurteilen.

Auch der Helpmaker liefert keine Erkenntnisse, da die einzelnen Fahrzeiten im Helpmaker nicht berechnet werden können. (Hierfür wären diskret definierte Einzelfahrzeiten in den Fahrzeitprofilen notwendig, welche dann aus der entsprechenden .ttp gelesen würden.)

Ich hatte überlegt noch einen Schlussabschnitt zum Thema SEV-Konzept und persönliche Präferenzen anzuhängen, was allerdings nicht mehr thematisch hier zugehören würde, sodass ich dieses Thema wahrscheinlich demnächst in einem eigenen Thread aufgreifen werde.

Nur so viel: Abgestimmte Takte und Linien sind für mich wesentlicher Bestandteil eines Packs und in der Regel die Grundbedingung für meinen Fahrspaß, sodass ich dem aktuellen Stand leider außer einem interessanten Grundkonzept (noch) nicht wirklich viel abgewinnen kann.

Ich hoffe, dass dieser Beitrag als möglichst konstruktiv aufgenommen wird, da ich hiermit auf keinen Fall dem Pack die unbestreitbare Arbeit und konzeptionelle Qualität mit auch teilweise sehr kreativen baulichen Lösungen absprechen möchte.

LG

S.A.D.

Die Logfile sieht erstmal unauffällig, aber unvollständig aus.

Evtl. würde ein Screenshot der Grafikeinstellungen (Normal und Erweitert) mögliche problematische Einstellungen zeigen können.

Außerdem die Frage: Sind irgendwelche Grafikmodifikationen installiert?

LG

S.A.D.

Soweit ich mich erinnere lag das an der setvar:

[setvar]
vis_Klappfenster
1

Versuch mal die durch

[setvar]
vis_CTI_Klappfenster
1

zu ersetzen.

Beim Spielerbus klappt auch einmal durchschalten per Monitor.

Du musst den String noch in die Klammern einpacken, also in das (S.$.Variablenname) z.B. (S.$.IBIS_lcd_nextstop).

Bedeutungserklärung:

() = Variablenzugriff erwarten

S. = Schreib etwas

$. = in einen String (Text)

Variablenname =Genau hier hin.

Weitere Erklärungen: Scriptsystem in Abschnitt 10

Ist das Auftragsschild auch im richtigen Ordnerpfad?

Für diesen Eintrag müsste es im Grundordner bei der .cti liegen.

creeperblock Versuchen mal die Objektkomplexität hoch zu stellen (Mindestens 1 für die Wartehäuschen). Manchmal setzt Omsi das nach Absturz oder Update zurück, bzw. mache Presets haben das auf 0.

Zitat von BusZug

hast du den Ordner MB_C2_EN_BVG einfach umbenannt oder so?

Das hätte nicht diese Fehler zur Folge. Die .bus Dateien liegen ja in diesem Ordner drin und greifen nur auf Unterordner zu. Der Ordner im Vehicles-Verzeichnis könnte theoretisch auch "Himbertorte123" oder "besterBusEVAAR" heißen und die Busse an sich würden weiterhin funktionieren.

Allerdings würden in dem Fall dann die normalen Ailists-Einträge nicht mehr stimmen und daher andere Fehler erzeugen (Busname.bus kann nicht geladen werden, Datei Busname.bus nicht gefunden)

Kann es sein, dass du beim Kopieren von .hof-Dateien aus Versehen auch .bus-Dateien mit kopiert hast?

Das würde diese Fehlläufer erklären.

Ich würde dir empfehlen alle Busordner durchzugucken und alle .bus-Dateien die offensichtlich nicht zum Ordnernamen passen zu löschen.

Ansonsten müssten wir hier jede .bus-Datein wahrscheinlich einzeln durchgehen, da nur Busse, die geladen werden sollen auf diese Fehler geprüft werden.

410 15:27:18 -  -   Error:           You want to create vehicle vehicles\CAM_Busotto\MB_C2_E5_Gn_main.bus - it is invalid!

Vorgehen wie bereits Beschrieben:

MB_C2_E5_Gn_main.bus aus dem Ordner CAM_Busotto löschen.

Du solltest NUR die MB_C2_E6_Gn_UE_main.bus aus dem Ordner MB_O530_v5 löschen, da sie da nicht reingehört.

Und wenn der C2 trotzdem nicht geht, dann bitte eine neue Logfile, weil dann wahrscheinlich noch andere Fehler vorliegen.

Normal müsste der C2 ja im Ordner MB_C2_EN_BVG sein.

Hallo Kader2_0,

Anscheinend hast du die MB_C2_E6_Gn_UE_main.bus in den Ordner des 1. Generation Citaro kopiert oder verschoben und versuchst daraus den Bus zu Spawnen. Da die Datei in einer anderen Ordnerstruktur liegt ist die Definition ungültig, da keine der notwendigen Skripte und Modelldefinitionen geladen werden kann.

Sofern im eigentlichen C2 Ordner die MB_C2_E6_Gn_UE_main.bus noch existiert lösch die im MB_O530_v5 Ordner, sonst verschiebe sie bitte zurück.

Ansonsten machen noch Makros folgender Busse (Ordnername) Probleme: MAN Citybus LC Series und MANNG273T4 Chrisles

Diese haben nicht mit dem C2 zu tun und da ich diese Busse nicht kenne kann ich auch nicht mehr dazu sagen.

LG

S.A.D.

Hallo Dominic, es handelt sich höchst wahrscheinlich um ein Auxi-Problem.

Der Cloudtype "-1" ist einfach nur klarer Himmel. Diese Meldung kommt immer, wenn keine Wolken ausgewählt werden.

Es ist bekannt, dass "Fehler bei Bereichsprüfung: P.TL: 9" immer dann ausgegeben wird, wenn etwas in der Omsi-Wettersteuerung nicht ganz richtig läuft.

Beispielsweise war dies noch in der Omsi-Version 2.2 bei Verwendung des realen Wetters ein ggf. alle paar Sekunden auftretender Fehler.

Das Auxi-System greift über direkten Variablenzugriff in die Berechnungen und Berechnungsgrundlagen des Omsi-Wetter- und Temperatursystems ein, sodass unplausible Werte entstehen, durch welche wahrscheinlich der Fehler geworfen wird.

Ich selbst verwende die Entwicklertools von von Auxi nicht.

Ebenso weiß ich nicht, welche .lua du verwendest und was dort drin steht und wahrscheinlich die Fehler verursacht.

Laut Handbuch kann für das Entwicklertool die Aktualisierungszeit zwischen den Variablenänderungen zwischen alle 0,1 bis 10 Sekunden (100-10000 Millisekunden) eingestellt werden. Evtl. könnte hier durch Intervallverlängerung zumindest die Häufigkeit des Auftreten ebendieses Fehlers verringert werden.

Aus den vorliegenden Logfiles geht erstmal nichts weiteres hervor, außer dass die verringerten FPS wahrscheinlich durch das Überfüllen der Logfile mit diesem Fehler zustande kommt. Weitere Auslöser wirken auch erstmal unwahrscheinlich.

Um evtl. noch weitere Ideen für die Fehlerbehebung oder wenigstens eine Fehlerreduzierung zu haben würde ich folgendes vorschlagen:

1. Die Auxi-Logfile Anhängen um evtl. dort entstehende Fehler zu erkennen.

2. Die .lua oder ihren Inhalt ebenfalls mitliefern um das, auf dessen Grundlage die Fehler wahrscheinlich entstehen, genauer verstehen zu können.

3. Evtl. die oben angesprochene Änderung der Aktualisierungsrate durchführen und danach eine neue Logfile schicken um evtl. auftretende Effekte erkenne zu können.

Vielleicht konnten meine Überlegungen zu deinem Problem dir weiterhelfen.

LG

S.A.D.

6631 11:04:26 -  -     Warning:       Szenerieobjekt wurde nicht gefunden: Sceneryobjects\Leitplanke\crash_barrier.sco, falls es sich um eine Addon-Karte handelt, lesen Sie bitte die Dokumentation und kontaktieren Sie ggf. den Autor. Falls es sich um eine originale Karte handelt (Spandau oder Grundorf), reparieren Sie bitte OMSI mittels Original-Setup.
6632 11:04:26 -  -   Error:           The file "Sceneryobjects\Leitplanke\crash_barrier.sco" could not be loaded!
6633 11:04:26 -  -     Warning:       Invalid Object: Sceneryobjects\Leitplanke\crash_barrier.sco"
6634 11:04:26 -  -     Warning:       Szenerieobjekt wurde nicht gefunden: Sceneryobjects\Leitplanke\crash_barrier.sco, falls es sich um eine Addon-Karte handelt, lesen Sie bitte die Dokumentation und kontaktieren Sie ggf. den Autor. Falls es sich um eine originale Karte handelt (Spandau oder Grundorf), reparieren Sie bitte OMSI mittels Original-Setup.
6635 11:04:26 -  -   Error:           In map file "maps\Ahlheim 4\tile_-15_14.map" there was an error in line 3926!

Dir fehlt die Leitplanke der "Vorausgesetzten Addons" aus dem Handbuch Link zur Leitplanke

Das Problem dürfte sein, dass die Abfrage nach Phase 0 (l0 < 1) keine dauerhafte Abschaltung erreichen kann, da immer auch die Aktivierungsbedingung l0 < 3 erfüllt wird.

Ich würde die Aktivierungsanfrage entsprechend noch um l0  1 >= && ergänzen.

Phil-Muc089 Nimm mal bitte das .bmp aus dem Dateinamen raus. Das ist nur das Kürzel des Dateiformats. Da bei dir diese Kürzel nicht angezeigt werden heißt die Datei für Omsi gerade Gleis_Beton.bmp.bmp

LG

S.A.D.

Jeweils mit den Namen, welche im Spoiler stehen für jeden aufgeführten Namen.

In der AVG_Kranenburg.ttl muss noch bei Umlauf 023 und 026 Eichenhöhe durch Eichenhoehe ersetzt werden (manche Nummern gibt es 2 mal).

Gleiches gilt für den Impfshuttle. Dieser befindet sich in einem Chrono-Ordner, also ab Omsi Hauptverzeichnis:

OMSI 2\maps\Ahlheim 4\Chrono\Corona Impfshuttle ab 08.02.21\TTData

Bei der Schulbus.ttl wird in Umlauf 99901 ein generell falscher Name verwendet. Diesen durch AVG Solowagen (Eichenhoehe) ersetzen.

Für die Fehler  has at least one invalid trip index:

Manche Trips (Fahrtdefinitionen) sind mit Ö oder Ü benannt.

Das betrifft wenigstens (können mehr sein, sind jetzt nur die, welche in der Logfile den Fehler werfen):

Mit diesen Namen gibt es jeweils 2 Dateien:

1: NAME.ttp <-- Ziel, Halte, Zeiten, zugehöriger Weg

2: NAME.ttr <-- Fahrweg

Fehlerbehebung:

Schritt 1:

Bei beiden Dateien das Ö durch OE oder das Ü durch UE ersetzten.

Schritt 2:

Die NAME.ttp mit dem Texteditor öffnen und den unter [trip] angegebenen Dateinamen ebenso ändern.

Ja, das wäre zumindest mein Ansatz dafür.

Phil-Muc089

Zitat von Readme Addon Simple Streets (Auszug)

3b) Kopiere "Splines/Marcel/texture" nach "Splines/ADDON_SimpleStreets/texture"

Kopiere "Sceneryobjects/Kreuz_MC/texture" nach to "Sceneryobjects/ADDON_SimpleStreets/texture"

Kopiere und NENNE UM "Sceneryobjects\Railroad_RUE\texture\Gleis_Betonschwellen.bmp" In "Sceneryobjects\ADDON_SimpleStreets\texture\Gleis_Beton.bmp"

Bitte prüf nochmal, ob die die Datei korrekt Kopiert und umbenannt hast, da Omsi diese nicht findet.

wilbo4

Bei dir sorgt wahrscheinlich das ö im AI-Group Namen von Eichenhöhe für Probleme.

Lösungsvorschlag:

Schritt 1:

Gehe in die ailists.cfg im Mapordner.

Dort sollten ab ca. Zeile 145 die Fahrzeuge des Btf-Eichenhöhe eingetragen sein.

Überall wo Eichenhöhe steht (oder ggf. mit Fehlerhaften Zeichen anstelle des ös) dies durch Eichenhoehe ersetzen.

Schritt 2:

Im Unterordner TTData muss in .ttl-Dateien, wo Fahrzeuge des Btf-Eichenhöhe aufgerufen werden der Name Ebenfalls getauscht werden.

[newtour]
61001
AVG Gelenkwagen (Eichenhöhe)
528

Unter jedem [newtour] steht erst die Umlaufnummer/Der Umlaufname und danach die Zugehörige AI-Group. Hier den Namen wie in der ailists.cfg abändern.

Das ganze muss für ALLE Umläufe in ALLEN entsprechenden Dateien gemacht werden.

Folgende Dateien enthalten bei dir einen entsprechenden Fehler:

Lösung/Workaround für die Brücke:

Geh in den Ordner:

OMSI 2\Sceneryobjects\Ahlheim4_Objekte\Lierach_Objects

und öffne die Bruecke_Lierach.sco mit einem Texteditor.

Füge unter dem letzten Eintrag erst eine Leerzeile und anschließend den Befehl [nocollision] ein.

Damit wird die komplette Brücke Kollisionslos, sodass auch die fehlerhafte Kollision der Unterführung verschwindet.

LG

S.A.D.