Ein grosses Merci und eine kleine Bitte an alle Szenario-Entwickler

Hallo @hbirger ,

erst einmal ein danke ... als Szenario-Bau Frischling .... *hust* gerade mal nur zwei Szenarien draußen ... finde ich es schön, dass du deinen Dank an die Szenario-Bauer im allgemeinen gerichtet hast.

Ich selber habe bisher eigentlich keine Probleme mit Blubbs gehabt, obwohl mein Rechner bzw. die verbaute Hardware etwas Out-Dated ist, bisher schaue ich dass ich so wenig Provider wie möglich verbaue um nach Möglichkeit das Maximum dabei heraus zu holen.

Bisher scheint dass auch ganz gut hin zu hauen, denn ich hatte bisher bei meinen beiden letzten Szenarien auch keine Rückmeldungen von Ram-Blubbs okay, dass kann daran liegen, weil diese auf Altenburg Wildau 3.11 laufen .... Aber ich sitze derzeit an einem Szenario auf Berlin Leipzig wo einiges los ist. ( Vielleicht ist dies ja mein erster Blubb-Kandidat )

Naja hoffen wir es mal nicht, denn im nächsten Jahr ist ein Update für das derzeit in Bau befindliche Szenario angedacht weil ich es schlicht nicht schaffe dass noch vor meiner selbst gesetzten Deadline alles noch mit ein zu binden.

Bevor ich angefangen habe mich mit Szenario-Bau zu beschäftigen und mein erstes zu erstellen welches dann auch Veröffentlicht werden sollte, habe ich mich durch Zig Threads gelesen, mich mit dem ein oder anderen Szenario Bauer unterhalten .... und wie es ja auch in der Signatur steht BETA Getestet xD .... Hier nochmal ein Sorry an die Szenariobauer die bei mir in der Letzten Zeit angefragt haben ob ich Testen kann ... aber das Selber Bauen macht mittlerweile echt eine menge Spaß!

Auch wenn ich diesen Dispatcher manchmal Erwürgen könnte oder irgendwo gegen klatschen! Besonders gefällt mir die Meldung:"Unbekannter Fehler"

Das Testfahren ist so oder so ein ziemlicher Zeit-Fresser ... Was ich aber schön finde ist dass man sich untereinander auch weiterhilft ... hier ein ganz großes DANKE an @Scarlet der mir schon dass ein oder andere Erklärt hat und sogar dass Szenario-Script welches ich seit Anfang an nutze Bereitgestellt hat ... nicht zu vergessen und von der Community geliebte ZZA-Genarator von Scarlet!

Auch möchte ich den Asset, Script, Strecken .. etc. Erstellern danken, ohne euch wäre es kaum möglich Strecken/Szenarien zu bauen!

Was die Teilung der Szenarien angeht, finde ich an sich gar nicht mal so übel .... Die ersten beiden Szenarien von mir hängen ja Story-Technisch auch zusammen ... nun gut ich habe zum Ende hin nen Aufhänger platziert an dem ich anschließen konnte! Gerade bei längeren Geschichten die man ggf. erzählen möchte ist dies eine sehr Sinnvolle Methode!

Sooo jetzt aber erstmal genug "Wall of Text"

Ich gebe den Stift mal weiter!

Kann mich dem nur anschließen. Die Szenarien werden gefühlt immer besser und besser. Sie sind definitiv das "Salz in der Suppe" für mich. Mittlerweile spiel ich eigentlich nur noch Szenarien aus diesem Forum, ggfs. nochmal hin und wieder 3DZug oder Versystem / TaD.

Aber gerade die besonders interessanten Szenarien mit aufwendigem KI Verkehr hier aus dem Forum, sind leider heutzutage oft nicht mehr (in einem Durchgang) spielbar ohne die Grafikeinstellungen zu reduzieren... Das ist natürlich ein gewaltiger Einschnitt in den Spielspaß.

Ich hab dazu auch noch ne technische Frage: Es gibt ja zu vielen Loks diverse Repaints, Soundupdates usw. Nicht immer müssen diese Repaints im Editor einzeln aktiviert werden, sondern machen sich sozusagen zum Teil des Grundpakets, nennen wir es mal "Paket Baureihe XYZ"

Dann werden doch - sobald der Haken zu "Paket Baureihne XYZ" im Editor gesetzt ist - all diese Repaints mitgeladen, auch wenn sie gar nicht auf den Schienen platziert wurden, oder täusche ich mich da?

Denn das wäre ggfs. ein Anlass für mich auch mal Repaints auszumisten und alle rauszuschmeißen die nicht extra einzeln im Editor freigeschaltet werden müssen...

Zitat von morb

Dann werden doch - sobald der Haken zu "Paket Baureihne XYZ" im Editor gesetzt ist - all diese Repaints mitgeladen, auch wenn sie gar nicht auf den Schienen platziert wurden, oder täusche ich mich da?

Ja, da täuscht du dich. Es beeinflusst das ganze zwar etwas, aber nicht so, als wenn alle Repaints auf der Strecke stehen würden.

Zitat von AbsolutesChaoz

Ja, da täuscht du dich. Es beeinflusst das ganze zwar etwas, aber nicht so, als wenn alle Repaints auf der Strecke stehen würden.

Danke dir, das hilft mir weiter... Und spart mir ne Menge Arbeit. Wäre sonst die Tage mal rangegangen und hätte Repaints ausgemistet

Aber was dringend ist und Nobsi im Blubb-Thread geschrieben hat. Wer mit QD Probleme hat, die Preload-ordner durchmisten und schauen ob da nicht (exotische hochauflösende) Repaints oder Rollmaterial überhaupt nicht passend für diese Strecke freigeschaltet sind.
Ich hatte letzthin auf Mannheim Karlsruhe die Abstellgleise voll von dem Steuerwagen-Schienenbus -Repaint. Die kamen mir sogar auf der SFS entgegen. grrr.
StS

@hbirger ich persönlich finde SSAA nicht so überzeugend, dass ich deswegen erhöhte Wärmeentwicklung und verminderte Performance in Kauf nehme - aber ich habe auch nur einen "normal großen" Monitor.
Ansonsten bin ich aber derselben Meinung, speziell auch im Hinblick auf Szenario-Aufteilung. Mir ist zwar klar, dass es ein paar "Freaks" gibt, die gerne 4 Stunden in einem Durchgang fahren würden, aber für Normalos (z.B. berufstätig) ist das sowieso nicht möglich.
Kürzere Szenarien mit mehr KI sind letztlich wesentlich interessanter als lange Szenarien (fast) ohne KI.

Zitat von morb

Dann werden doch - sobald der Haken zu "Paket Baureihne XYZ" im Editor gesetzt ist - all diese Repaints mitgeladen, auch wenn sie gar nicht auf den Schienen platziert wurden, oder täusche ich mich da?

Wenn der Haken gesetzt ist, werden nur die entsprechenden Cache-Dateien (Blueprints.pak) geladen. Die enthalten nur die Infos aus den Blueprints - z.B. auch die Info, wo die erforderlichen Texturen sind -, aber keine Texturen. Die Texturen werden erst geladen, wenn das Fahrzeug tatsächlich auf die Schienen kommt (und auch nur jeweils einmal).

Es gibt übrigens noch einen Einfluss, wie schnell der Dump kommt: die Fahrgeschwindigkeit. Der TS lädt gleichzeitig Assets nach, die gebraucht werden, und wirft Assets raus, die nicht mehr gebraucht werden. Das Nachladen hat höhere Priorität. Je schneller man fährt, um so mehr Daten muss der TS pro Sekunde laden, und hat schließlich keine Zeit mehr übrig, Assets rauszuwerfen, die nicht mehr gebraucht werden. Das ist spätestens dann der Fall, wenn man so schnell unterwegs ist, dass ständig Nachlade-Ruckeln auftritt. In einem Szenario mit festem Fahrplan hat man natürlich bei der Geschwindigkeit nicht all zuviel Spielraum, aber da kann ein bisschen Pause (ESC) helfen.

Merke: wer schneller fährt, hat schneller Dump

Zitat von nobsi

Wenn der Haken gesetzt ist, werden nur die entsprechenden Cache-Dateien (Blueprints.pak) geladen. Die enthalten nur die Infos aus den Blueprints - z.B. auch die Info, wo die erforderlichen Texturen sind -, aber keine Texturen. Die Texturen werden erst geladen, wenn das Fahrzeug tatsächlich auf die Schienen kommt (und auch nur jeweils einmal).

Könnte man dann nicht durch häufigeres leeren des Cache, Speicher sparen und Dump´s minimieren?

Du verlängerst nur die erste Ladezeit einer Strecke, da werden die Blueprint.pak erzeugt und auch auf der Platte für spätere Nutzung abgelegt. Es werden aber nur die blueprint.pak der Assets in den Speicher geladen, die in der Routesproperties aufgeführt sind. Da muss man mal schauen, was da so steht und wirklich gebraucht wird. Entwickler haken gerne was an, bauen das aber nicht ein. Nur Du hast dann Probleme. Sehr beliebt, Rollmaterial in der Grundstrecke, das Anhaken dazu gehört in die Szenarien, dann wirds auch nur beim Szenarienaufruf geladen.
RW-Tools bietet das Weghakeln an.
Eine Abhilfe gibts noch: streckenspezifische Assets-Struktur, Da rein nur das Material was eine Strecke braucht.
Vor allem gut für alle Sammler und Jäger, die 1000 und ein Objekt im KUJU-Ordner haben, die Strecke aber nur 100 braucht.
Mit RW-Tools das Material listen lassen, danach Assets-Ordner mit entsprechenden Unterordnern aufbauen.
StS

Bringt also nichts. Danke für deine Ausführungen.
Ich schaue mir irgendwann mal doch wieder das Programm StoreThem an ob man damit was anfangen kann.
Vielleicht in meinem Weihnachtsurlaub.

Gruß
Stefan

Das Tool StoreThem ist eine Fehlentwicklung, die Denke war wie Trainstore für den MSTS, nur der TS tickt anders.
StoreThem lagert nur komplette Assets-Ordner weg, und magert die nicht auf das notwendige ab.
So mein Stand, länger nicht mehr getestet, da ich anders arbeite.
StS

Ja schon aber ist es nicht so, wenn sich nur wenige Assets Ordner und somit Fahrzeuge im TS befinden dann kann er ja nicht alle laden...
Wenn man damit nur die für die Strecke ich gerade fahren möchte wieder in den TS laden könnte. Dann ist doch mehr Speicher vorhanden und Dump´s müßten doch verringert werden? Währe doch auch für QD´s interessant um die Anzahl möglicher Fahrzeuge in QD´s zu reduzieren und damit Dump´s zu vermeiden.

Der TS packt in Bp.pak und läd dann diese was in der Strecke, bzw Szenario angehakt ist. Der Rest wir ignoriert. Siehste nach Cache leeren daran, dass kein blueprint.pak für ungenutzte Assets erstellt wird.
Bei QD -Preloads hast Du recht, könnte helfen. Das testen und schauen ob das Tool preload-Ordner kennt.
StS

Klaro, als Streckenbauer am besten ein fast" rollmaterialfreies" ""Bau"" Freeroam- Szenario und das gleiche für alle Jahreszeiten sowie Tag und Nacht, dann hat man immer alles beinander. Klar will man dann auch mal zwischendurch was Fahren aber dann macht man halt Testszenarien (Jahreszeiten kann man klonen wenn nötig usw).

Lieber @StS zwar wäre es für die reinen "für mich bauer" von extremem Vorteil alle nicht benötigten Assets "rauszuschmeißen" (denn mit den eingefärbten Listen arbeiten wohl die wenigsten, muss man halt unbedingt sichern). Für einen Provider macht das auch Sinn (modden wäre zu mühsam wie für Rollmaterial), wenn man aber etwa aus 10-15 Providern Sachen extrahieren will, müssen halt sämtliche Pfade geändert werden. Natürlich ist sowas nur "privat" und wird niemals veröffentlicht werden, höchstens es ist ausschließlich Freeware und in Rücksprache. Idial wären minimale Listen im Editor, andererseits geht es mit copy und paste durchaus auch flott, viel Aufwändiger ist das exakte Aufstellen und Herrichten.

Anders gesagt, nach der Testerei, die schiere Anzahl von freigeschalteten Providern ist eher nachrangig (auch die Länge der Strecke und die pure Anzahl von Kacheln ... naja gut zum Laden eben und von > 200 km will ich auch nicht sprechen), problematisch wirds wenn eine Kachel mit sehr viel verschiedenen und großen Assets ("Texturfrevel" würde Schmiddi es nennen) vollgestopft wird, kein Rbf Maschen in voller Auflösung darin liegt und man dann eben noch mehr als 3-4 hochauflösende Zugmodelle aufstellt oder damit in dieses kritische Kachel reinfährt.

Wenn man sich an diese Regeln hält kann man sowohl schön (aber sparsam) bauen als auch relativ nette Szenarien einrichten, letzteres allerdings ist ohne "schonende KI" in größeren Bhf eine echte Herausforederung.