Hab den Fehler seit eben auch einmal gehabt.
Schön Hamburg T&N (V2.01) gefahren und eine Station hinter Dammtor (Richtung Hbf) kam das kleine Fehlerfenster und das Thema hatte sich erledigt --> OMSI 2 Absturz
Auslastung des VRAM liegt bei 1,5 - 1,8GB/3GB (wurde anhand von Trixx überprüft).
btw: der Fehler ist auch auf eine falsche Logik in der Speicherreservierung zurückzuführen.
http://support.microsoft.com/kb/2627259/de (das es da um ein anderes Windows und ein AVI File geht, ist irrelevant)
Was heißt das nun für betroffene...? Gibt es dafür schon eine Lösung...? (Sorry, wenn ich da so blöd frage, aber auf DEM Gebiet kenne ich mich nun grad mal überhaupt nicht aus, und der Link führt ja nur zu Lösungsvorschlägen bei AVI-Files...)
Bei mir hat es geholfen den 4GB-Patch drüber zu bügeln
Aber wenn ich das richtig sehe, dann optimiert der 4GB-Patch doch eher den Arbeitsspeicher...? Bringt der auch was bezgl. Grafik...? Schließlich kommt diese Meldung ja bei zu wenig Grafikkartenspeicher...
Ich habe es heute mit der Option "Reduziertes Multithreading" probiert und keinen einzigen Absturz oder Fehler gehabt bis jetzt bei HH T&N.
M-RV 5050, nicht zwingend, wie in meinem Beitrag weiter unten verlinkt, kann es auch von einer falschen logischen Speicherreservierung herrühren.
(Ja ich weiß, da geht es um ein anderes Windows und AVI Files, was aber irrelevant ist, da es auch den Fehler betrifft).
EDIT:
Jetzt habe ich das Spiel mal 10 Minuten am HBF ZOB Pausiert und nachdem ich die Pause beendet habe, kam wieder der Fehler der aber diesmal ohne Absturz weg geklickt werden konnte.
Dabei ist mir ein neuer Fehler untergekommen und wohl der Grund für beide Fehler:
Es muss also an der Oma liegen, da der Fehler immer dann auftaucht, wenn sie sich in der nähe oder im Bus befindet (sie bleibt auch weiß als einzigste).
Und gerade sparsam soll sie ja nicht sein und ich schätze das DirectX (oder das Spiel selber) somit einen Fehler in der Speicherreservierung verursacht und die Fehlermeldung(en) ausspuckt (vielleicht wird der Speicherbedarf als zu groß geschätzt, z.B. statt 4MB dann 4GB und es kommt die Fehlermeldung outofmemory-, und anschließend die d3dxerr_invaliddata Meldung, da der wert beim Auslesen nicht mehr stimmt).
PS: VRAM ist zum Zeitpunkt der Fehler immer nur zu max. 1,8GB/3GB belegt und bevor ich pausiert habe, bin ich eine komplette Schicht auf der 109 gefahren und es passierte nichts.
Und gerade sparsam soll sie ja nicht sein
Kann ich nicht behaupten, meistens will sie nur eine Kurzstrecke.
Im Ernst: Wieso sollte die Oma so viel mehr Ressourcen verbrauchen als z.B. der voluminöse Manfred?
ZitatIm Ernst: Wieso sollte die Oma so viel mehr Ressourcen verbrauchen als z.B. der voluminöse Manfred?
Das geht sogar mit einem kleinen Mülleimer. Modell und/oder falsches Texturformat können schnell Fehler verursachen. Alles schon gehabt...
ZitatIm Ernst: Wieso sollte die Oma so viel mehr Ressourcen verbrauchen als z.B. der voluminöse Manfred?
Weil ich hier schon öfter gelesen habe, das sie und das Kind ziemlich Performance fressend sein sollen.
Das geht sogar mit einem kleinen Mülleimer. Modell und/oder falsches Texturformat können schnell Fehler verursachen. Alles schon gehabt...
Dass es möglich ist, ist mir schon klar. Aber welche konkreten Hinweise gibt es darauf?
Dass es möglich ist, ist mir schon klar. Aber welche konkreten Hinweise gibt es darauf?
Diesen
Hab gerade mal nachgesehen: Die Body-Textur für die Oma ist gut 2 MB groß (und hat 2048 x 2048 Pixel) und damit tatsächlich wesentlich größer als die den den anderen Menschen. Welchen Sinn hat das? Fehler der Entwickler?
Und darin dürfte der Fehler liegen, denn ich schätze mal, das OMSI 2 dem Treiber bzw. DirectX sagt das sie größer ist als sie eigentlich ist (z.B. 4096x4096) und beim Auslesen der Fehler kommt, da sie in Wirklichkeit nur 2048x2048 ist.
ODER durch die Pause von ca. 10 Minuten sagt OMSI 2 nicht mehr das die Textur geladen ist, sondern schiebt sie immer weiter in den Speicher und DirectX sagt dann irgendwann "Stopp, hier liegt zu viel, ich weiß nicht mehr was nun wo hin gehört" und wirft den Fehler aus.
ich schätze mal, das OMSI 2 dem Treiber bzw. DirectX sagt das sie größer ist als sie eigentlich ist (z.B. 4096x4096) und beim Auslesen der Fehler kommt, da sie in Wirklichkeit nur 2048x2048 ist.
Du meinst OMSI macht die ohnehin zu große Textur noch größer? Der Fehler weist doch auf zu geringen Speicher hin und nicht auf eine Diskrepanz zwischen OMSI-Angaben und dem, was DirectX vorfindet. Zumal ich eh nicht glaube, dass OMSI so mit DX kommuniziert und so ja eher zu viel Speicher für die Textur reserviert würde als zu wenig.
Du kannst ja mal ein Backup von den Oma-Texturen machen und sie kleiner speichern, z.B. 512x512 wie die Körpertexturen der anderen Menschen.
Du meinst OMSI macht die ohnehin zu große Textur noch größer? Der Fehler weist doch auf zu geringen Speicher hin und nicht auf eine Diskrepanz zwischen OMSI-Angaben und dem, was DirectX vorfindet. Zumal ich eh nicht glaube, dass OMSI so mit DX kommuniziert und so ja eher zu viel Speicher für die Textur reserviert würde als zu wenig.
OMSI bzw. die Spiele Kommunizieren auch mit DirectX, der Treiber ist nur die Schnittstelle.
Und outofmemory kann nur kommen, wenn der Speicher zu voll ist und das kann durch die Textur der Omi passieren, in dem OMSI fröhlich die Textur immer weiter in den Speicher knallt, bis dieser voll ist und DirectX dann die Fehlermeldung ausspuckt.
Und wie gesagt, ist das nur nach der Pausierung aufgetreten und da denke ich hat OMSI 2 einen Fehler drin, in dem es die Textur weiter in den Speicher schaufelt.
Du kannst ja mal ein Backup von den Oma-Texturen machen und sie kleiner speichern, z.B. 512x512 wie die Körpertexturen der anderen Menschen.
Hab sie auf 1024x1024 verkleinert und schon sind sie "nur" noch knapp 750kb groß, aber Testen konnte ich es noch nicht, da es gestern einen kleinen Disput zwischen Mageninhalt und Porzellanthron gab und die Nachwirkungen noch etwas anhalten.
OMSI bzw. die Spiele Kommunizieren auch mit DirectX, der Treiber ist nur die Schnittstelle.
Dass OMSI mit DirectX kommuniziert weiß ich. Jedoch frage ich mich, ob OMSI DirectX die Größen der Texturen mitteilen muss. Das kann DX schließlich auch selbst Anhand der Daten ermitteln. Allerdings habe ich mich noch nicht direkt mit den Schnittstellen von DirectX befasst.
Und outofmemory kann nur kommen, wenn der Speicher zu voll ist und das kann durch die Textur der Omi passieren, in dem OMSI fröhlich die Textur immer weiter in den Speicher knallt, bis dieser voll ist und DirectX dann die Fehlermeldung ausspuckt.
Jede Textur(-datei) sollte eigentlich nur einmal im Speicher sein. Würde mich sehr wundern, wenn das bei OMSI anders ist als bei anderen Spielen/Engines. Das wäre eine riesige Ressourcenverschwendung.
Wenn dem so wäre, dann müsste OMSI die Omi nicht größer machen, als sie ist. Denn wie gesagt, die Textur ist bereits real viel größer als bei den anderen Menschen.
Und wie gesagt, ist das nur nach der Pausierung aufgetreten und da denke ich hat OMSI 2 einen Fehler drin, in dem es die Textur weiter in den Speicher schaufelt.
Du meinst wegen der Pause lädt OMSI die Textur mehrfach in den Speicher? Aber warum nur bei der Omi in Hamburg und nicht auf anderen Maps und mit anderen Texturen? Bei Fahrzeugen gibt es ja ähnliche Größen.
Hab sie auf 1024x1024 verkleinert und schon sind sie "nur" noch knapp 750kb groß, aber Testen konnte ich es noch nicht, da es gestern einen kleinen Disput zwischen Mageninhalt und Porzellanthron gab und die Nachwirkungen noch etwas anhalten.
TMI!
Du meinst OMSI macht die ohnehin zu große Textur noch größer? Der Fehler weist doch auf zu geringen Speicher hin und nicht auf eine Diskrepanz zwischen OMSI-Angaben und dem, was DirectX vorfindet. Zumal ich eh nicht glaube, dass OMSI so mit DX kommuniziert und so ja eher zu viel Speicher für die Textur reserviert würde als zu wenig.
Na irgendwie muss es ja zu dem Fehler kommen und das kann normal nur passieren wenn der Speicher unnötigerweise zugeknüppelt wird.
Dass OMSI mit DirectX kommuniziert weiß ich. Jedoch frage ich mich, ob OMSI DirectX die Größen der Texturen mitteilen muss. Das kann DX schließlich auch selbst Anhand der Daten ermitteln. Allerdings habe ich mich noch nicht direkt mit den Schnittstellen von DirectX befasst.
Der Speicher muss ja Reserviert werden und OMSI 2 direkt wird es nicht können, sondern muss wie alle den Umweg über die 3D API (DirectX, OpenGL etc.) und den Treiber nehmen.
Jede Textur(-datei) sollte eigentlich nur einmal im Speicher sein. Würde mich sehr wundern, wenn das bei OMSI anders ist als bei anderen Spielen/Engines. Das wäre eine riesige Ressourcenverschwendung.
Wenn dem so wäre, dann müsste OMSI die Omi nicht größer machen, als sie ist. Denn wie gesagt, die Textur ist bereits real viel größer als bei den anderen Menschen.
Sollte, aber durch einen Fehler kann es passieren das eine Textur öfter in den Speicher gelegt wird.
Du meinst wegen der Pause lädt OMSI die Textur mehrfach in den Speicher? Aber warum nur bei der Omi in Hamburg und nicht auf anderen Maps und mit anderen Texturen? Bei Fahrzeugen gibt es ja ähnliche Größen.
Vielleicht treffen da zwei Umstände aufeinander, die ohne das AddOn nicht zustande kommen.
Wer weiß das schon, jedenfalls sieht man ja am Ausschnitt des Logfiles, das die Omi nach der Pause schuld ist am DX Fehler
TMI!
Aber berichte mal, wenn du es ausprobiert hast.
Also OMSI wird mit der kleineren Textur der Omi schon mal viel geschmeidiger, nur mit dem Pausenmodus hab ich es noch nicht probiert.
Danke für euren Hinweis! Ich werde mir das sofort ansehen und dann für den nächsten Patch korrigieren.
Außerdem kann ich verraten, dass OMSI jeden Texturpfad nur einmal in den Speicher lädt. Zugegeben heißt das aber, dass gleichnamige Texturen aus verschiedenen Ordnern trotzdem doppelt geladen werden, weil OMSI ja nicht wissen kann, ob die Textur gleich aussieht oder nicht.
Danke, Marcel. Wie gesagt, hätte mich etwas anderes auch sehr an euch zweifeln lassen.
Na irgendwie muss es ja zu dem Fehler kommen und das kann normal nur passieren wenn der Speicher unnötigerweise zugeknüppelt wird.
Das geht auch, wenn der Speicher nötigerweise zugeknüppelt wird. Wenn die Map aufgrund ihres Umfangs und den Einstellungen einfach viele Ressourcen braucht und der Rechner in der aktuellen Situation (die ja auch von anderen Programmen beeinflusst wird) nicht genug bietet. Womit ich nicht sagen will, dass das hier der Fall ist. Jedoch können wir nur spekulieren, daher ist es gut, dass M&R sich das ansehen werden und wir können damit aufhören.
Ich finds auch gut das sich Marcel dazu geäußert hat
Bis auf den Fehler, kann ich mich über OMSI 2 nicht groß beschweren, läuft im Moment 1a (wenn man von eher kleinen wehwehchen hinweg sieht die aber eher nebensächlich sind).
btw: wer wissen will womit sich OMSI, OMSI 2 und andere spiele abgeben müssen: http://www.sysprofile.de/id4237
Neu erstellte Beiträge unterliegen der Moderation und werden erst sichtbar, wenn sie durch einen Moderator geprüft und freigeschaltet wurden.
Die letzte Antwort auf dieses Thema liegt mehr als 182 Tage zurück. Das Thema ist womöglich bereits veraltet. Bitte erstellen Sie ggf. ein neues Thema.
