Beiträge von NewRailWay

@Kim_olesen1 : Das Problem ist nur, dass der gute alte TS technisch leider doch dem Ende seiner Lebenszeit entgegensieht. Ich bin vor 2 Wochen auf einen 4k-Monitor und die entsprechende Auflösung umgestiegen. Durch die Verwendung von DirectX9 ist die fps-Rate dramatisch in die Knie gegangen und gerade noch am Rande des Erträglichen. Während der TSW auf UE4-Basis und DirectX11 kaum Einbußen erlitten hat. Und bei ETS2 und ATS (auch auf der Basis von DirectX11) bei der Beschränkung auf 60fps sich nicht im geringsten beeindruckt gezeigt haben.

Und ich glaube nicht, dass DTG die personellen Ressourcen (und das KnowHow) hat, den TS noch auf DX11 umzuprogrammieren. Selbst SCS hat sich da ja bei ETS2/ATS ganz schön anstrengen müssen.

@Schwarzwaldbahner: Ich kenne den TS nun schon seit ein paar Jahren (seit 2013). Und RSC (wie sie sich vor der Umbenennung auf DTG nannten) war von Anfang an allergisch auf Drittanbieter. Konnten sie nur bei dem eher offenen Konzept von Railworks nicht verhindern. Drittanbieter waren für sie schon immer unangenehme Konkurrenz, die ihnen das Brot vom Teller klauen will. Wie sich gezeigt hat, waren es aber genau diese Anbieter, die den TS über die Jahre interessant und am Leben erhalten haben. (Und DTG den Verkauf unzähliger DLCs ermöglicht haben). Ironie der Geschichte ist, dass DTG heute rundum die Produkte dieser Anbieter aufkauft und dann unter eigener Regie auf Steam anbietet, um das Rad TS am Laufen zu erhalten.

Und der TSW war nun eben genau die Gelegenheit, die schon immer verhasste Konkurrenz auszuschalten. Und so ist der PC eben nur noch eine Art Konsole neben den anderen. Und mit dem Kopierschutz Denuvo auch schön abgesichtert. Mal schauen, wie lange man die Leute bei Laune halten kann. Erst mal sieht es durch die zusätzliche Kundschaft von XBOX, Playstation ja gar nicht so schlecht aus. Aber beim TS hat man über Jahre hinaus fast jede Woche ein neues DLC angeboten und verkauft. Ob man auf den Konsolen die Leute so lange bei der Stange halten kann? Besonders, wenn ich das richtig verstanden habe, auch die Spielstände von TSW1 nicht auf den TSW2 übertragen kann, sondern man von vorne beginnen muss.

Zitat von rschally

... Dafür werde ich Trainz 2020 im Auge behalten ...

Um den ist es in letzter Zeit aber auch so merkwürdig ruhig geworden. Hatte Anfang der Woche mal auf deren Seiten geschaut, aber über die Planung für die Zukunft ist da überhaupt nichts zu lesen. Oder habe ich das übersehen?

Ansonsten verstehe ich das Marketing von DTG im Moment nicht so ganz. Für den TSW1 gibt es doch schon 25 DLCs. Auch auch wenn diese in den TSW2 übernommen werden, die kauft nach Erscheinen des TSW2 doch keiner mehr (wenn sie nur eingeschränkt nutzbar sind und nicht mehr aktualisiert werden). Müsste von der Kosten/Nutzen-Analyse doch sinnvoller sein, diese DLCs auf den aktuellen Stand zu bringen und dann normal weiter verkaufen zu können. Bei Trainz/TANE kaufe ich doch auch keine DLCs von alten Versionen, die nur so halbgar kompatibel sind. Alles wieder auf 0 zu setzen mag ja beim Farming Simulator oder ähnlichen SImulationen funktionieren, aber da ist die Anzahl der vorhandenen DLCs doch auch eher übersichtlich (und die Anzahl der vorhandenen Modelle in der Grundversionen auch wesentlich höher).

Eh schon merkwürdig, die alte Version TSW 2020 zu bezeichnen und die neue Version als TSW 2. Freue mich schon auf die ganzen Fragen hier im Forum ab Herbst, weil manche das dann nicht auf die Reihe bekommen.

Aber immerhin sind sie so ehrlich, die Karten vor dem Erscheinen des nächsten DLCs nächste Woche aufzudecken. Der Kauf der Class 20 hat sich dann wohl eher erledigt.

Great work. I included some screenshots in the screenshots thread to this beautiful line. --> look here

And v2 includes 27 scenarios!

Diese Tage erschienen: Northern Lines V2

Das mag bis Ende April gepasst haben, seit Anfang Mai aber mit Sicherheit nicht mehr unter Windows 10. Gibt ja nun in allen Foren genug Beiträge und Beschwerden, dass an allen Ecken und Kanten im TS (64bit-Version) laufend Fehlermeldungen mit Out of Memory kommen, mal nur die Dialogbox, manchmal gleich mit Absturz des TS.

Man konnte ja nicht mal 2 Minuten auf einer alten und bislang harmlosen Strecke wie London-Brighton (ohne Ki-Verkehr) fahren, um mit diesem OOM genervt zu werden.

Mit der Vergrößerung der Auslagerungsdatei bekommt man unter W10 erheblich weniger dieser Fehlermeldungen. Jetzt kann man wenigstens wieder ein Szenario über die ganze Strecke auf der ohnehin nicht ganz unkritischen London-Peterborough fahren, bevor der TS beim Rückkehr in das Hauptmenü mit OOM abstürzt.

Ob das nun ein Bug im TS ist oder mit einem Sicherheitsupdate Anfang Mai im Windows 10 eingeführt wurde, sei dahin gestellt. (Vielleicht ein Bug im TS bei der Freigabe von Speicher (Hauptmenü, DX9-Thread-Wechsel, ???) Und mit einer CPU i7-2600K, Hauptspeicher 16 GB, Grafikkarte GTX 1060 mit 6 GB habe ich bis Ende April im TS keine Probleme gehabt. Und seit Anfang Mai wurde der TS zunehmend unspielbar. Mit der größeren Auslagerungsdatei, die bei jedem Systemstart neu angelegt wird, kann ich jetzt zumindest alle Szenarien wieder durchspielen und erst danach stürzt der TS manchmal ab. Im übrigen das einzige Spiel, das Probleme macht.

Ich habe heute gesehen, dass Windows 10 zumindest seit 1903, bei 16 GB Hauptspeicher nur eine Auslagerungsdatei von 2 GB (max 3 GB) anlegt. (Wenn W10 die Auslagerungsdatei selbst verwaltet.) Ich habe heute mal die Auslagerungsdatei auf 16 GB mit max. 32 GB erhöht und lasse diese beim Herunterfahren löschen und dann beim Starten neu anlegen.

Mit ist zwar nicht klar, warum der TS bei 16GB Hauptspeicher auch noch auf der Auslagerungsdatei herumkauen sollte, aber bislang hat sich keine OOM-Meldung mehr herausgetraut. (Kann sich natürlich minütlich wieder ändern )

Das Protokoll sieht aber nicht aus, als ob beim Consist Builder mitgelaufen ist ?

Eine Frage: Welches Betriebssystem verwendest Du? Ich habe heute gesehen, dass Windows 10 zumindest seit 1903, bei 16 GB Hauptspeicher nur eine Auslagerungsdatei von 2 GB anlegt. (Wenn W10 die Auslagerungsdatei selbst verwaltet.) Ich habe heute mal die Auslagerungsdatei auf 16 GB mit max. 32 GB erhöht und bislang hat sich keine OOM-Meldung mehr herausgetraut.

Wohl wahr. Wobei, wenn ich gestern die Diskussion auf Facebook richtig verstanden habe, dieses Mal die Innenraumsounds "nur" eine reduzierte Version der Außensounds sind. Wegen des Coronarvirus-Lockdowns waren wohl entsprechende Aufnahmen im Februar/März nicht mehr möglich.

Leider ist das Thema AP so vorbelastet. Auf UKTrainsim könnte inzwischen eine KI jeweils die Beiträge von alleine erstellen Ist eh immer das Gleiche von den gleichen Teilnehmern.

Ich glaube, mit diesem Enhancement-Pack wird nur derjenige richtig glücklich, der mit den ganzen Zusatzfunktionen das Fahren etwas anspruchsvoller gestalten möchte. (Wobei das natürlich so etwas wie Selbstbetrug ist, da der TS das zwar duldet, es ihm aber vom Spiel her völlig egal ist.) Eigentlich gehört so eine Erweiterung inzwischen in den TSW, da aber dort die Streckenlänge bei einer Strecke von Brighton-London auf Brighton-Gatwick begrenzt wäre, leider auch vergebene Mühe.

Mutig. Da bin ich mal gespannt. Die Class 20 war im TS schon vor über sechs Jahren eine der ersten Loks, die auf Advanced Niveau gebracht wurden und damals mit den guten Ruf von JustTrains begründet hat. Da hängt die Messlatte hoch Auch, da man den Sound mit dem AP-Soundpack vergleichen wird.

Gewonnen hat mit Sicherheit das Lokcab. In 4K-Auflösung hängt der TSW da den TS gnadenlos ab. (Habe mich gestern arg gewundert, als ich nach einem Monitorausfall auf 4K und 3840x2160 umsteigen musste. Gegenüber 2560x1440 ist es, als ob man eine ganz andere TSW-Version bekommen hat. Und im Gegensatz hat der TSW auch wesentlich weniger fps verloren als der TS mit seinem DX9. Da weiß man zumindest, wie die Screenshots zustandekommen, die DTG in ihren Beiträgen zeigt.)

Try it step for step, not all in one step. Try first only the next directory. If I understood correctly, you deleted already the whole Yohann folder. In this case move the next directory out offside the Assets folder. If you are unsure, make a screenshot from the directory structure within the file manager and post it here. Don't do too much in one step. You like to have a nice TC installation after the error correction, not only a partially deleted. (A hint, if you didn't it before: a backup before further steps could one of your best friends )

Noch mal zu der bisherigen Diskussion:

Die Verzeichnisse in Railworks/Assets sind nicht zwangsläufig auch die Provider-Ordner, für die der Cache, d.h. die Blueprints.pak Dateien erstellt werden. Das können auch Verzeichnisse sein, die eine oder mehrere Ebenen tiefer liegen. Typisches Beispiel sind die Ordner DTG und RSC. In diesen Ordnern liegen die Verzeichnisse für die jeweiligen Strecken und Loks/Triebwagen. Und erst diese Verzeichnisse bilden dann die Provider. Somit kann man aus der Anzahl der Verzeichnisse im Asset-Ordner keine wirklichen Rückschlüsse auf die Gesamtzahl der zu erzeugenden Blueprints.pak Dateien ziehen.

Das Logmate-Protokoll, dass hier gepostet wurde, zeigt eindeutig, dass die Cache-Erzeugung ohne Absturz bis zum Ordner Yohan\BB66000 funktioniert hat. Erst als der TS in den nächsten Ordner gegangen ist, kam es zum Absturz und das Protokoll endet abrupt ohne weitere Eintragungen. Von A bis Y (Yohan) braucht man deshalb nicht nach dem Fehler suchen. Damit kam der TS klar.

Die Frage ist nun, gibt/gab es in der betroffenen Installation ein Verzeichnis, in das TS gewechselt ist. Dabei geht der TS streng alphabetisch vor. Gibt es ein solches Verzeichnis, dann sollte man dort nach dem Fehler suchen (also am besten das Verzeichnis verschieben). Wenn man im Dateimanager in der alphabetischen Reihenfolge kein weiteres Verzeichnis findet, dann es ist nicht die altbekannte Problematik, dass der Consist Builder keine vernünftige Fehlerabfangroutine hat. Dann dürfte es eher an Memory-Fehler-Problematik liegen, die seit kurzem immer häufiger auftritt und für die bislang keiner einer vernünftige Erklärung gefunden hat. Das Logmate-Protokoll spricht aber eher für die erste Variante, da am Ende noch eine Zeile für eine neue Blueprints.pak-Erzeugung begonnen wurde.

Und was das Cache-Löschen betrifft. Das heißt eigentlich nur, dass alle Blueprints.pak gelöscht werden. Blueprints.pak müssen gelöscht werden, wenn sich in den Provider-Verzeichnissen etwas geändert hat. Weil ansonsten in den Blueprints.pak falsche Angaben stehen. Dieser Cache ist überhaupt nur da, damit der TS nicht alle Millionen an Dateien im Asset-Ordner lesen muss, sondern erst einmal nur die bestehenden Blueprints.pak-Dateien. Je nach Installationsmenge können das schon mal 1500 sein oder wie hier über 3000 (was allerdings wirklich etwas viel erscheint). Man darf dabei nicht vergessen, dass im Asset-Ordner auch alle anderen Objekte enthalten sind, Vegetation, Gebäude, Schilder, Signale, etc.. Damals hat man es noch nicht für nötig gefunden, das Rollmaterial getrennt zu behandeln. Worunter das TS-Menü bis heute (und bis zum Ableben des TS) empfindlich leidet.

Früher konnte man davon ausgehen, dass tatsächlich Hauptspeichermangel oder defekte Konfigurationsdateien für ein solches Problem verantwortlich waren.

Seit Anfang Mai hat sich das Problem aber verschärft. Erste Diskussionen waren auch schon im englischen UKTrainSim-Forum und aktuell auch im offiziellen DTG-Forum zu lesen (dort wie immer sehr "leidenschaftlich" geführt). Inzwischen gehe ich eher davon aus, dass es gar nicht an Fehlern in den jeweiligen TS-Installationen liegt. Sondern ein irgendwie gearteter Bug zu dieser Fehlermeldung und dieser Dialogbox führt. Aufgetreten ist der Fehler ungefähr zu dem Zeitpunkt, als auch durch das Steam-Client-Update die Zugriffsprobleme auf spezielle DLCs, wie die UK-LED-Signale, zu Tage traten. Muss aber nichts miteinander zu tun haben.

Mal taucht dieser Fehler schon beim Starten des TS auf, mal in Szenario-Builder, manchmal in Szenarien oder dem Spielen von Szenarien, manchmal auch erst wenn man im Hauptmenü auf Beenden klickt und der TS beendet wird. Angesichts der vielen Absturzreports, die lt. Protokoll netterweise unverschlüsselt an einen Server geschickt werden, sollte DTG eigentlich selber hellhörig werden.

Bislang konnte ich jedenfalls weder feststellen, dass zum Zeitpunkt der Fehlermeldung der Hauptspeicher komplett ausgelastet war, auch nicht der Speicher der Grafikkarte. Allerdings sind im Logmate-Protokoll teilweise Fehlermeldungen zu DX9 zu finden (Tried to acquire DX resource on different thread). Falls DTG selber keine Änderungen im TS vorgenommen hat, könnte es vielleicht auch sein, das ein Windows-Update zu diesen Problemen führt. In letzter Zeit gibt es ja viele Sicherheitspatches im Zusammenhang mit der Abschottung von Hauptspeicher, damit Programme keine anderen Programme ausspähen oder manipulieren können.

Falls man im Logmate-Protokoll keine Fehlermeldungen findet, sollte man also vielleicht besser einfach mit der Situation leben, anstatt mit irgendwelchen Reparaturmaßnahmen sich noch die Windows-Installation zu beschädigen. Vielleicht kümmert sich DTG ja noch um das Problem. Falls immer mehr TS-User betroffen sein sollten, bricht Ihnen ja sonst eine wichtige Einnahmequelle weg.

Zitat von Tarik Pasic

So you're saying this Yohan folder may be causing all those problems?

No, that's not, what I meaned.

The last successfully handled asset was Yohan\BB66000. And the next asset, for which it's needed to create a blueprints.pak file is faulty.

Because you already deleted the whole Yohan folder, it must be the next (alphabetically) folder within Railworks/Assets. Sort the Assets folder alphabetically and look, what's the next folder (after the previously deleted Yohan folder). Assumed, you have cleared the TS Cache (deleted all blueprints.pak files) before running the Consist builder, this folder doesn't contain a blueprints.pak file. (Because the TS crashed on the try to build it).

Zitat von Tarik Pasic

Here's the logmate

The solution could be at the end of your logmate file:

Please look into your Railworks/Assets folder and sort it alphabetically. All was fine until Yohan\BB66000. (Ok, not fine, there are several error messages, but these were catched by the error routines).

I don't believe, that there is really a memory problem. This problem is very old and common. Your can find many threads and solutions many years ago in this forum. The problem is founded by missing a proper error handling. The TS tries to build the internal cache, based on the blueprints.pak files. To build them, it reads all content within the assets folder, grouped by the providers (directories). And if the TS can't read one of the included files because of 0-byte length or unexpected chars, it raises an exception. And here in this routine, the exceptions will not be caught, but let the TS dump.

So look within the Yohan folder. Is there alphabetically another folder after BB66000, where TS2020 tries to build the Blueprint file? Or if not, is directly in the assets folder alphabetically after the Yohan folder another directory?

Within this folder (Yohan/?? or Assets/???) the TS2020 dumped by trying to build the BluePrints.pak file. Look in the folder, if there any 0-byte files and delete them. Or if not, once move this directory out of the assets folder.