Neues Tool "StoreThem"

da bin ich gespannt wie das dann endgültig läuft, ohne Trainstore hätte ich damals beim MSTS rasch aufgegeben.

Gerade heute erst habe ich mich wieder geärgert als der TS mir wieder eine - Out of Memory Meldung - ausgegeben hat.
Da kommt so ein Programm wie damals Trainstore für den MSTS eigentlich gerade recht.

Das würde natürlich Sinn machen wenn wirklich nur das geladen wird was auch benötigt wird. Aber ob das durch einfaches umbenennen der Dateien erreicht werden kann ist mir noch nicht so klar.
Müsste nicht eigentlich alles was nicht benötigt wird quasi ausgelagert werden so das der TS das praktisch gar nicht mehr sieht?

Runtergeladen habe ich das schon mal aber ausprobieren möchte ich das momentan noch nicht. Ein Backup ist zwar vorhanden aber ich wollte mir nicht unbedingt den Sonntag Abend vermiesen.

Da sich der TS nicht um Dinge kümmert die nicht in einer Strecke oder Aufgabe referenziert sind, ist dieses Tool überaus nutzlos. Der Effekt der mit TrainStore beim MSTS erreicht wurde kann hier nicht erreicht werden. Wenn eine Strecke oder Aufgabe zu viele Provider benutzt, dann ist dies nur zu lösen indem man diese daraus entfernt. Da das Tool ja nachschaut, was refenziert wurde, kann man auf diese Art auch nichts zwanghaft ausschliessen. Ergo: völlig nutzfrei für das Speicherproblem was manche haben. Einzig für den ConsistBuilder kann es helfen die LAdezeit zu verkürzen, aber dann fehlen ja auch Dinge darin.

Habs eben mal mit ausprobiert.
Eine kleine eigene Route eingelagert, nur die Route
erscheint im Spiel.
Nehme ich eine "normale" Strecke, dauert das Ein- und Auslagern zu lange bei meinem Notebook
ohne SSD.

Es funktioniert, aber es dauert mir zu lange.

Ich denke schon das so ein Tool von Nutzen sein kann. Sicher die vielen Provider in einer Strecke da lässt sich nichts dran ändern aber beim benötigten Rollmaterial wohl doch.

Ich stelle mir das so vor das zb der Kuju Ordner dann je nach Strecke und Scenario nur aus dem benötigten Material besteht. Alles andere was sonst unnütz mitgeladen wird und Speicher
belegt fällt doch dann weg. Das auf alle benötigten Provider angewendet würde doch schon ordentlich Speicher einsparen.
Bei einer ich sag mal Standard Inst wird sich das vielleicht nicht so großartig auswirken aber es soll ja auch Leute geben die sind jenseits von 90 Gigabyte die der TS belegt.

Zitat von Maik Goltz

Wenn eine Strecke oder Aufgabe zu viele Provider benutzt, dann ist dies nur zu lösen indem man diese daraus entfernt.

Da gebe ich Dir recht. Wenn das Progarmm die Szenario.bin lesen würde und dann auch nur die Assets laden würde wo darin stehen wäre es besser.
Z.B brauche ich nur ein Asset aus dem Kuju-Ordner dann sollte auch nur das eine Asset geladen werden.
Dann hätte das Programm sinn.

Falsch Madison. Das Tool kann keine in das Produkt eingelagerten Assets ausschliessen. Es schliesst wenn dann das ganze Produkt aus. Um beim Beispiel Kuju zu bleiben, bringt das effektiv also gar nichts, denn RailSimulator ist das Produkt. Die ganzen Modifikationen und Repaints liegen alle daraunter und werden weiter mitgeladen. Gleiches gilt auch für RWItalia und ähnlich aufgepustete Provider mit zugemüllten Produktordnern.

Dazu kommt dass das Tool ja wohl nur umbenennt und nicht verschiebt. Das nutzt dann noch weniger, weil der TS sich im die Ordnernamen erst mal nicht schert beim Start, der kramt die alle durch.

Ausser einen leicht informativen Nutzen sehe ich da gar nichts nutzbringendes in dem Tool. Es birgt im Gegenteil wieder diverse "Gefahren" sich den TS zu zerstören.

Nix für ungut.

Ich habe keine Ahnung von der Speicherverwaltung des TS, ich denke aber Maik Goltz und Andere haben das. Ergänzend zu MAik's Beitrag:
Northern Europe (Denmark 2000) von Erich Falensteen
Szenarien Editor Erfahrungsaustausch
Laden von Strecken beschleunigen
Ich möchte nichts madig reden aber abgesehen von ev. verkürtzen Ladezeiten (Ohne die Zeit für das Ein- und Auslagern mitzurechnen ) verstehe ich im Moment noch nicht ob das ganze einen Sinn macht. Ich wäre froh gewesen Mike Simpson hätte RW-Tools abgespeckt, neu aufgesetzt, erheblich überarbeitet oder zumindest die ap-Dateien darin in den Griff bekommen.

Danke Maik für die Erklärung.

Mit dem Umbenennen das hatte ich mir schon gedacht das bringt nichts. Dem TS ist es doch egal wie die Ordner Bezeichnung ist. Sicher das Rollmaterial wäre nicht zu benutzen da der Pfad nicht mehr stimmt
aber dennoch würde der TS das mitladen. Also null Nutzen bringt rein gar nichts um Speicher einzusparen.

Wegen der ganzen umbennerei wollte ich das auch nicht ausprobieren da mir das Tool beim Start schon Zicken gemacht hat in Form von reagiert nicht mehr.
Man stelle sich vor das bleibt mitendrin hängen da kommt dann Freude auf

erst mal gucken, was das Tool wirklich macht. Wenn es nur auf Provider/Produkt Ebene arbeitet, bringt es nicht wirklich was. Wenn es weiter runter geht, schon. Aber weiter runter zu analysieren, dürfte fett Ladezeit kosten, und Komplikationen mit Szenarien provozieren.

Umbenennen bringt nur dann nichts, wenn es weiterhin im Asset Ordner (bzw im Provider/Produkt-Ordner) bleibt.

Zitat von nobsi

Umbenennen bringt nur dann nichts, wenn es weiterhin im Asset Ordner (bzw im Provider/Produkt-Ordner) bleibt.

Wenn es nicht im Asset-Ordner bleibt, ist ein Umbenennen auch sinnfrei.

Ich war heute auch mal ganz mutig und habe das mal getestet. Es werden zusätzliche Ordner angelegt wo die Strecken und Asset hin verschoben werden.
Von Umbenennen kann absolut nicht die Rede sein da habe ich nichts erkennen können daher frage ich mich warum das so beschrieben worden ist.

Egal man lagert erst mal alle Strecken und Assets aus was bei mir auf einer SSD relativ zügig ging. Dann wähle ich eine Strecke die fahren möchte und verschiebe diese.
Das Tool sucht dann in der Route Properties und scheinbar auch in den ScenarioProperties nach den benötigten Providern. Da muss man einfach abwarten und dem Prog etwas Zeit geben
da keine Anzeige existiert wo man sehen kann wie weit diese Aktion fortgeschritten ist. Anschließend verschiebt man dann diese markierten Assets.
Der Ordner Kuju wird automatisch mit angewählt und das bei jeder Strecke weil der ja Teil des TS ist und unabdingbar ist.

Programmstart des TS ist dann natürlich mega schnell da es ja nicht viel gibt was einzulesen wäre.

Svcenario auswählen und nach kurzer Zeit kann es dann normalwerweise schon losgehen. Das wollte bei mir aber nicht so wirklich klappen da angeblich diese und jene Fahrzeuge nicht geladen werden konnten
obwohl sie unter Assets im entsprechenden Ordner vorhanden waren. In wie weit da noch Abhängikeiten zu anderen Providern waren wo quasi durch die Hintertür drauf zugegriffen wird kann ich nicht sagen
das habe ich nicht weiter erforscht.

Das war schon mal das Ergebnis was Freeware Strecken angeht. Wie es bei den RSC Strecken mit eigenem Rollmaterial aussieht kann ich nicht sagen da ich keine Lust hatte meine ap Files zu entpacken.
Möglicherweise wird da alles funktionieren.

Aufgefallen ist mir auch das bei einer vermurksten Ordnerstruktur wie man sie ja von einigen bekannten Providern kennt auch dieses Tool nichts rausreißen kann.
Was innerhalb eines Providers einzeln an und abwählbar ist das funktioniert aber wenn alles in einem Topf liegt dann ändert sich auch nichts und alles wird nach Assets importiert.

Hauptproblem ist nach wie vor der Kuju Ordner der je nach Größe Probleme verursacht. Hier wird alles importiert da kann nichts abgewählt werden.
Was aber meiner Meinung nach sehr wichtig wäre denn das ist einer der Provider wo man ordentlich Speicher einsparen könnte wenn nur das benötige geladen wird.
Aber es ist halt so wie Maik gestern schon geschrieben hat das Tool ist nicht in der Lage tiefer in die Dateistruktur einzudringen um überflüssiges auszuschließen.

Bei einer fetten Freeware Strecke war nach einem Test der Speicherhunger des TS genau so groß wie vorher auch da hat sich schon mal nichts geändert trotz weniger Provider im Asset Ordner.
Wenn also zuviele Provider bei einer Strecke verwendet werden ist der Absturz so gesehen vorprogramiert. Vernünftige Scenarien lassen sich dann nicht mehr bauen wenn schon bei einer leeren
Strecke ohne Rollmaterial gut 2,8 Giga im Speicher stehen. Bei 3,5 Giga ist Feierabend da führt kein Weg dran vorbei da kann man machen was man will und da ändert auch kein Programm was.

Für mich ist dieses Tool erst mal uninteressant da ich bis auf die schnellere Ladezeit erstmal keine Verbesserung für mich sehen kann.

Der einzige Ausweg aus der Misere ist eigentlich eine Modifikation seitens DTG das der TS auch mehr als 3,5 Giga verpacken kann. Am fehlenden Speicher solls ja nicht liegen da ist meinerseits genug vorhanden.
Das nutzt aber alles nix wenn der TS das nicht gebacken bekommt.

Ein Verschieben in einen anderen Ordner desselben Laufwerks ist technisch betrachtet ein Umbenennen.
Daher geht das auch so schnell, weil nicht physikalisch irgendwas verschoben wird, sondern nur der Eintrag im Inhaltsverzeichnis des Datenträgers wird abgeändert.
Vermutlich rührt daher das Missverständnis.

Dass Kuju generell immer benötigt wird, ist nur bedingt richtig.
Es ist richtig, wenn das Tool nur die erste Ordnerebene behandlen kann, also den Provider, hier "Kuju".
Wenn das Tool aber noch das Product in der zweiten Ordnerebene behandelt, würde "Kuju/RailSimulatorCore" bei manchen Strecken ausreichen, weil nur hier die elementaren Objekte vorhanden sind, die der TS immer benötigt, z.B. Bahnsteig- und Szenariomarker oder den Gizmo des Editors, der seinerseits ja auch ein Objekt ist.

Letztlich aber erscheint mir der Einsatz dieses Tools aber noch irgendwie fragwürdig. Ich erkenne da irgendwie keinen Sinn. Das sähe anders aus, wenn die Product-Ordner, also die zweite Ordnerebene gezielt für ein bestimmtes Addon abgespeckt werden würde, was die BluePrints verkleinern würde und RAM sparen könnte, was aber ja nicht der Fall ist, wenn ich das richtig verstehe.

Bei 3,5-irgendwas GB ist Schluss, das stimmt leider.
Dennoch soll nicht verschwiegen werden, dass durch den Start des TS trotzdem auch mal 4 oder gar 4,4 GB verbraucht werden durch die ganzen anderen Zusatzmodule wie DirectX, OpenAL und PhysX, die ihrerseits ihre eigenen, vom TS unabhängigen Speichergrenzen haben.
Insofern... bevor wieder jemand angesprungen kommt und versucht, zu belegen, dass XP-32Bit keinen Nachteil gegenüber 64Bit hat... ist es schon von Vorteil, wenn man ein 64-Bit-OS mit mindestens 6 GB in seinem Rechner verbaut hat.

Ja das Problem ist ja das die 32 bit Nutzer einfach nicht verstehen wollen oder können das ein 64 bit System in jedem Fall Vorteile hat.
Ein 32 bit User wird diese 3,5 Giga Grenze wo der TS technisch bedingt aussteigt ja nie erreichen da ja das BS auch noch seinen Teil vom Kuchen abhaben will.

Beispiel sind die Scenarien eines Users hier aus dem Forum. Da ist dann entsprechend nicht viel KI Verkehr vorhanden wo man deutlich mehr reinpacken könnte.
Geht aber nicht weil dann das ganze System beim Ersteller zusammenbrechen würde

Bei mir sieht es oft so aus das ich gesamt eine Auslastung von ca 6 - 7 Gigabyte habe. 3,5 davon dann im schlimmsten Fall für den TS und der Rest geht an das BS mit den anderen Anwendungen die im Hintergrund laufen.

Hm... Wenn man auf ein anderes Laufwerk ein und auslagern könnte, wäre das noch halbwegs sinnvoll für kleinere SSDs. Wobei ja hier die Schreibvorgänge auch nicht zur Lebensverlängerung beitragen würden.
Schlussendlich dauert wohl das ein-/auslagern und starten genauso lange wie das starten ohne dieses Tool.