Beiträge von S.A.D.
++ Update: 31.03.2026, 21:35 Uhr: siehe Artikel ++
Achtung: Sicherheitswarnung für ein Programm aus unserer Filebase
Wir haben bei dem Programm "No More Sleep!" aus unserer Filebase Sicherheitsbedenken feststellen müssen. Für Nutzer, die die neuste Version des Programms von letzter Woche nutzen, haben wir hier weitere Informationen zusammengestellt: **Klick**
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet:
= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! -
-
Schau mal, was um Zeile 705 in der Modeldatei eingetragen ist.
Außerdem verwendet das Init-Script abweichende Türvariablen, die du erstmal einfach in eine verwendete varlist eintragen kannst, um die Fehler abzustellen. Korrekterlesen müssten anschließend entweder im Script die Variablen durch den Standard ersetzt werden oder eine kurze Zuweisung auf die Alternativvariablen gestellt werden.
Initiative Variablen: door0, door1, door2, door4, door6, door8
Standard Variablen: door_0, door_1,...
Brückenscript z.B. Anfang des Init-Geräte Frames:
(L.L.door0) (S.L.door_0)
(L.L.door1) (S.L.door_1)
...
Der Kritische Fehler ist aber auf jeden Fall das mit der Model Datei
-
Da ich die Matrix nicht mehr besitze nur eine Theorie die ich nicht überprüfen kann, da die Logfile für den C1 mir CoD Matrix keine erkennbaren Fehler enthält: Müsste nicht eigentlich auch das Script auf die Setvar Einträge zugreifen, damit die korrekten Fonts und Anzeigenmaße für die Scripttextur verwendet werden? Das dürfte (denke ich) ja dabei mit bedacht worden sein und entsprechend nicht alles immer unnötig mit berechnet werden.
Das ganze kommt wenigstens für die verwendeten Fonts z.B. bei den Kajosoft Bussen oder den DGM Matrix Paketen zur Anwendung.
Könnte also sein, dass hier ggf. keine passenden Schriftsätze oder sogar Scripttexturen verwendet werden.
-
In der cockpit_constfile.txt gibt es relativ weit am Ende
[const]
tuertaster_blink
1
Wenn die 1 in eine 0 verändert wird blinken die Türtaster garnicht mehr (also auch nicht bei fehlender Druckluft und betätigtem Nothahn.).
Alternativ muss in der Cockpit.osc nach Tuertaster 1 gesucht werden.
Es folgen nun 5 Türtastereinträge.
Hierbei muss nun dafür gesorgt werden, dass die Einträge (L.L.haltewunsch_X) durch eine logisch nie korrekte Bedingung ersetzt werden.
Hierzu genügt es hinter diesen Eintrag z.B. 2 > einzufügen. Hiermit würde das Blinken nur dann ausgelöst, wenn die binäre Haltewunschbedingung (0 = kein Haltewunsch, 1 = Haltewunsch) einen Wert von 2, also außerhalb des möglichen Bereichs, annimmt.
Die Fertige Zeile wäre also (L.L.haltewunsch_X) 2 >.
Hierbei bleibt zumindest das Blinken über den Nothahn bestehen.
Eine andere Option ist es, (ebenfalls) in der Cockpit.osc, in dem Abschnitt über Tuertaster 1 die beiden oberen Bedingungen (haltewunschlampe_all und halt_inw) zu deaktivieren. Dazu können die Zeilen mithilfe eines Apostrophs ' am Zeilenanfang auskommentiert werden. Außerdem sollte in der folgenden Zeile der logische "oder" Befehl || entfernt werden.
Hierbei wird das Blinken durch ein nicht Starten des Blinkertimers unterbunden.
Nachteil dieser Varianten: Wenn jetzt ein Nothahn betätigt wird startet auch der Timer und somit das Blinken der Türtaster mit Haltewunsch.
-
Der Mod verwendet eine modifizierte Version der Krüger++ Matrix, welche unter anderem die Möglichkeit einer Laufschrift beinhaltet.
Diese Funktionen werden z.B. durch das Addon "Grand Paris-Moulon" genutzt (und müssten auch daher stammen).
Leider ist diese Mod nicht vollständig mit der universellen Hofdatei bzw. einer normalen Hofdatei kompatibel.
Wenn in der Hofdatei eine Rollbandtextur eingetragen ist, wird diese als Textur (oder fehlerhafter Eingabewert, bin mir da nicht ganz sicher) für die einzelnen Linienanzeigen interpretiert bzw. sorgt dafür, dass die Anzeige komplett Aktiviert, also Weiß wird.
Sobald der Rollbandstring (String 4) leer ist funktionieren auch die einzelnen Linienanzeigen korrekt.
-
Wenn ich mich richtig erinnere war der Drucker mal in der ersten Version des (400 MMC) Addons dabei. Allerdings wurden wohl beide Addons sehr stark Überarbeitet bzw. zweiterstellt, wobei glaube ich auch der Drucker vollständig ausgetauscht wurde.
-
Ich würde dir vorschlagen, dies über das ALT-Menü manuell zu steuern
Das würde ich nicht vorschlagen. Dann hast du nämlich keine Ansagen
Natürlich sollte erst die Route über den Drucker und dann nochmal Liniennummer und Ziel über das ALT-Menü geschildert werden, dann gibt es Präfix und Ansagen.
Alternativ müsste in der .hof-Datei die Liniennummer "Hardcodet" werden. Da der Citaro Facelift die Krüger+(+) Matrix verwendet ist dies mit dem Zusatz *[LINIENNUMMER] am Ende der (ersten) Zielzeile der Frontanzeige möglich. Hierzu müsste allerdings für jede Linie ein eigenes Ziel mit gleichem Namen erstellt werden und dann das Ziel bei den Routen entsprechend auf die korrekte Nummer abgeändert werden. Weitere Informationen in folgendem Handbuch Krueger matrix mod "Krueger+" 0.6+2ε.
Ansonsten wäre noch der Einbau eines anderen Druckers oder IBIS-Systems eine Option.
-
Spieler-Straßenbahnen können in Omsi nicht über die Entrypoints gesetzt werden. Wenn ich richtig liege, spawnen sie immer auf einem der ältesten, und damit in den Mapdateien frühesten, Gleissplines im geladenen Bereich. Aber auch dass kann teilweise bei gleichen Einstellungen in unterschiedlichen Versuchen unterschiedliche Ergebnisse haben. Für einen neuen Straßenbahn Spawnpunkt auf der geplanten Strecke müsstest du wahrscheinlich etwas tricksen.
Mehr kann ich dazu aber auch nicht direkt sagen. Wenn ich mich richtig erinnere gab es dazu vor ein paar Jahren auch hier in der Webdisk und im damals noch offenen offiziellen Omsiforum (https://forum.omnibussimulator.de/forum/) einige Themen zu den Besonderheiten.
-
Der Regio Sprinter würde doch eher in die Zeit Passen.
Sowohl der RegioSprinter, als auch der Regio-Shuttle wurden ab Mitte der 1990er Jahre gebaut. (Ersteinsatz: RegioSprinter 1995, Regio-Shuttle 1996).
Während der RegioSprinter ein ziemliches Nischendasein mit nur 40 Fahrzeugen darstellt, ist der Regio-Shuttle mit ca. 500 Fahrzeugen weiter verbreitet (auch, da er nach 2000 weiter hergestellt wurde, anders als der RegioSprinter von DUEWAG->Siemens->Desiro).
Da seit Anfang der 2000er Regio-Shuttles in Thüringen heimisch sind, ist es folglich logisch, diesen auch im Addon (2004) darzustellen und keinen RegioSprinter, welcher zu dieser Zeit nur in NRW und Sachsen, sowie auch außerhalb Deutschlands in Dänemark anzutreffen war.
Quelle: Wikipedia
-
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.
-
-
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.
-
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.
-
-
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.
