Beiträge von hajo

Willkommen in der OMSI-WebDisk!
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!

    Ergänzend dazu...

    Ich hatte vorher ein G27. Als ich zum Hori wechselte, dachte ich Anfangs, dass Force Feedback quasi nicht vorhanden ist. Lenken ging mit dem kleinen Finger ohne jegliche Gegenkraft.


    Es war erst nötig, den Regler für die Force Feedback-Stärke in OMSI deutlich zu erhöhen. Beim Logitech stand das etwa auf 25% - jetzt bin ich bei über 75%.

    Dann fühlt sich's wieder ok an. Der Gegenschlag am Bordstein ist aber noch immer schwächer ... worüber ich aber ganz froh bin. Aber jegliches Vibrieren aufgrund schlechter Straßen fehlt halt komplett.


    Ansonsten kann ich mich mich Herr_Mr_Sir anschließen. Das Lenkrad ist klasse für Busse und LKW und ergibt ein völlig anderes Gefühl, als das kleine Logitech.


    Im direkten Vergleich muss ich aber auch sagen, dass sich das Logitech merkbar "wertiger" anfühlte. Hori ist halt nur Plaste (immerhin mit Kunstlederbezug am Lenker), wogegen das Logitech-Lenkrad aus Metall war und sich einfach stabiler anfühlte. Dafür gibts aber bei Hori z. B. auch einen echten Blinkerhebel am Lenkstock - und das macht das Ganze auch gleich viel realistischer.

    Einfacher konstruiert sind auch die Pedale. Gerade bei der Bremse fällt das auf. Hier hatte das Logitech wirklich eine gut gemachte Bremse deren Gegendruck fließend stärker wurde, je tiefer man drückte. Bei Hori wird die leichtgängigere Bremse dagegen nur von einem Gummi gestoppt, der die letzten Millimeter des Pedalwegs bis zur Vollbremsung etwas schwergängiger macht. Stärkeres Bremsen wird da leicht unbeabsichtigt zur Vollbremsung. An der Schalteinheit hab ich dagegen gar nichts auszusetzen. Die macht gerade in ETS beim Schalten Spaß und bietet aber auch jede Menge Knöpfe, die ich in OMSI belegt hab. Die Tastatur ist zum Spielen so völlig überflüssig geworden.

    Mrblume falls du das Enhacned Environment Pack hast, liegt es daran.

    Bei mir gabs gestern neben dem Bremen-Update aber auch ein Update vom Enhanced Enviroment Pack, das (scheinbar) wohl endlich dieses Problem behoben hat.

    Die vorherigen Änderungen der Original sound.cfg stehen nun in einer Extra-Datei (sound_EEP.cfg) und die Spandau-Originalfahrzeuge wurden entsprechend auf diese EEP.cfg angepasst. Andere Fahrzeuge sollten nun eigentlich keine Probleme mehrhaben (voruasgesetzt, dass die sound.cfg nun wirklich wieder im Originalzustand ist - der randomsound-Eintrag ist zumindest nicht mehr drin)

    Hab gerade noch mal die alte Konversation mit Tobi durchgesehen (als ich die Repaints für Hohenkirchen gemacht hatte) ... aber da stand von ihm auch nur "...der IVECO hat ja keine KI-Variante ..."

    Kein Ahnung, ob der nun gar nicht KI-tauglich ist, oder ob es nur Performance-Gründe hatte, da es keine dedizierte KI-Version gibt.

    Probiers einfach aus, ob es klappt, indem du der ai-List den KI-Bus gegen den IVECO ersetzt.


    Und wie Lars schon schreib, der KI-Gelenkbus ist nicht fahrbar ... vor allem ist das eben auch eine performanceschoneden KI-Version, bei der es auch nur einen völlig reduzierten Innenraum gibt - da ist kein Cockpit, dass du bedienen könntest, drin.

    Ja, das mit den Eintragen in den Trailer-Bus-Dateien wollte ich auch gerade schreiben

    Diese "_21.cfg" ist jedoch ausschließlich für den Solo-Bus vorgesehen und nicht für die Varianten mit drei oder vier Türen.

    Und dies dürfte dein nächster Denkfehler sein:

    Die config-Datei ist nicht für den Solo-Bus, sondern für den Vorderteil des Gelenkbusses - denn im HH20-Addon war nur dieser dabei.

    Der Solo war ein zuvor erschienenes separates Addon und der Bus liegt in einem komplett anderen Verzeichnis im vehicles-Ordner (HH_EBus2019).

    Das HH20-Addon lieferte den Solo nur als stehendes vehicle (HH20_EBus2019_parked) mit.

    Ich habe auch JoyToKey allerdings erkennt dieses bei mir auch nur 32 Buttons. Kann mir jemand sagen wie ich das ändern kann?


    In JoyToKey im Reiter "Options" (neben den Reitern der erkannten Controller) musst du den Wert bei "Number of buttons to configure" erst noch auf 64 erhöhen.

    Der stand bei mir nach der Installation von JoyToKey auch erst auf 32.

    Der 305 hat der model.cfg den Standardordner "Anzeigen\Rollband_SD79" eingetragen, der 305G dagegen "Anzeigen\Rollband_O305_Std".

    Die Bitmaps der Rollbänder in letzterem Ordner haben tatsächlich nur Zahlen und "E".


    Variante 1: Die Rollbandbitmaps in Anzeigen\Rollband_O305_Std ersetzen (bzw. möglicherweise auch noch um "Rollband_Ln2..." "Rollband_Ln3..."ergänzen und auch die chtex_rollband ersetzen ... dann sollte es von der Rollbandanzeige identisch zum SD79-Ordner sein).


    Variante 2: Eintrag in der model-cfg ändern.



    Ob und was davon funktioniert, müsstest du aber selbst testen - meine Tipps kamen jetzt nur vom schnellen Ansehen der Dateien im Texteditor.

    Es gibt keinen Changelog, weil dieses Update nur den unsichtbaren Nachläufer beim Gelenk gefixt hat.

    Ähem ...


    V3-02

    =====

    - Behebung des Fehlers mit dem unsichtbaren Citelis AI-Bus

    - Korrektur der Invertierung der Liniensymbole auf dem Display für C20 und C23

    - Hinzufügen der fehlenden Schriftart

    - Korrektur eines kleinen Fehlers in der Außenanzeige des C24

    - Korrektur des falsch angezeigten Textes im Citelis 18

    +++




    Changelog gibts im Verzeichnis "OMSI 2\Addons\Saint-Servan" ;)

    Seltsam ... bei dir gibts gar kein OMSI 2-Verzeichnis (nicht die Addons) in der registry.


    Bei mir sieht das so aus


    Falls sich da inzwischen was geändert haben sollte ... ich hab noch Windows 10.


    Ansonsten würd ich's halt mal versuchen und das ganze inkl. Verzeichnis in der regedit anlegen. Nur "Product_Path!" reicht ja möglicherweise (oder vielleicht noch den "Standard)"-Eintrag - wofür auch immer der gut ist.



    ---


    und kurz nach dem Absenden des Beitrages werde ich gerade unsicher, ob ich das alles vielleicht doch selbst in Windows 10 angelegt hab (eben wegen des Installationsproblems) und da einfach alle Einträge aus Windows 7 übernommen hab ... ??? .. kann ich dir aber wirklich nicht mehr mit Sicherheit sagen.

    Ups - schon so lange her. Aber aus meiner Erinnerung:


    Bei irgendwelchen Aerosoft-Addons klappte es nicht, den Ordner manuell zu ändern.

    Ich glaub, das betraf auch irgendein OMSI-Addon.

    Das gleiche Problem gabs auch mal beim Train Simulator und da hatte ich damals irgendwo ne Lösung gefunden, bei der das Installationsverzeichnis des Spiels direkt in der Registry eingetragen wurde.

    Auf die Schnelle fand ich gerade diese Seite, die das beim Train Sim beschreibt https://rail-sim.de/wiki/index.php?title=Registry_Eintrag

    In meiner Registry hab ich bei OMSI unter Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Aerosoft\OMSI 2den Eintrag Product_Path.

    Prüf doch mal, ob es den Eintrag bei dir gibt (falls du noch ein 32bit-System müsste es der Pfad ohne den WOW...-Unterordner sein) und ob dort der richtige Installationsort von OMSI eingetragen ist.

    Hab aber heraus gefunden das die Addons in den Einstellungen gar nicht Aktiviert sind. Wie kann das sein.

    Sind das bei den alten Hamburger Addons über Steam gekaufte oder noch die von CD installierten Versionen?


    Falls letzteres müssen die nach der Installation über den "Aerosoft Launcher" aktiviert werden.

    Is it really only Hohenkirchen, where you are missing the passanger voices?

    If yes, it would be unexplainable for me. Hohenkirchen did not use any special voices but the standard ones from OMSI in the Berlin ticketpack folder.


    Did you have made any changes in the ticketpack?


    In the file "OMSI 2\TicketPacks\Hohenkirchen\Hohenkirchen.otp" you'll find the path to the voices.

    It should be (line 28)

    [voicepath]

    TicketPacks\Berlin_1\

    Ansonsten ... wers dennoch weiter mit EEP versuchen will ...

    (Wobei ich gestehen musss, das neue Update noch nicht draufzuhaben, aber das Problem in der Logfile von Th3_John_1337 konnte ich auch mit der bisherigen Version so direkt nachvollziehen.)


    Es waren es zwei X10-Autos, die die Probleme machten. Und genau diese beiden haben in ihrem Verzeichnis im Unterordner "script" eine eigene AI_varlist.txt.

    Während die Standard OMSI AI_varlist.txt durch EEP geändert wurde (und Fahrzeuge, die diese nutzen auch funktionieren) hakt es eben bei alle KI-Autos, die eine eigene AI_varlist.txt haben (z. B. auch die Bremer KI). Beheben lässt sich das aber auch hier recht einfach, indem die fahrzeugeigene AI_varlist.txt am Ende durch eine Zeile mit dem Eintrag Randomsound ergänzt wird.

    Bei meinem Test gerade spuckten die beiden x10er Fahrzeuge danach keine Fehler mehr aus. (und die Bremer hatte ich schon früher mal entsprechend geändert)


    Grundsätzlich ist es aber eben völliger Shit, wie EEP hier vorgeht, da es eben jede Menge KI-Fahrzeuge gibt, die angepasst werden müssten und nicht nur die Standard-OMSI-KI, wie es EEP tut).

    Die saubere Lösung wäre hier nach meiner Meinung nicht die Äderung der Originalskripte, sondern eine Erweiterung für die EEP-Änderungen und die entsprechend vom Pack angepassten Fahrzeuge. Statt aufs Standardfile "Sounds\AI_Cars\sound.cfg" könnten diese einfach auf einen anderen Ordner wie z.B. "Sounds\EEP_AI_Cars\sound.cfg" zugreifen. Auf die Art wären andere Fahrzeuge nicht betroffen. Dadurch greift die Anpassung allerdings dann auch für deutlich weniger Fahrzeuge als jetzt, aber es gäbe eben auch keine Fehler mehr. Und jeder mit ein wenig OMSI-Verständnis könnte sich das auch für weitere Fahrzeuge durch eine simple Änderung des [sound]-Eintrags in der ovh anpassen.


    Wenn der Entwickler nicht mehr zu greifen ist (ich hoffe natürlich, ihm ist nichts passiert) ist das einfach die Aufgabe von Aerosoft, das Pack endlich so zu ändern, dass es nicht dauernd mit anderen Elementen von OMSI kollidiert.

    fLoMsi

    Wäre vielleicht mal noch einen Versuch wert, die EEP-Cummulus_1-Datei quadratisch zu verzerren ... Die anderen nicht quadratischen* waren zusätzliche Dateien vom EEP - die "Cumulus_1.tga dagegen die einzige wo EEP eine quadratische Originaldatei durch eine andersformatige ersetzt hatte.


    *und obwohl die weiterhin in 1024x512 im Ordner sind, flackert ja nichts mehr.

    Hmm ... bei mir hatte es trotz Verkleinerung der größeren Wolkenbilder auf 1024x1024 bzw 1024x512 (waren ja nicht alle quadratisch) immer noch geflackert (niedriger Sonnenstand, fast wolkenloser Himmel).


    Irgendwo stand hier mal im Forum, dass die "Cumulus_1.tga" das Problem sei. Seit ich EEP-Version durchs OMSI-Original ersetzt hab, sind die Cummulus-Wolken zwar wieder hässlicher - geflackert hats aber nicht mehr.

    Abend, eine Frage, hat Hohenkirchen schon eine Postleitzahl? Habe nämlich bisher dazu noch nichts gefunden.

    (Bräuchte diese für ein Repaint)

    Eine 9988X-PLZ war von Tobi ja durch die Adresse der Stadtwerke Herrenhof vorgegeben. Für Hohenkirchen dachte ich dann 9989X.

    99891 und 99893 hab ich auf den Repaints bereits verwendet. 91 sollte im Zentrum sein 93 ist eine Straße der Tour Richtung Flughafen

    Ich vermute mal das heißt Haltestellenbremse aktiv.

    Kann ich gerade nicht ganz ausschließen, dass die beim Speichern tatsächlich wieder aktiv war. Ich hatte sich vorhere mehrfach aktiviert/deaktiviert ohne dass der Bus losfahren wollte.


    Als ich die Situation gerade neu geladen hatte, war die Haltestellenbremse allerdings gelöst. Beim Speichern diesmal defintiv auch.

    Eine 1 hab ich nun zwar nicht mehr in der laststn ... aber fast


    bremse_halte

    0.99999998430675

    bremse_halte_sw

    0


    (Und der Bus bewegte sich auch nach dem Neuladen Situation nicht mehr)




    cockpit_light_bremse_halte

    hat übrigens in beiden gespeicherten Situationen der Wert "0", was ich als als Kontrollampe aus - also laut Cockpit Haltestellenbreme nicht mehr aktiv interpretieren würde.

    Die "H"s an den Rädern im Display bleiben aber - die Bremse löst sich also einfach nicht mehr beim Gasgeben, obwohl sie es sollte.

    Ich brauche bitte mal ein Save von so einer Situation, die log hilft da nicht weiter.

    Habs gerade auch mal auf Krefrath getestet ... und auch bei mir mag sich der Bus nach ein paar Haltestellen nicht mehr bewegen (Haltestellenbremse löst nicht mehr).


    Mit Situation meinst du doch die laststn.osn - oder?

    Habs direkt vor OMSI-Beenden gespeichert


    laststn.txt


    (Dateiendung von osn auf txt geändert, um es hochladen zu können)

    Fehler bei Bereichsprüfung: CV.Calculate - J2 (vehicles\xxx.bus)

    tritt bei mir auch bei Berlin 300 nun auch ganz massiv auf. (XXX weil es nicht nur der Urbino ist, sondern ein beliebiger oder auch mehrere AI-Busse). Beim letzten Spielversuch hatte ich da in paar Minuten über 10000 Logfile-Zeilen voll.


    Vor Berlin 300 trat das aber auch schon bei St. Servan auf. Vorher find ich keine Fehler in der Log und ab irgendeinem "Information: Try placing random bus:" gehts dann halt los mit dem obigen Fehler. Bei St. Servain, wo ich das seit ein paar Wochen nachverfolgt habe, aber nicht jedes Mal und auch nicht immer der gleiche Bus .. also in einem Spiel taucht der Bus problemlos als KI auf, im nächsten wird dann plötzlich wieder massenhaft der Fehler ausgespuckt.


    Bei irgendeiner anderen MAP (hab leider vergessen, welche), betraf das neben Bussen auch KI-Züge.


    Ich versuch da gerade rauszukriegen, on das ein grundsätzliches Problem ist, oder ob nur bestimmte Maps betroffen sind. Aus Zeitmangel geht das gerade nur sehr zäh.

    Zumindest kann ich schon sagen, dass der Fehler weder bei Aachen noch bei Yorkshire Countries auftritt.