Beiträge von Eschy5

Matthias68x

Hast du eine Logfile dazu oder hast du dort schon mal reingeschaut? Dein Problem liest sich so ähnlich wie meins. Bei mir sind die verschobenen Objekte weg, seit dem ich die Fonts noch mal installiert und überschrieben habe.

Ich weiß gar nicht mehr, ob ich die Fonts überschrieben habe oder nur fehlende eingefügt habe. Ich werde die jetzt noch mal reinpacken und überschreiben lassen. In den nächsten Tagen berichte ich dann, wie es mit dem Fehler bei Bereichsprüfung: map.translate aussieht.

Edit: Beim Überschreiben der Fonts habe ich eins gefunden, was geringfügig größer war. Alle anderen waren mit Größe, Datum, und Uhrzeit identisch. Anschließend bin gerade noch mal unter fast den selben Bedingungen wie gestern Nachmittag die 163 gefahren, selber Umlauf, selbe Uhrzeit, ein Schlenki aus dem DLC MAN Standardbus II. Nur das Wetter war jetzt besser. Ich hatte deutlich besserere Performance, es waren keine Objekte verschoben, ich hatte keinen Bereichsfehler mehr und selbst die DFI's haben jetzt die Abfahrtszeiten der anderen Busse angezeigt. Scheinbar alles nur wegen einer einzigen Schriftart.

Mir sind auf der Karte auch einige Dinge aufgefallen. Es sind zum Beispiel mehrere fehlerhafte Tracks auf der Karte. Der Editor hat extra unter der Registerkarte "Tracks & Trips" den Button "Find Errors on loaded files", der solche Fehler findet.

Weitere Fehler sind in den Umläufen drin. Hier ein Auszug aus der Logfile:

Den Umlauf 321020 aus Eichenhoehe TA32 Freitag Ferien.ttl habe ich mir zum Beispiel mal angeschaut und dabei herausgefunden, dass die Umsetzfahrt von Hbf D4 zu C1 zeitgleich mit der Linie 164 von Burgschöttel Steig 3 nach Hbf (beide 23:00:00) statt findet. Außerdem zeigen die Abfahrtanzeigen wie am Bernauerplatz zum Beispiel die ganzen Abfahrten ohne Zeiten an. Nur bei der Spielerlinie steht sofort. Ich vermute mal, dass es mit den fehlerhaften Tracks oder Umläufen zusammenhängen könnte.

Den Fehler bei Bereichprüfung: map.translate habe ich häufig in der Logfile und an manchen Stellen verschieben sich die ganzen Objekte um eine Kachel. Hatte ich vorhin mit der 163 an der Universität. Und Folgetour war auch nicht möglich. Ich hatte noch eine angenommen am Grachter Markt. Dort waren ebenfalls alle Objekte verschoben und wenige m nach der Abfahrt ist Omsi eingefroren mit Errors in der Logfile über zu wenig Arbeitsspeicher. Und besonders im Bereich Hbf, wo ebenfalls der Fehler bei Bereichprüfung in die Logfile geschrieben wurde, sprang mein Bus.

Zu diesem Thema kann ich mittlerweile einen Tipp geben.

Klickt in Steam mit rechts auf Omsi und dann auf Eigenschaften. Im neuen Fenster unter Updates wählt ihr den Punkt "Dieses Spiel nur beim Start des Spiels aktualisieren".

Seit dem ich diese Einstellung verwende gehen die Updates wieder schnell und bisher kam keine ungewollte Steamüberprüfung. Leider ist der Punkt nicht so benannt, wie er benannt sein müsste, denn daraus geht nicht wirklich hervor, dass man keine Zwangsüberprüfung mehr bekommt.

Zitat von Maxi G

Hier meine logfile. Gefahren bin ich mit einem O 305 auf der Linie 6 vom Hirschkäferweg bis kurz vor den Fürstenplatz, dann war Schluss. Ich hoffe, ihr könnt mir helfen.

Bei mir und einem Kumpel tritt genau das selbe Problem auf. Vom Wohnpark Othmarschen kann man die Straße noch bis zum Ende fahren und beim abbiegen nach link Richtung Fürstenplatz fängt entweder der Bus an zu springen oder Omsi schließt sich direkt. Gerade eben habe ich eine kurze Testfahrt vom Hbf zum Wohnpark Othmarschen gemacht. Das klappte noch einigermaßen gut, aber als ich dort dann gedreht hatte und das Stück wieder zurück gefahren bin, hat der Bus beim links abbiegen in Richtung Fürstenplatz wieder angefangen zu springen.

Das Problem bestand mit der normalen ailist und auch mit der Facelift ailist. Die erste Fahrt, die ich dort langfahren wollte, war die Linie 6 vom Bismarckplatz zum Hbf, Abfahrt war 21:37. Aber auch wenn es hell ist, scheint es dort ein großes Problem zu geben. Ich habe mir die Stelle auch im Editor angeschaut, jedoch konnte ich nichts auffälliiges finden und die Logfile enthält einige versuche einen Bus zu laden, einige Fehler "Fehler bei Bereichspr fung: AMUAV.CNAVO.MV.U", die auf ein ailisten-Problem hindeuten sollen und dann geht es auch schon los mit "Out of memory" und "Zur Verarbeitung dieses Befehls sind nicht gen gend Speicherressourcen verfügbar: TUV 4" sowie "Error: Systemfehler. Code: 8"

Hallo,

bei mir kommen selbstverständlich auch immer diese nervenden Steamüberprüfung. In den Steamforen gibt es folgenden Beitrag:

Spieleupdates bei Steam :: Deutsches Forum (steamcommunity.com)

Gleich im ersten Beitrag ist ein Zitat drin, was vom Steamsupport stammen soll. In Deutsch übersetzt heißt es in etwa:

"Hallo, Mit dem neuesten Client wurde eine neue Download-Seite bereitgestellt, die das Verhalten von Steam deutlicher zeigt; Der Patch-Vorgang ist jetzt Teil des Patch-%-Abschlusses, während vor den Updates nur „Aktualisierung“ angezeigt wurde, während dieser Vorgang abgeschlossen war. Updates auf Steam sind optimiert, um die Bandbreitennutzung zu minimieren. Dies kann jedoch dazu führen, dass der Patching-Teil eines Updates viel länger dauert als der Download-Teil. Dies liegt daran, dass Steam eine zweite Kopie der installierten Spieldateien erstellt, das Update auf diese Kopie anwendet, das Update validiert und dann die Dateien in das Installationsverzeichnis kopiert. Wenn auf Ihrem Laufwerk nicht genügend Speicherplatz für diese zweite Kopie vorhanden ist, kann sie stattdessen auf einem anderen Laufwerk erstellt werden, das Sie als Bibliotheksordner konfiguriert haben. Dadurch kann dieser Vorgang verlangsamt werden (das Verschieben von Dateien auf derselben Festplatte ist viel schneller). Verschieben von Dateien zwischen Festplatten). Vielen Dank, dass Sie Steam nutzen, Jessy"

Ich habe das zuerst auch immer für ein Omsi- bzw. Aerosoftproblem gehalten, weil es bei es mir bei Omsi besonders auffiel und auch durch die vielen kleinen Dateien sehr lange dauert. Tatsächlich haben das auch andere Spiele, bei denen man es vielleicht nicht so merkt, wenn die Dateien deutlich größer sind. Kürzlich hatte ich CitiesSkylines 2 geupdatet, da war der Download glaube ich ca. 2 GB groß, aber es wurden dann trotzdem über 50 GB angezeigt, was zu einer Spielkopie passen würde, weil es in etwa der Spielgröße entspricht.

Mich nervt das auch extrem, denn ich habe nicht für's Überprüfen, sondern für's Spielen bezahlt. Bei Omsi dauert diese dämliche Überprüfung ca. 30 Minuten bei mir. Ich will weder dass eine Kopie des Spieles angelegt wird, noch das es überprüft wird. Es sollen einfach nur die neuen Dateien schnell eingefügt werden und fertig. Der rest soll unverändert bleiben. Offenbar müssen wir uns alle bei Steam beschweren, damit sich das mal wieder ändert. Vielleicht müsste man sogar mit Anwälten dagegen vorgehen. Ich habe letztes Jahr schon mal an die Kanzlei von Christian Solmecke (Anwalt für Medienrecht, bekannt aus TV und YouTube) eine Email geschrieben, die aber bisher leider unbeantwortet blieb.

Ich könnte mir vorstellen, dass mit dieser Umstellung Steam auch zumindest gegen unser deutsches Recht verstoßen könnte, weil es oft sehr lange dauert, ungefragt geänderte Dateien zurück gesetzt werden, man ständig Backups machen müsste und diese dann wieder zurück kopieren müsste, was auch wieder unnötig Zeit kostet und auch unheimlich viel Speicherplatz frisst, den manche User einfach nicht haben.

x84 gibt es gar nicht. Das wäre x86. Und das kann eben nicht beides. x86 ist die 32 Bit-Version und die kann auch nur 32 Bit-Programme ausführen und maximal 4 GB Arbeitsspeicher nutzen. Wenn du mit rechts auf "Computer" und dann auf Eigenschaften klickst öffnet sich deine Systemübersicht. Wenn du wirklich ein 32 Bit System nutzt, dann würde dort stehen Installierter RAM: 32 GB (4 GB verwendbar) oder so ähnlich stehen.

Die 64bit Version 32- und 64-Bit Programme ausführen und auch die kompletten 32 GB RAM nutzen.