Bern, Fribourg, Neuenburg, Biel

@TrailDogRunner1909
Grunddiskussion: Warum kommt der RAM-"blubb" schon bei 3.3 GB Ram-Nutzung und nicht erst bei 4GB-Nutzung?
Prinzip, je mehr Freischaltungen, desdo blubb. Das gilt seit Railsimulator, an die Speicherverwaltung haben die RSC/DTG Mannen sich noch nie rangetraut.
Warum packt den DTG jetzt alles in einen Provider (= ein ap-Paket) ?
Dann da ist nur das drin, was die Strecke braucht. Den jeder freigeschalteter Provider wird zum Blueprint.pak und komplett in den Ram gepackt. Ob du vom Provider nur ein paar Blümchen, oder alles brauchst. Was nicht immer gleich mit kommt sind Texturen der Objekte, die nicht angesprochen werden. Wenn Du Pech hast, ist jedes Blümchen auf einer eigenen 2024*2024 Textur und nagelt den Ram voll. manche Provider bringen ja noch aufwendiges Rollmaterial mit, kommt alles mehr oder weniger mit in den Speicher und steht zum Laden bereit.
Daher mein Hinweis: RAM im Taskmanager beim Bauen und nach Freischaltungen beobachten.

Englische Strecken vor allem Objekte werden mit einer absoluten Disziplin an Speicherverbrauch "erfunden". Da gibts Häuserserien die alle auf eine einzige Textur zurückgreifen, dann werden die meist mit Baumreihen an der Strecke gestaltet,dahinter nur Bodentextur. Sieht zwar langweilig aus, aber den Speicher freuts.
Schalt mal Koblenz-Trier da mit frei und schau mal was der Ram macht.
StS

Warum sollte DTG zig Ordner mitschicken?
Würde nur auf die Performance gehen.

In der Grunddisskussion ist doch genau das Gegenteil herausgekommen
Nur das kommt in den Ram, was verbaut ist.
Bis auf den Blueprint.pak.
Wenn die paar KB als Maßstab genommen werden, dann sollte man tunlichst vermeiden, überhaupt nur einen Grashalm, geschweige denn eine Lok aufzustellen
Hmmm

Marias Pass halte ich eher für ein Problem, denn das bekommt man ja außerhalb der USA nichtmehr (zumindest auf unabsehbare Zeit hin nicht).

Meine Erfahrung aus etlichen Strecken, die mir wegen Signaleinbau zum Testen gegeben wurden und erst mal abgeschmiert sind: aus der Bauzeit etliche Provider freigeschaltet, aber nichts mehr davon verwendet. Die alle "weggehakelt", dann lief es. Also da wird schon mehr geladen als gebraucht. Deshalb wegen eines Grashalm einen Provider freizuschalten, ich würds nicht machen, wenn der Grashalm nicht in einem Eigenen Provider/Produkt Ordner ist und eigene Freischaltung hat.
StS

Aber das muss ja nicht zwangsläufig nur mit der alleinigen Freischaltung zu tun haben.
Was ich auch bereits erwähnte, z.B die Sache mit zu vielen Providern auf einer Kachel.
Nach meiner Erfahrung, müssen einige Dinge zusammenkommen, dass der TS bei einigermaßen artgerechter Haltung abschmiert.

Gruss Schmiddi

Na das sieht noch gut aus, bei Leipzig-Berlin wird schon berichtet, dass Quickdrive mit KI abgenippelt ist. DA kommst halt auf das Material an, das für diese Strecke QD-mässig freigeschaltet ist.
Hier haste etwas mehr Puffer.
Mit neuen Providern wäre ich jetzt vorsichtig.
StS

Nur als Ergänzung:
Einen Ramblub durch KI-Verkehr eines Quickdrives bekommst ganz einfach hin, indem mehr als 6 Loks (Pakete) freischaltest und fahren läßt.
Egal wie performanceschonend die Strecke gebaut ist.

Zitat von TrailDogRunner1909

So sehe ich das.

das hast Du in dem Beitrag meiner Meinung nach treffend zusammengefasst.

Wir haben früher die Produkt-Freischaltung überbewertet, und dadurch möglicherweise den einen oder anderen Content-Ersteller zu falschen Maßnahmen veranlasst (z.B. Pasquale von rsitalia, und in der Folge dwagency)
Natürlich kann, wenn die Strecke schon am Limit ist, eine Produktfreischaltung mehr oder weniger über den Crash bei einzelnen Usern entscheiden. Und daher konnte auch beim berühmt-berüchtigten Provider/Produkt Kuju/RailSimulator Abspecken dabei helfen, eine große Freeware-Strecke zum Laufen zu bekommen.
Im Normalfall ist aber auch die gleichzeitige Freischaltung mehrer aktueller "großer" DTG-Strecken kein Problem (mit "aktuell" meine ich die .ap-Datei-Generation).

Die eigentlichen Crash-Ursachen sind meist woanders zu suchen:

1. in den alten Providern wie Kuju, "Developer", aber auch rsitalia haben sich sehr viele Entwickler getummelt, von denen leider manche es wohl nicht für nötig hielten, die Doku zu lesen und zu verstehen (was man schon daran sieht, dass überhaupt Assets mit dem Provider "Developer" existieren). Daher gibt es in diesen Providern viele Assets, die schlichtweg kaputt sind und Strecken zum Crash bringen können.

2. in unterschiedlichen Produkten können gleichartige Assets mit demselben Namen auftauchen. Berühmt-berüchtigtes Beispiel: die Standard Tunnel- und Wasserfolien, die es mit identischem Namen sowohl in Kuju/RailSimulator als auch in Kuju/RailSimulatorUS gibt. Wenn ein Streckenbauer beim Bau beide Produkte aktiviert hat, kann er diese Assets nicht unterscheiden, in der Strecke wird scheinbar zufällig mal das eine, mal das andere benutzt. Bei den erwähnten Folien ist das nur ein optisches Problem (falls der Benutzer eines der Produkte nicht hat), bei manchen Assets kann es aber auch zum Crash führen.
Und je mehr unterschiedliche Produkt man aktiviert, um so höher ist die Gefahr von solchen Widersprüchen.

3. wenn sehr viele unterschiedliche Assets bzw Provider auf einer Kachel verwendet werden, kann es, wenn der Spieler schnell fährt, zum Crash kommen, weil der TS mit dem Nachladen nicht hinterher kommt. Das ist aber nicht unbedingt ein Speichermangel-Crash, und lässt sich (ohne Änderung der Strecke) in game vom Spieler oft verhindern.

Crashes wegen Speichermangel (hier mittlerweile gerne "Blubb" genannt) hängen erst mal nicht an Freischaltungen, sondern an tatsächlich geladenen (verbauten) Assets. Allerdings kommen manche Freeware-Strecken mit 100 oder mehr Freischaltungen daher. Und diese Menge kann - alleine durch die Freischaltung, ohne Verwendung der Assets - im Extremfall 4-6 Zugprodukten entsprechen, die dann eben nicht mehr ohne "Blubb" im Szenario Platz haben...

Zitat von Schwarzwaldbahner

Marias Pass halte ich eher für ein Problem, denn das bekommt man ja außerhalb der USA nichtmehr (zumindest auf unabsehbare Zeit hin nicht).

I have the Maria Pass route purchased 2 months ago by Aerosoft.
And I live in Belgium.

Checked it myself, you´re absolutely correct. I thought that it is not obtainable everywhere. Thanks for letting me know.

@'FMZSchotter
Ich habe mir heute auch alle Assets zusammengesucht, nur leider läßt sich der zweite der französischen Assets nicht finden "Fort Vincennes RAR" ist auf der Seite nicht vorhanden

Ich habe mir mal die Mühe gemacht und die meisten verlangen Downloads installiert. Das gibt ja eine riesige Strecke und auch entsprechend viel, sehr viel Arbeit. Da kann man nur hoffen, dass dem Erbauer die Lust nicht ausgeht dieses Projekt zu Ende bringen. Meinerseits wünsche ich die notwendige Ausdauer dazu.
Ich freue mich so oder so auf eine neue Schweizer-Strecke.
znarf

Zitat von FMZSchotter

When i layed the tracks i had no own trackrules and i didn't know the real speed-limits.

na klasse... hat sich das mal jemand angesehen und kann darüber urteilen?

Mir fehlen irgendwie noch einige Objekte und Gleis, muss dies bei Gelegenheit nochmals überprüfen was alles fehlt.
Ich bin mal kurz von Bern nach Lyss gefahren, hier fiel mir auf, dass die Geschwindigkeiten nicht immer mit den echten übereinstimmen.

Im Anhang die Streckentabelle der Zugreihe R von Bern nach Biel.

Tolle und viel Arbeit Arbeit investiert, nur die Basis-Macken des TS nicht berücksichtigt, alles Handweichen, kannste nur Freeroam fahren, vernünftige Szenarien, insbesonders Quickdrive nur umständlich machbar, müsste man alle Weichen von Hand für jedes Szenario vorjustieren und mit dem Szenario dann abspeichern. Schade.
Da macht es auch nichts, dass es kein Strecken-Vorschaubild gibt. Vor lauter in den 2d Plan schauen, ob der Fahrweg stimmt, ist es fast wurscht, ob die Geschwindigkeiten der tatsächlichen Strecke entsprechen.
StS