Assets Ordner Hierarchie - Wahnsinn mit oder ohne Methode?


Abonniere unseren Kanal auf WhatsApp (klicke hier zum abonnieren).

  • Ich verschiebe gerade alle meine Assets Ordner auf eine frisch formatierte HDD Platte. Ich bin gerade bei R wie RSC angelangt und derzeit 490 Gigabyte.


    Jenseits der schoen verpackten .ap Ordner scheint ein absolutes Chaos zu herschen?


    Ab und an finde ich die eigenartigsten 'Nester' (as in nested folders) - Ordner deren Unterordner genauso heissen wie der obere Ordner und die Frage sich aufstellt "Ist das Absicht?" ... oder hat da jemand beim zusammenpacken sich vertan? Findet RailWorks.exe die "RailVehicles" und "RailNetwork" Unterordner in dem Unterordner des Unterordners?



    Manche (nicht-/kommerziellen) Provider haben Ordnernamen oder Dateien welche keiner Idee von "Best Practices" oder Kuju/RSC Strukturvorgaben folgen. Ich bin ueber eine Datei gestossen, welche Whitespace ('unsichtbares' Zeichen, wie Space Taste) nutzen. Andere, Namen, welche nach Rechtschreibfehler klingen ( = siehe ScaleRail "Vigitation". Findet die Strecke via Blueprint-Eintrag den Inhalt?). Ich habe keine Ahnung.


    Je nach Ursprungsland der Objekte oder Strecken, sind manche Unterordner in der jeweiligen Landessprache (inklusive Schriftzeichen). Logmate.exe meckert unaufhoerlich, wenn man mal "Train Simulator" mit dem Monitor-Tool logged, aber bricht nicht ab. Also, zumindest 'laeuft das Spiel' auch wenn ich nicht weiss, ob Objekte im Unterordner des jeweiligen Providers gesucht und/oder gefunden werden.



    Selten habe ich das Glueck, dass ich einen 'offensichtlichen Fehler' finde. Wenn sich zum Beispiel jemand tatsaechlich verschrieben hat wie in Bild-Beispiel 3.


    Keine der offiziellen Manuals/Handbuecher scheint dieses Thema anzusprechen?


    Mit RWTools kommt man bedingt weiter aber nicht ans Ziel? Was RWTools nicht kennt, kann es auch nicht finden?


    Die Entwickler unter euch, welche jenseits der "Ich mach das genauso wie die Anderen"-Methode schmerzhafte Einsicht in die Materie haben, koennt Ihr mich auf Links oder Webseiten-Artikel lenken, welche "Euch" geholfen haben, durch diesen "Free-for-All" Dschungel durchzuwaten?


    Danke.

  • Verstehe ich das richtig, du suchst eine Liste o.ä an Assets, welche sich in den Ordnern befinden?


    Und was soll das erste Bild aussagen?


    PS: Falls dir der Speicher zu voll wird, hätte ich einen effizienten Trick:
    - Strecken die du nicht mehr fährst oder uninteressant sind -> löschen
    - Unbrauchbare Assets aus alten Zeiten (ebenso nicht mehr benötigt) -> löschen

    Schön, dass Sie da sind :)!

    2 Mal editiert, zuletzt von Fabian ()

  • Verstehe ich das richtig, du suchst eine Liste o.ä an Assets, welche sich in den Ordnern befinden?


    Und was soll das erste Bild aussagen?


    PS: Falls dir der Speicher zu voll wird, hätte ich einen effizienten Trick:
    - Strecken die du nicht mehr fährst oder uninteressant sind -> löchen
    - Unbrauchbare Assets aus alten Zeiten (ebenso nicht mehr benötigt) -> löschen

    1. Nein.


    Ich suche eine Person, die Ahnung hat ob RailWorks.exe bzw TSxxxx eine eindeutige(!) Hierarchie-Struktur besitzt oder nicht. Gibt es eine eindeutige Ordnung? Wenn ja, wo finde ich die Quelle?


    Die Tutorials und Handbuecher die ich habe (Railworks/DTG) und finde (Community Webseiten) wiederholen alle dieselben "Einsteiger"-Niveau Inhalte.


    Ich finde keine Entwickler-Foren oder Entwickler Diskussionen, welche nachlesbar die Hierarchie-Struktur diskutieren. (UKTS hat ein bisschen was ueber Assets Nutzung. Chris Trains hat ein nettes Tutorial ueber Sounds in TSxxxx).


    Wann findet die exe-Datei einen Unterordner NICHT? Auf welche Weise evaluiert die Game Engine, welche Assets geladen wurden? Wann werden fehlende (oder nicht auffindbare??) Assets ignoriert? Jemand benutzt (veraltete) Assets fuer seine neue Strecke und nutzt sie im Blueprint-Editor. Kann das Spiel auf dem Rechner der Person mit neuesten Assets diese alten Assets finden? Kann RWTools den 'Fehler' erkennen? Etc.



    2. Das Bild zeigt Cajon Pass mit einem grafischen Clipping Fehler, dank eines fehlerhaften Assets (asphaltierte Strasse) in der Route. Es zeigt was 'schiefgehen' kann, wenn Dinge/Objekte nicht eindeutig definiert sind, bzw. ungeprueft(!) ausgefuehrt werden, passend zum Thema und der Ueberschrift.


    [Edit]


    Speicherplatz ist da nicht das Problem, aber Danke. Ich loesche regelmaessig alle "Entwickler" Dateien, nach Gebrauch (also .tgt .cost .bak .xml und .pak)


    (Obwohl fuer sich auch diskussionswuerdig, da unzaehlige Ordner und Dateien wegen Reskins eins zu eins kopiert werden, anstatt sie sinnvoll zu den benoetigten Dateien oder Ordnern einfach zu verlinken, anstelle fuer jeden Reskin eigene (Unterordern) zu kreiren/kopieren.)


    Ich habe uralte Community Strecken aus allen Herrenlaendern (Spanien, Schweden, Daenemark, Australien, NZ, USA, Russland, Italien, Frankreich, etc, etc... von 2006 bis 2018. Was ich kann ist 'saubermachen' - keine doppelten Assets/keine Assets uberschreiben mit alten, weil sie in einem Asset-Zip Installer von 2011 verpackt wurden. Manchmal ist es aber schwer herauszufinden - sogar mit RWTools Hilfe - ob gewisse Dateien nicht doch noch in der Strecke eingebunden werden/wurden.

    3 Mal editiert, zuletzt von Adam Beckett () aus folgendem Grund: Klarere Formulierung (+ erweiterte Erlaeuterung) zum besseren Verstaendnis.

  • Also meiner Erfahrung nach kannst der Entwickler die Ordner so nennen wie er will. Ein Ordner mit scenery Objekten drin muss also nicht zwingend Scenery genannt werden. Die Art des blueprints steht direkt im blueprint, sodass Railworks dort auslesen kann, ob es sich um einen Baum oder einen Zug handelt. Wobei es hierbei doch ein paar Ausnahmen gibt: Zum Beispiel Inputmapper oder Zugbände. Die haben feste Ordner wo sie liegen müssen...

  • Es gibt eine gewisse Ordnerhirarchie, der man folgen KANN (wie in den DevDocs "1.01 Provider & Product Setup.pdf" vom Uraltentwickler Kuju beschrieben), aber im Prinzip kann jeder Entwickler in seinen Provider/Produkt Ordner wüten, wie er will. Das ist auch normalerweise kein Problem, solange alles vernünftig verknüpft ist...wovon man ausgehen kann, wenn es über den Blueprint-Editor erstellt wurde (der würde sonst meckern und es nicht zulassen). Gefährlich wird es erst, wenn man hingeht und eigenmächtig in der Hirarchie herumfuscht und augenscheinliche Fehler korrigiert, ohne die verlinkten Pfade zu ändern. DAS führt dann definitiv zu einer fehlerhafte Installation *shau*

  • Willkommen im Assets Chaos seit Railsimulator.
    Du kannst Strecken im Ordner Content Routes löschen. Aber von Assets löschen rate ich ab, da niemand weiß, welche Assets wo verwendet werden, machste Dir mit Löschungen nur Probleme.
    Strecken auch nie über Uninstall des Utilities exe löschen, da werden dann Assets gelöscht, die mit der Strecke mitgeliefert wurden. Daher nicht wundern wenn andere Strecken leer sind die auch auf diese Assets zugegriffen haben.
    Was Deinem AssetsOrdner hilft ist das Clean Assets-Tool , das es hier im Download gibt und den ganzen unnötig mitgelieferten Entwicklungsmüll von der Platte putzt.
    Grundwissen dazu: Unnötige Daten in Downloadpaketen (und andere zu vermeidende Fehler)

    Keine Hilfe und Auskunft per PN, da meist von allgemeinem Interesse. Diese Fragen bitte im Forum stellen.

  • Hallo @Adam Beckett,


    es gibt nur sehr wenige Vorgaben in der TS-Asset(Ordner-)struktur. Insbesondere sind mit wenigen Ausnahmen keine bestimmten Namen vorgeschrieben:


    1. die Ordner der ersten Ebene unter "assets" geben (jedenfalls aus Sicht des TS) den "Provider" (Hersteller, Entwickler) an.
    Da es keine Registrierung für TS-Entwickler gibt, können natürlich unterschiedliche Entwickler auf dieselbe Idee für den Providernamen kommen. Wenn ich z.B. meine, meine Assets unter dem Titel "Das Track Genie" veröffentlichen zu wollen und als Provider-Ordner die passende Abkürzung DTG nehme, vermischen sich meine Assets eben fröhlich mit denen von DTG (aka RSC)
    2. die Ordner unter der Provider-Ebene geben das "Product" (Addon, Objekt-Bibliothek) an.


    Unterhalb der Produkt-Ebene ist der jeweilige Entwickler in Bezug auf Ordnerstruktur und Namensgebung weitgehend frei.
    Eine der wenigen Vorschriften bei der Namensgebung: Consists für schnelles Spiel müssen sich in einem Ordner mit dem Namen "PreLoad" befinden (Groß/Kleinschreibung spielt keine Rolle), und dieser Ordner muss sich unmittelbar im Produkt-Ordner befinden.


    Die häufig verwendeten Namen "RailVehicles", "Scenery", "RailNetwork" usw. sind keine Vorschrift, sondern sind von Kuju in den Developer Docs nur als Beispiel angegeben, wie sie selbst es gemacht haben.

    Under each add-on product folders you can store your assets in any folder structure. We have used the following ...

    Vorteil für den Entwickler, wenn er die von Kuju verwendeten Namen benutzt, ist lediglich, dass man im Blueprint-Editor nette kleine Icons an den Ordnern hat.


    Natürlich gelten gewisse "best practices" der Software-Entwicklung auch hier: Ordner- und Dateinamen sollten keine Leerzeichen, Sonderzeichen, Umlaute enthalten. Aber da, wie du schon schriebst, die TS-Struktur "free for all" ist, tragen auch Leute zum TS bei, die mit solchen Regeln nicht vertraut sind. Daher gibt es bereits bei diesen elementaren Dingen viel Schrott im TS.



    Jenseits der schoen verpackten .ap Ordner scheint ein absolutes Chaos zu herschen?

    Ja, eben "free for all", weder Registrierung noch Aufnahmeprüfung erforderlich.

    Zitat

    Ab und an finde ich die eigenartigsten 'Nester' (as in nested folders) - Ordner deren Unterordner genauso heissen wie der obere Ordner und die Frage sich aufstellt "Ist das Absicht?" ... oder hat da jemand beim zusammenpacken sich vertan? Findet RailWorks.exe die "RailVehicles" und "RailNetwork" Unterordner in dem Unterordner des Unterordners?

    nicht beim zusammenpacken ... sowas entsteht meist, weil jemand beim "installieren" eine .rwp oder .zip Datei von Hand an der falschen Stelle auspackt. Wenn derjenige dann an einer Strecke baut, landen diese falschen Pfade in der Strecke, und zukünftige Benutzer der Strecke sind gezwungen, die Assets bei sich ebenfalls an der falschen Stelle zu installieren.
    Der TS (railworks.exe) findet die Assets nur an der Stelle, von der sie bei der Content-Erstellung benutzt wurden.


    Zitat

    Namen, welche nach Rechtschreibfehler klingen ( = siehe ScaleRail "Vigitation".

    spielt keine Rolle, da die Namen für den TS keine Semantik (Bedeutung) haben, sondern einfach so, wie sie sind, benutzt werden. Entweder ist die Schreibweise der Asset-Datei identisch zu der in der Strecke benutzten (= gefunden) oder nicht (= nicht gefunden)


    Zitat

    Je nach Ursprungsland der Objekte oder Strecken, sind manche Unterordner in der jeweiligen Landessprache (inklusive Schriftzeichen).

    wie schon geschrieben: grundsätzlich ist dem TS die Schreibweise egal. Sonderzeichen und Umlaute können aber zu Problemen führen - kann gut gehen, muss aber nicht.


    Zitat

    Keine der offiziellen Manuals/Handbuecher scheint dieses Thema anzusprechen?

    außer den alten Developer Docs aus der Zeit bis zu TS 2012.

    Zitat

    Die Entwickler unter euch, welche jenseits der "Ich mach das genauso wie die Anderen"-Methode schmerzhafte Einsicht in die Materie haben, koennt Ihr mich auf Links oder Webseiten-Artikel lenken, welche "Euch" geholfen haben, durch diesen "Free-for-All" Dschungel durchzuwaten?

    Die alten Developer Docs und langjährige Neugier "Wie funktioniert Railworks". Sehr hilfreich dabei ist natürlich eine "Software-Entwickler-Allgemeinbildung" - die verständlicherweise nicht jeder hat.


    Zitat

    Wann findet die exe-Datei einen Unterordner NICHT?

    Kommt normalerweise nicht vor, da der TS schon aus Performance-Gründen Dateien nicht frei im Dateisystem sucht, sondern den konkreten Namen aus dem Content entnimmt. Er findet etwas also nur dann nicht, wenn das Asset nicht an der Stelle / mit dem Namen existiert, die im Content (Strecke, anderes Asset) angegeben ist.

    Zitat

    Wann werden fehlende (oder nicht auffindbare??) Assets ignoriert? Jemand benutzt (veraltete) Assets fuer seine neue Strecke und nutzt sie im Blueprint-Editor. Kann das Spiel auf dem Rechner der Person mit neuesten Assets diese alten Assets finden?

    "Neu" und "Alt" gibt es aus TS-Sicht nicht. Nur unterschiedliche oder gleiche Namen (inkl. Pfad). Wenn eine "neues" und ein "altes" Asset denselben Namen/Pfad haben, kann eben nur eins davon existieren - und zwar das, das der Benutzer als letztes installiert hat. Wenn "neu" und "alt" sich nicht nur in einfachen Eigenschaften (z.B. Farbe) unterscheiden, sondern in der Struktur, dann kann das zum TS-Absturz führen.

    Zitat

    Kann RWTools den 'Fehler' erkennen? Etc.

    RW-Tools guckt auch nur, ob es ein Asset mit exakt dem Namen/Pfad gibt oder nicht.

    Zitat

    Es zeigt was 'schiefgehen' kann, wenn Dinge/Objekte nicht eindeutig definiert sind, bzw. ungeprueft(!) ausgefuehrt werden, passend zum Thema und der Ueberschrift.

    Das ist genau das, was zu der Flut von Freeware für den TS geführt hat: jeder(!) kann was dazu tun, egal ob er es "gelernt" hat oder nicht. Bevor die Strecken+Szenarien so groß wurden, dass sie ständig an der Speichgrenze kratzen, war diese Asset-Anarchie die häufigste Ursache für TS-Abstürze. Gegenkonzepte dazu sind die globale Datenbank bei Trainz (wo die Installation eines Assets "Stunden" dauert, weil dabei die Assets geprüft und komplett in die Datenbank eingebunden werden) oder die geschlossenen Pakete im TSW.

    Zitat

    (Obwohl fuer sich auch diskussionswuerdig, da unzaehlige Ordner und Dateien wegen Reskins eins zu eins kopiert werden, anstatt sie sinnvoll zu den benoetigten Dateien oder Ordnern einfach zu verlinken, anstelle fuer jeden Reskin eigene (Unterordern) zu kreiren/kopieren.)

    das ist oft zwingend erforderlich, da die Texturdatei in der 3D-Modell Datei (*.geopcdx) relativ zu eben dieser Datei angegeben werden. Zum Verlinken auf andere Texturen müsste man die Modelldatei ändern, was nicht praktikabel ist, da man die in der Regel nicht verteilen darf.

  • @nobsi


    Wow! Vielen Dank, dass Du Dir die Muehe gemacht hast.


    Je mehr ich micht mit Railworks/TSxxxx beschaeftige desto erstaunlicher kommt es mir vor, wie 'gut' und stabil es immer noch funktioniert, alles in allem.


    Wirklich schade, dass man nicht die Chance hat den Quellcode neu zu kompilieren und die 32bit Grenze zu sprengen.


    DTG's TSW/FSW Geklicke im Unreal Editor ueberzeugt mich noch nicht.