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!

    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.



    Mir fielen noch ein paar Fehler auf, falls die nicht eh schon bekannt sein sollten:



    Die Ausfahrt vom Ostbahnhof. Hier hing ich schon mehrfach völlig fest, da aufgrund dauerhaft gefüllter Straße die KI Busse nicht weiterkamen.

    Das Problem dürfte auch daran liegen, dass die umkreiste Ampel vom KI-Verkehr ignoriert wird. Wenn da was nachfliest, fahren die trotz "Rot" durch und die Kreuzung wird nie leer.



    Endhaltestelle Philharmonie. Hier sollten die Pfade noch mal überarbeitet werden. Die KI rammt seitlich in den stehenden Spielerbus.




    Endhaltestelle Warschauer Str.: Nur eine kleine Unschönheit - da blitzt UNTER dem Haus Himmel durch




    Und das letzte ist keine Fehler an sich, aber etwas was mich ziemlich nervt. Dass nicht überall Originalhäuser stehen können ist ja ok. Aber dann ein anderes Haus so zu versenken, dass die Balkone auf dem Gehweg liegen ... sowas killt bei mir sofort jeglichen Eindruck von realer Umgebung.

    Ich hatte mal spaßenshalber versucht, bisher noch nicht existierende Linien anhand der Haltestellenbeschriftungen und teils schon existierender Hiflspfeile abzufahren ... und zumindest eine Linie (Nummer hab ich gerade nicht mehr im Kopf) scheint von den Straßen schon komplett zu existieren. Da fehlts halt noch etwas an Gebäuden und Ausgestaltung, aber die sollte eigentlich ohne größeren Aufwand noch integrierbar sein.

    Bei der Linie 2 gibts eine Unterbrechung direkt nach Beaulieu Rosa Parks - der ganze Rest der Straßen bis zum Hotel ist dagegen wohl auch schon da.


    Ich freue mich auf alle Fälle, wenn an der Map noch gearbeitet wird, denn ich find die wirklich sehr schön gemacht.

    Dass der KI Verkehr dagegen wirklich furchtbar ist und es unmöglich ist, mit Kollisionen zu fahren, hatte ich hier glaub ich schon mal bemängelt. :whistling:

    Es scheint etwas mit dem Sound der KI-Autos nicht zu stimmen.

    Du hast wahrscheinlich auch das Enhanced Enviroment Pack - oder?


    Der Fehler mit den "SoundSort Fail: Invalid distance calculation!..." ist hier im Forum schon öfter im Zusammenhang mit dem EEP erwähnt wurden. Da wurde wohl was an der KI verändert - aber eben nur für die Standard-OMSI-Autos angepasst, so das andere KI-Fahrzeuge nicht mehr fehlerfrei funktionieren.


    Lösung: EEP deinstallieren oder mal im Forum suchen (es reicht auch nur ein paar der vom EEP veränderten Dateien wieder in den Originalzustand zu versetzen).

    Zur Mauertextur: Grundsätzlich denk ich, die Auflösung reicht ... mit der Ausnahme direkt an der Haltestelle. In einem Video war da der Blick aus der Fahrertür auf die Mauer zu sehen und aus der geringen Entfernung war das nur noch Pixelmatsch. Insofern würde ich zumindest für die direkt an der Haltestelle sichtbaren Elemente eine höhere Auflösung vorschlagen.


    Und was hier vorher auch schon erwähnt wurde: fahrende E-Scooter (bzw. auch Fahrräder). Das letzte Hamburg hat gezeigt, dass auch das in OMSI möglich ist. Ich mach mir bei dem fortgeschrittenen Stand des 300-Addons zwar keine Hoffnung mehr ... aber ich find das extrem schade, dass das hier nicht umgesetzt wurde. Gerade in dem Berliner Gewimmel gehört das unbedingt dazu.

    Selbst wenn ihr keine eigenen animierten Fahrräder/Scooter bauen solltet ... wenn zumindest entsprechende Pfade gelegt wären, um die in die Hamburger Räder in die ailist aufzunehmen, wäre das doch zumindest etwas.

    An den cti-Dateien kann es eigentlich nicht liegen, da es ja bei 90% aller installierten Repaints das Problem gibt...

    Doch kann es.

    Ein falsches Repaint reicht.


    Ganz dumpfe Erinnerung (und damit ohne Gewähr auf Richtigkeit) an einen vor vielen Jahren mal gelesenen Beitrag aus dem alte Forum: OMSI zählt die Repaints intern einfach nur durch. Wenn da dann irgendwo ein Fehler ist (ich vermute ein fehlendes Front oder Heckteil in der cti) wird einfach das nächste genommen und dadurch ist das dann auch für alle weiteren Repaints verschoben.

    Bamp

    Öhem ... peinlich. :huh:

    Hab die ganze Zeit deinen Server als Test genutzt, in der Annahme, dass es Niles ist (hatte irgendwie einfach den letzten Link auf der vorherigen Seite kopiert.)



    Aber sind es wirklich die https-Einstellungen?

    Bei meinem Server, wo es mit http funktionierte, gibts zwar https - aber keine Zwangsumleitung, wenn http aufgerufen wird.

    Bei dir mit media. wird https erzwungen und es klappt nicht.

    Bei Nile schein dagegen kein https erzwungen zu werden - trotzdem klappt es bei ihm nicht.


    Für heute reichts. Morgen kann ichs gern selbst nochmal direkt mit Niles Server versuchen

    Code: itx
    http://http.omsi-tools.de/itx-test.tga            ---Geht
    Sceneryobjects\niletest\texture\1.tga
    
    https://media.omsi-tools.de/itx-test.tga          ---Geht nicht
    Sceneryobjects\niletest\texture\2.tga


    Hier ist der Unterscheid aber mehr als nur http/https (ich hatte es ja auch mit http bei Nile versucht)


    Das was funktioniert hat ja gar nicht mehr die Subdomain "media.", sondern stattdessen http als Subdomain ???

    Hier müsste es ja unter den Admins doch ein paar geben, die von Servern im Gegensatz zu mir Ahnung haben. ;) Vielleicht hat da einer einen Tipp.

    Allerdings ist das mit Sicherheitsrestriktionen eh nur eine reine Vermutung von mir - aber ich wenns auf einem Server geht und auf dem anderen nicht, muss es ja irgendeinen Grund haben.

    Hatte ich ja geschrieben ... bei deinem Server hats so nicht funktioniert.

    Bei meinem eigenen dagegen schon. (Der Link stand nun nicht im Beitrag - aber wenn du es testen willst schreib das in itx. Noch liegt die Datei dort. Und wahrscheinlich müssen auch die Ordner "Sceneryobjects\niletest\texture\" in OMSI vorhanden sein. Kannst aber natürlich genauso nur den Link ändern und den Ruede-Ordner wie bei dir stehen lassen.)

    Code
    http://grakl.de/OMSI/itx-test.tga
    Sceneryobjects\niletest\texture\nile.tga


    Zumindest sollte so eben klar sein, dass das Problem weder OMSI, noch die Datei ist, sondern dein Server. Möglicherweise irgendwelche Sicherheitseinstellungen, die die OMSI-Anfrage blocken.

    Ich habs gerade auch mal mit deiner Datei versucht und dazu schnell eine neue "nile.itx" geschrieben

    Code
    http://media.omsi-tools.de/itx-test.tga
    Sceneryobjects\niletest\texture\nile.tga
    
    https://media.omsi-tools.de/itx-test.tga
    Sceneryobjects\niletest\texture\nile_s.tga

    (mal beide Varianten versucht ... nicht dass OMSI nur kein https mag)


    Ergebnis war das gleiche erfolglose wie bei dir. (Information: Problem while getting file...)


    Dann hab ich deine direkt mit dem Browser heruntergeladene tga-Datei auf meinen Server gepackt, den Link in der itx auf meinen Server geändert ... und die Datei wurde sofort beim OMSI_Start (der dann auch wieder etwas schneller war) problemlos runtergeladen und im gewünschten Ort im OMSI-Verzeichnis gespeichert.


    Ich vermute, dass dein Server aus irgendwelchen Gründen die Anfrage von OMSI blockt.

    Fehlersuche also wohl nicht bei OMSI, sondern bei deinen Servereinstellungen.

    Steam-Aktivierung der alten CD-Addons geht soweit ich weiß nicht.

    Du solltest dein Addon aber bei Aerosoft registrieren können und die aktuelle Version (die eh neuer sein dürfte, als die auf der CD) dann als als Installations-exe-Datei herunterladen können.

    War bei mir auch so ... obs damit zusammenhängt kann ich aber nicht sagen.

    Auf alle Fälle kommen diese Überprüfungen immer häufiger.
    Jahrelang gar nix, dann 1-2 im Jahr und nun gefühlt bei jedem 2. Addon-Kauf oder Update.
    Es nervt wirklich tierisch.

    Ja, das ist eine Steam Sache. Der Client prüft offenbar, welche Daten da sein sollten und welche da sind.
    Wenn das differiert, dann kommt eine Überprüfung. Darauf haben weder wir noch Aerosoft aber Einfluss, das betrifft nämlich alle Steam Produkte.

    Die Theorie würde ich auch eher ausschließen. Würde Steam immer prüfen würde die Sache auch jedes mal passieren. (ich überschreib ja auch sofort danach wieder diverse OMSI-Original-Dateien).
    Was die Überprüfung aber wirklich auslöst ist mit auch ein Rätsel.