BlueprintEditor2, Manual oder Anleitung


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

    Danke.


    Die DevDocs habe ich schon, und das manual zum BlueprintEditor ist nur ein kleinerer Teil davon, 10 Jahre hat das auch schon auf dem Buckel und mittlerweile hat es für BlueprintEditor und TS schon einige Schönheitskuren gegeben.


    Schade, wenn es wieder mal nur mit try and error gehen muss, ...


    ... eigentlich hatte ich was ganz anderes mit TS vor :D .

    Zitat von Schoenbiehl

    Schade, wenn es wieder mal nur mit try and error gehen muss, ...

    stimmt so nicht ganz.


    Es stimmt, dass die genannten DevDocs den TS Stand vor/maximal bis TS 2012 repräsentieren.
    Spätere Erweiterungen sind in jeder Railworks-Installation im Ordner railworks/dev/docs dokumentiert.


    Das betrifft sowohl die UI-Erweiterungen, als auch viele neu hinzgekommene Blueprints.

    Ich war recht irritiert von einer Diskussion, ob RWTools oder BPE2 zum soliden Anlegen des RouteTemplate besser ist, bzw. was womit überhaupt möglich ist etc.


    Für mich hat das nicht viel gebracht, außer dass ich hier erstmal eine Auszeit genommen habe, mit beiden experimentiert und eine Menge gelernt habe, alles nur mit dem Ziel, ein solides RouteTemplate und die eine oder andere Datei darum herum einschließlich Verzeichnisstrukturen nachvollziehbar anzulegen und zu verstehen. Mir geht es erst einmal nur um Streckenbau einschließlich funktionierender Bahntechnik mit einem vernünftigen RouteTemplate als Basis. Objektbau habe ich erst einmal nicht vor.


    Dabei bin ich auf wesentliche Unterschiede zwischen beiden tools gestoßen. RWTools kommt zwar mit weniger Eingaben aus, aber man kann die erzeugten Dateien mit RWTools nicht so ohne weiteres noch einmal editieren. Beim BPE2 scheint das eher umgekehrt zu sein. Wie es aussieht, liegen die fertig editierten "Rohdateien" für BPE2 z.B. als .xml in \Source\, werden dort von BPE2 abgeholt und mit anderen Dateien zu einem blueprint zusammengestellt und dann für TS "gebrauchsfähig" exportiert.


    Ich nehme gerne die etwas umfangreicheren Eingaben beim BPE2 in Kauf, wenn ich dadurch tatsächlich den Vorteil habe immer wieder auf die Quelldaten zugreifen zu können, was bei RWTools nicht ganz so einfach, wenn nicht sogar unmöglich ist.


    Nach dem manual habe ich gefragt, weil ich mich in die etwas aufwendigere Arbeit mit dem BPE2 einlesen will. Die DevDocs einschließlich der updates enthalten zwar viele Hinweise in Richtung BPE2, aber leider weit verstreut.


    Beste Grüße
    Schoenbiehl

    Zitat von Schoenbiehl

    Dabei bin ich auf wesentliche Unterschiede zwischen beiden tools gestoßen [ ... ]

    Treffend festgestellt.


    Ist letztlich wie in der Entwicklung regulärer Software auch:
    Wenn ein Programm korrigiert bzw. erweitert werden soll, nehmen professionelle Entwickler die erfoderlichen Änderungen in den SOURCE-Dateien vor (die auch in einem Versionierungsystem wie Git archiviert werden), kompilieren, testen, und liefern die neu compilierte .exe Datei aus. Sie fummeln nicht mit einem Hex-Editor an der alten .exe-Datei rum.


    In gleicher Weise werden bei der Entwicklung für den TS die Blueprints im BPE bearbeitet. Der BPE hat immer den vollständigen Zugriff auf die Blueprint-xml Dateien, die hier auch ähnlich wie oben erwähnt in Git versioniert werden können. Der BPE hat auch - ähnlich wie allgemeine Software-Entwicklungssysteme - eine "Make" Funktionalität (F7), die auf Tastendruck gleich für eine ganze Ordnerhierarchie genau die Dateien neu konvertieren und von /Source nach /assets exportieren, die seit dem letzten Makt geändert wurden. Das spart enorm Zeit, wenn man tatsächlich einen echten eigenen Strecken-Source-Ordner hat. Außerdem ist z.B. die Änderung von Farben mittels RGB-Schieberegler (z.B. für die Farbe der Morgendämmerung oder der Distant Terrain Color) im BPE doch wesentlich anschaulicher als die Änderung von nackten RBG-Werten in serz-konvertierten Asset-Dateien.


    Genau wie Hacker mit einem Hex-Editor in einem Programm für das sie keine Source-Dateien sondern nur die ausgelieferte exe Datei haben, manche Änderungen machen können (wenn auch oft nicht ohne Kollateralschäden), können auch TS-User, die von fremden Assets nunmal keine Source-Dateien haben, sondern eben nur die ausgelieferten "compilierten" Assets, mit einem Hex-Editor bzw einer Handvoll Utilities wie serz, rsbintool und einem xml-Editor einiges an den vorhandenen Assets anstellen.


    Da hat Mike Simpson in den Jahren schon einiges geleistet, mit viel Trial and Error dieses "TS-Hacking" so zu verpacken, das recht viele User damit einige Wünsche umsetzen können. Aber eben immer auf der binary Seite (den Assets), den genau das war ja der Sinn: der normale TS-User hat ja keinen Zugriff auf Source-Dateien der Entwickler. Dieser Ansatz verdeulicht auch gleichzeitig, wozu RWTools gedacht war: für Änderungen an "fremden" Assets für den eigenen Bedarf. Denn man man keine Source-Dateien hat, ist das ja in den meisten Fällen ein Zeichen dafür, dass man auch keine Urheberrechte hat, die geänderten Assets weiter zu geben.

    Moin,


    an statt zu meckern, habe ich mich jetzt daran gemacht, die Erstellung eines route template mit dem BPE2 zu beschreiben einschließlich Informationen was dabei noch so passiert, insbesondere beim Export. Dabei will ich möglichst nur auf RWTools und Co. zugreifen, wenn es nicht anders geht.


    Wenn die Beschreibung sicher funktioniert, würde ich sie gerne Rail-Sim zur Verfügung stellen.


    Bei der Gelegenheit habe ich z.B. gelernt, dass .ap Dateien eigentlich .zip Dateien mit falscher Namensendung sind, und dass TS auf die .ap Dateien einschließlich der Verzeichnisstrukturen und natürlich Daten zugreifen kann, wobei die Struktur der .ap Datei eine Art Verlängerung des Unterverzeichnisses ist, in dem die .ap Datei liegt, ...


    ... aber ich hatte ja schon geschrieben, dass ich mit Train Simulator was ganz anderes vorhabe :) .