Generelle Fehlerliste aktueller Patch

Das Forum befindet sich im reduzierten Betrieb. Die Addon- und Supportforen bleiben weiterhin verfügbar.
Bitte beachte, dass OMSI nicht mehr weiterentwickelt wird. Ein Teil der Entwickler widmet sich inzwischen der Entwicklung eines neuen Simulators. Weitere Informationen zum LOTUS-Simulator findest Du hier.
Ein communitybetriebenes Nachfolge-Forum wird hier verlinkt, sobald es gegründet und bereit ist.
    Zitat von HBW


    Die Fehler die wir hier ansprechen sind aber globale Fehler, daher ist es unerheblich ob Spandau die Referenzkarte ist oder nicht.


    Dann muss man die Fehler aber auch global benennen und nicht mit der Mönckebergstraße als Beispiel kommen.

    ;)

    U-Bahn fahren heißt Zeit ersparen!

    Wobei ich auch noch finde, dass man zwischen Fremdcontent und Fremdcontent unterscheiden muss. Einerseits gibt es die Payware-Addons, die offiziell im Handel erschienen sind und von Leuten gekauft werden, die einfach nur spielen wollen, aber weder dieses Forum kennen, noch Ahnung von Downloads etc. haben, zumindest außerhalb von Steam und Aerosoft. Diese muss man definitiv testen und zur Fehlerbeseitigung heranziehen, immerhin sind sie offiziell lizensiert und als offizielle funktionierende Addons angepriesen und die Kunden zahlen eine Menge Geld dafür.



    Dann gibt es natürlich den Freeware-Kram. Das ist klar, dass man hierfür null Support geben kann, da die Qualität mächtig schwankt und außerdem verbietet dies schon die Fülle. Diese Sachen wird aber der normale Durchschnitts-Käufer niemals haben, daher irrelevant.


    Also wie gesagt, wir testen auf Hamburg, einem offiziell lizensierten Addon...
    Aber... Sämtliche Fehler sind zu 100% auf Spandau reproduzierbar. Wenn gewünscht, kann ich mich in der nächsten Woche darum kümmern und versuchen, diese Fehler dort zu reproduzieren...


    Gruß
    Carsten

    Zitat

    Einerseits gibt es die Payware-Addons, die offiziell im Handel erschienen sind und von Leuten gekauft werden, die einfach nur spielen wollen, aber weder dieses Forum kennen, noch Ahnung von Downloads etc. haben, zumindest außerhalb von Steam und Aerosoft. Diese muss man definitiv testen und zur Fehlerbeseitigung heranziehen, immerhin sind sie offiziell lizensiert und als offizielle funktionierende Addons angepriesen und die Kunden zahlen eine Menge Geld dafür.

    Da muß ich Dich enttäuschen. Jeder Dödelkopp kann ein AddOn entwickeln und dies über einen Publisher vertreiben lassen. Sicherlich gibt es im Sinne des Publishers (und als Selbstverstäbdlichkeit) Betatests (und diese mal schlecht und mal recht)
    Aber sie sind überhaupt kein Garant, dass sie Fehlerfrei sind bzw. auch nur irgendeinen Qualitätsstandard seitens M&R haben. M&R haben mit den AddOns nichts zu tun. Wenn in Hamburg ein falsches performancefressendes Texturformat gewählt wurde (wissentlich oder unwissendlich) so kann dies schon zu den bekannten Fehlverhalten führen. Daher sollte und kann seitens M&R ja nur Spandau als Referenz herhalten. Sicherlich wird man bei Fehlern auf anderen Maps nicht weggucken.


    Zitat

    Also wie gesagt, wir testen auf Hamburg, einem offiziell lizensierten Addon...

    Das einzige was lizensiert wird ist, dass Du den Namen Omsi nutzen darfst etc. Mehr nicht.

    Zitat von some1

    Was ich persönlich auch sehr, sehr störend empfinde sind die ständigen Direct3D-Device lost! Fehler.


    Dafür kann es viele Ursachen geben. Treiber, Windows, Grafikkarte (oder die Kommunikation zwischen allen dreien) - oder vorherige Grafikfehlermeldungen (weiße Texturen, zu wenig Arbeitsspeicher). Das lässt sich schwer eindämmen und zum Reproduzieren muss ich wohl nichts sagen

    ;)


    Zitat von ACMG

    Was: Wie gesagt konnte ich das bisher nur bei Gelenkbussen beobachten, darunter auch der GN92.


    Danke für den Hinweis, das ist ja ein Anhaltspunkt.


    Zitat von Prökelstudio

    Mit Shift+Z Status anzeigen und einfach bei der ganzen Aktion den Texturspeicherbedarf beobachten... er wird nur steigen und selten wieder sinken, bis er sich komplett füllt.


    Stelle Dich doch bitte mal an den Rand der Karte und schaue mit der Kamera ins Nichts (weg von der Karte), sodass man nichts mehr sieht. Dann bleibst du 30 Sekunden in dieser Position. Dabei sollte der Wert wieder sehr stark absinken. Passiert das nicht, bitte ich um genauere Infos - aber erst wenn Du das getestet hast!


    Zitat von Prökelstudio

    Es geht hier um Variante A. Man stelle sich in Hamburg an den Bahnhof Altona.


    Das ist so konkret, dass wir uns das lieber mal zusammen mit Darius angucken, der seine Karte sicher besser kennt, als wir.


    Zitat von Prökelstudio

    Alles was nicht Spline ist, also beispielsweise Kreuzungen. Dies könnt Ihr ganz simpel reproduzieren.


    Ok.


    Zitat von HBW

    Fremdkontent hin oder her - Omsi wurde so entwickelt, das sich jeder eigene Maps bauen kann nebst selbsterstellten Zubehör, Fahrzeugen usw.


    Es gibt einen entscheidenden Haken, den Du übersiehst. OMSI ist so konzipiert, dass jeder Maps, Mods und Fahrzeuge bauen kann. Aber OMSI ist nicht failsafe gebaut. Es gibt keinen Hinweis, wenn man unbedacht an den Editor geht, "einfach loslegt" und dabei alles falsch macht. Dann passieren die Fehler, keiner weiß, warum. Das Problem ist also viel mehr das Fehlen von Checks durch OMSI selbst, ob diese Karte/das Objekt/... so etwas taugt, oder ob es OMSI oder das System in die Knie zwingen wird.

    Zitat von Prökelstudio

    Alles was nicht Spline ist, also beispielsweise Kreuzungen. Dies könnt Ihr ganz simpel reproduzieren. Ihr seid ja im Besitz des Drei-Generationen-Addons. Darius hat ja beim Citaro C2 einen Doppelgelenkbus mitgeliefert mit Schwächen. Diese Schwächen könnte man mildern. Setzt bitte diesen Bus in die Ailist von Grundorf als Fahrzeug der Linie 76 ein. Vorher geht Ihr bitte in jede .bus Datei der drei Wagenteile und fügt "[Type] 2", damit das Fahrzeug faktisch ein Schienenfahrzeug wird. Da OMSI aber egal ist, dass Schienenfahrzeug nicht auf Asphalt fahren können, kann man diesen "Doppelgelenkzug" nun als normale BUS-KI fahren lassen. Nachteile: Der Bus wird nicht mehr von den Haltestellenwürfeln angezogen und die Gelenkanimation funktioniert nicht mehr richtig, aber dafür knicken alle drei Wagenteile vorbildgerecht. Ihr werdet sehen, dass der Bus, wenn er auf einen Spline gesetzt wird, vollkommen vollständig ist, sobald er aber ein Kreuzungsobjekt passiert, werden die beiden hinteren Teile ins Nichts verschwinden. Probiert es aus.


    Funktioniert es denn auf Eisenbahnschienen? (Ich habe nicht vor, mir 3 Gen. zu kaufen) Der Fehler kann daran liegen, dass bei Kreuzungen z.T. sogar bis zu 3 Pfade aus einem einzigen Pfad herauskommen. Bei Eisenbahnschienen gibt's ja die Weiche.


    Zitat von Grenko

    Man muß an der Basis arbeiten. Du kannst nicht nach Fehlern suchen wenn User Fremd-Content und dazu zig Mods installiert haben. Auch AddOns können nicht verbindlich als Anhaltspunkt genommen werden, da den Entwicklern nicht bekannt ist wie Darius im Detail gebaut und programmiert hat. Kein Entwickler kann Support für Fremd-Content geben bzw. dort nach Fehlern suchen. Für Omsi2 ist stets Spandau die Referenzkarte.


    Das sehe ich etwas anders: Klar, für OMSI ist Spandau der Maßstab. Es ist aber bei manchen Problemen sehr interessant, wie diese auftreten. So habe ich z.B. bis 2.1.004 ein Kollisionsproblem gehabt, immer am Übergang zwischen Spline und Objekt (aber nicht in Spandau). Soll heißen, dass die Entwickler sich diesen Fehler trotzdem angeschaut haben, und behoben haben. Marcel schrieb im Dezember mal, dass OMSI als Quelloffener Simulator gedacht ist. Unter Quelloffen verstehe ich auch, dass Fremdcontents (unter der Voraussetzung, dass diese fehlerfrei gebaut wurden) funktionieren.
    Das ist nicht immer der Fall, da jede Karte ein anderes Niveau hat, und auch z.B. bei den Fahrplänen jeder Mapbauer einen individuellen Stil hat. (Manche machen Kreuzungen selber, manche nur die Pfade, und arbeiten mit Terrain Splines, nur um mal ein Beispiel zu nennen.) Deshalb kann man nicht persé nachprüfen, ob diese und jene Karte ein Maßstab ist. Man kann immer nur vermuten, ob der Fehler nur kartenabhängig ist, oder generell vorhanden ist. Nur bei letzterem sollten die Entwickler tätig werden.


    Zitat von Prökelstudio

    Wobei ich auch noch finde, dass man zwischen Fremdcontent und Fremdcontent unterscheiden muss. Einerseits gibt es die Payware-Addons, die offiziell im Handel erschienen sind und von Leuten gekauft werden, die einfach nur spielen wollen, aber weder dieses Forum kennen, noch Ahnung von Downloads etc. haben, zumindest außerhalb von Steam und Aerosoft. Diese muss man definitiv testen und zur Fehlerbeseitigung heranziehen, immerhin sind sie offiziell lizensiert und als offizielle funktionierende Addons angepriesen und die Kunden zahlen eine Menge Geld dafür.


    Dann gibt es natürlich den Freeware-Kram. Das ist klar, dass man hierfür null Support geben kann, da die Qualität mächtig schwankt und außerdem verbietet dies schon die Fülle. Diese Sachen wird aber der normale Durchschnitts-Käufer niemals haben, daher irrelevant.


    Also wie gesagt, wir testen auf Hamburg, einem offiziell lizensierten Addon...
    Aber... Sämtliche Fehler sind zu 100% auf Spandau reproduzierbar. Wenn gewünscht, kann ich mich in der nächsten Woche darum kümmern und versuchen, diese Fehler dort zu reproduzieren...


    Das stimmt schon, es gibt aber hier im Forum auch Mods, die an die Kommerziellen wenigstens ein bisschen herankommen. (Ist übrigens auch ein Grund, warum ich keine Payware habe ;)).
    Die Freeware macht halt die große Hülle & Fülle aus, die es in OMSI gibt, und das finde ich auch gut so. Immer auf Spandau fahren, ist ein bisschen langweilig...
    Dennoch sollte man Freeware nicht unterschätzen.

    Wir sehen uns alle in der WebDisk wieder :-)

    https://reboot.omsi-webdisk.de/community/

    Moin Moin,


    wir werden die nächsten Tage versuchen, nähere Belege für die Fehlerliste aufzuzeigen, um vielleicht gezielter bei der Fehlersuche behilflich zu sein.


    Nach einem anstrengenden OMSI-Test durch HBW und meiner einer hier mal die Belege dafür, dass die Speicherverwaltung von OMSI2 nicht einwandfrei funktioniert. Dies ist auf allen Maps global reproduzierbar!


    Rein theoretisch müsste es möglich sein, sich an einen beliebigen Ort einer Karte zu setzen und dort den Texturspeicherbedarf zu notieren. Wenn man sich jetzt einmal quer durch die Map hangelt und am Ende wieder an den gleich Ort zurückkehrt, sollte eigentlich in etwa der gleiche Texturspeicherbedarf wieder hergestellt sein, da OMSI ja eigentlich alles nicht Benötigte wieder aus dem Speicher entfernen sollte. Dem ist auf keinen Fall so.


    Insbesondere beim KI-Verkehr gibt es viele Hinweise, dass OMSI in diesem Bereich den Speicher nicht wieder korrekt leert. Abhängig von der Zahl der eingesetzten KI-Busse wird sich der Speicher schneller oder langsamer aufblasen.


    Wenn man momentan OMSI startet, werden alle beim Start platzierten Fahrzeuge ohne Fahrerfigur generiert, später im Spiel auftauchende zusätzliche haben größtenteils die Fahrerfigur im Bus.


    Egal wo man sich auf der Map bewegt und diese Fahrzeuge eigentlich nicht mehr im Sicht- und damit im Speicherbereich vorhanden sein sollten, merkt OMSI sich dennoch, ob das jeweilige Fahrzeug einen Fahrer hatte oder nicht. Das Fahrzeug wird also nicht komplett neu generiert, obwohl es eigentlich zwischenzeitlich redundant geworden und aus dem Speicher entfernt sein sollte. Nur der pure Eintrag, dass genau dieses Fahrzeug gerade auf diesem Kurs fährt, sollte eigentlich für OMSI ausreichen, es ist aber irrelevant, sofern das Fahrzeug nicht im Sichtbereich ist, ob der Bus nun einen Fahrer hat oder nicht.


    Gleiches gilt für Fehler, die im Spiel entstanden sind (z.B. zerfetzte Gelenke), denn auch diese Information bleibt fortwährend im OMSI-Speicher, obwohl auch dies irrelevant sein sollte. Schließlich könnte das Fahrzeug, sofern es neu benötigt wird, auch komplett neu generiert und somit auch gleich Fehler beseitigt werden. Vorherige Stati dieses Fahrzeugs dürfen eigentlich nicht im Speicher verbleiben.


    Beispiel: Wenn ein KI-Bus gerade an einer Haltestelle aus dem Sichtbereich herausfährt und Fahrgäste dabei an Bord hat und man sich dann von diesem Standpunkt nicht entfernt, sondern wartet, dass der Bus irgendwann mal zurückkommt, wird man feststellen, dass exakt die selben Fahrgäste wieder im Bus sitzen, nur mit dem Nachteil, dass der Bus jetzt in die falsche Richtung unterwegs ist und die Fahrgäste bis zur Endhaltestelle nicht aussteigen werden, da sie ja eigentlich in die andere Richtung wollten. Da aber außerhalb des Sichtbereichs keine Fahrgäste aus dem KI-Bus aussteigen oder aber
    neue einsteigen, entsteht dieser Umstand.


    Wenn OMSI sich natürlich für jeden Bus außerhalb des eigenen Sichtbereichs die Position der Fahrgäste im Bus ebenfalls merkt, ist es kein Wunder, dass der Speicher immer weiter vollgeladen wird.


    Es mag ja sein, dass OMSI Gebäude- und Kreuzungsobjekte, die nicht mehr im Sichtbereich sind, wieder aus dem Speicher entfernt, bei KI-Bussen funktioniert dies auf keinen Fall.


    Beispiel: Wenn man in OMSI einen Bus neu platziert und dann im Hintergrund z.B. in Paint.Net das Repaint ändert und sich von diesem Bus so weit weg bewegt, dass der Bus außerhalb des Sichtbereiches kommt (hinter der Kachelgrenze) und dann wieder zurück geht, wird automatisch das neue Repaint auf den zuvor mit altem Repaint generierten Bus geladen. Dabei steigt der Texturspeicherbedarf um das neue Repaint an. Daraus ist zu folgern, dass OMSI für jeden Bus, der auf der Karte auftaucht, wieder die Paints neu lädt, das alte aber im Speicher belässt, was sich natürlich multipliziert, wenn der gleiche Bus zig Mal aus dem Sichtbereich herausfährt und später wieder zurück kommt.


    Einzige Lösung ist, dass KI-Busse, die aktuell grade nicht mehr benötigt werden, komplett aus dem Speicher entfernt werden, einzig die einmalig angelegte Info, welches Fahrzeug auf welchem Kurs fährt, sollte ausreichen. Diese kleine Info sollte allerdings selbst bei einer großen Vielfalt an KI-Kursen nicht den Speicher so sehr belasten, dass OMSI sich komplett zuschaufelt.


    Soviel zu diesem Thema.


    Außerdem ist uns im Nachhinein noch folgender Fehler aufgefallen. Seit Version 2.1 werden KI-Busse, die beim Programmstart ins Spiel gesetzt werden, mit etwas Schwung ins Spiel gesetzt, so dass sie teilweise nicht mehr auf den Pausenplätzen stehen bleiben und den Verkehr blockieren, sofern sie grade am Pausieren sein sollten. Sie werden dann am Pausenplatz vorbei geschubst.


    Zusätzlich ist uns aufgefallen, dass wenn man einen KI-Bus per F3 verfolgt, der laut Fahrplan schon mindestens eine Minute Verspätung hat und dann per Menu Uhrzeit/Datum aufruft und einfach mit OK bestätigt, dass der Bus und auch andere Busse plötzlich verschwinden und auch in der Übersichtsliste nicht mehr auffindbar sind. Das liegt daran, dass OMSI checkt, wo dieser Bus in diesem Moment eigentlich sein müsste. Im aktuellen Patch nimmt OMSI den Spieler aber nicht mehr mit.


    Wenn man dann den Bus suchen geht und sich vorwärts durch die Karte hangelt, wird man feststellen, dass der Bus zwar offensichtlich nicht auffindbar ist, aber er trotzdem irgendwie vorhanden ist. Der Bus wird an DFI-Masten z.B. angezeigt und auch Fahrgäste laufen zur angegebenen Zeit an die Haltestelle, obwohl der Bus rein optisch und auf der Liste nicht zu sehen ist. Geht man jetzt von diesem Standpunkt noch weiter voraus und hangelt sich später wieder zurück, wird der Bus dann aber wie von Geisterhand wieder auftauchen.


    Auf die anderen Punkte werden wir die Tage noch eingehen.


    Viele Grüße
    Carsten (Prökelstudio)

    Hallo,


    Nach dem neusten Update, bekomme ich auf jeder Map ca. alle 2 Minuten
    für 10 Sekunden den Ladebildschirm für den AI-Verkehr angezeigt. Das
    nervt ganz schön, und das war vor dem Update definitiv nicht so. Des weiteren ist die Logfile voll mit nicht definierbaren Fehlermeldungen.


    Und das liegt auch nicht an meiner Hardware!!!!So langsam müste OMSI 2 doch mal besser laufen, aber aus meiner Sicht wird es nach jeden Update schlechter. Leider habe ich den Fehler gemacht, mir kein Backup von der letzten Version anzulegen.


    Logfile 15.07.2014 Bezieht sich nur auf die Error Meldung ab 17:27 Uhr


    Spoiler anzeigen




    Gruß



    Viele andere, inklusive mir sind ebenfalls schon auf Bremen gefahren, ohne Probleme, daraus schließe ich das es kein Problem vom Hauptprogramm noch vom aktuellsten Patch ist.
    Ein erster Schritt wäre getan, wenn du eventuell mal die Daten durch eine Steamüberprüfung überprüfst und es anschließend nochmal versuchst Bremen zu starten

    ex OMSI Forum Moderator(circa 6 Jahre :O ).

    Ja, das habe ich bereits gemacht. Diesen Fehler habe ich auch auf der Map, Nürtingen,Velbert,Hamburg Tag und Nacht.
    Und wie ich schon gesagt habe, vor dem Update liefen alle Map`s ohne Probleme.

    Es ist bekannt, dass Steam beim Update häufig installierte Maps/Mods/... zerstört. Hattest Du die Maps, um die es Dir geht, nochmal heruntergeladen und einem frischen, reinen OMSI hinzugefügt?


    Also ich meine folgendes:
    - OMSI deinstallieren inklusive aller geheimen Rückstände und neu installieren, damit die Installation sauber ist!
    - Bremen neu herunterladen und gemäß Anleitung installieren
    - Bremen starten und testen
    -- funktioniert? --> nächste Karte neu herunterladen, ordentlich installieren, testen und nochmal: funktioniert? --> [...]
    -- funktioniert nicht? --> Logfile, Optionen und Systeminformationen hier (im Spoiler bitte) posten.


    Nachtrag:
    Wurden vielleicht Deine Optionen verändert durch das Update (also überschrieben)? Ist der KI-Verkehr vielleicht zu hoch eingestellt, weshalb Du die häufigen Nachladevorgänge vorher nicht hattest?