Vorankündigung: Mod für individuelle Gleistypen-Anpassung

Da sich das Straßenbahnprojekt erst einmal eine Pause gönnt, habe ich eine andere Sache dazwischengeschoben, auch wieder mal eins der Vorhaben, die schon lange angedacht waren. Es handelt sich um eine Mod, mit der man beliebige (!) Gleistypen mit einer Reihe von Attributen versehen kann, die sie nativ nicht besitzen. Darunter unterdrückte Oberleitungsmasten, Fahrdrähte und Prellböcke, Änderung der Geschwindigkeit, Gleisbettfarbe, Böschung etc. Ist das so was wie die Jokerstraßen? Ja, aber anders. Man kann besser sehen, was man tut, und die Anzahl der neuen Gleistypen ist unbegrenzt. Es können allerdings keine bereits verlegten Gleise verändert werden, und eine Erzeugung weitergabefähiger Gleistypen ist auch nicht geplant. Außerdem wird in den meisten Fällen die Installation der Original-Gleismods nötig sein. Es wird in dieser Mod auch keine Funktionen geben, mit denen Gleistypen anderer Mods durchgehend geändert werden können; es werden grundsätzlich nur neue einzelne Gleistypen erzeugt.

Ich denke mal, gerade im Hinblick auf ziehbare Oberleitungen und Verschlankung des Gleistypen-Bestandes haben sich schon einige von euch so was gewünscht. Es werden aber noch ein bis zwei Wochen bis zur ersten Beta vergehen, denn es muss wie üblich wieder viel Forschung betrieben werden.

Quote

Bevor hier wieder wegen paralleler Entwicklung gemeckert wird.

Ich habe überhaupt nichts gegen CommonAPI, aber es soll auch Leute geben, die CommonAPI nicht benutzen, z.B. die User auf Steam oder die Linux-Leute. Oder diejenigen, die sich aus welchen Gründen auch immer für einen anderen Weg entscheiden. Vielleicht wird es eine Doppelentwicklung, aber dann hat eben auch jeder zwei Optionen.

Quote

Ich möchte nur anmerken, das die Gleisgeschwindigkeit per Region in CommonAPI2 geändert werden kann.

War mir nicht bekannt. Aber wieso wird dann jede Gleismod mit gefühlt Hunderten von Varianten geliefert, die alle nur die Menüs verstopfen? BTW Was meinst du denn mit "per Region"?

Quote

Wie, ich kann keine Gleise ändern, die ich nicht habe

Es werden Klone angefertigt, bei denen der größte Teil der vorhandenen Informationen kopiert wird. Einige Parameter können dann geändert werden. Eigentlich alles, außer den Schwellen und den Schienen, weil dazu separate Modelldateien notwendig sind, die sich nur sehr eingeschränkt über die Transformationsmatrix ändern lassen.

Quote

Außer lollus höchstens, der macht das mit ein paar Straßen.

Auf demselben Wege mache ich das auch

Quote

In der neuen dynamischen Ressourcenverwaltung ist "maxSlope" leider nicht mehr vorhanden und kann nicht in der postRunFn gesetzt werden.

Danke für den Hinweis. Muss ich mal austesten. Falls dem so ist, kann ich das leider nicht implementieren. Edit: Hatte den folgenden Satz nicht gelesen. Wenn es doch da ist, ist es ja kein Problem mehr. Werde es aber dennoch testen.

Quote

d.h. dynamsich hinzugefügte Gleise werden nicht beeinflusst (denke da zB an deinen Kurvengeschwindigkeitsanpasser). Das muss man bedenken, aber man will die custom Gleise ja eh selbst konfigurieren.

Aber es werden immerhin die Originalgleise in der RunFn angepasst, und wenn diese wiederum anschließend dynamisch kopiert werden, werden deren Änderungen mit übernommen, was letztendlich auch zum Ziel führen dürfte. Und wenn es Parameter sind, die in den Klonen selbst geändert bzw. überschrieben werden, ist es ohnehin egal.

Quote

Eine lange Liste von Modoptionen? Das könnte halt schnell explodieren.

Soo lang ist sie nun auch wieder nicht. Zumal bestimmte Parameter wie die Farbe und Form der Schwellen und Schienen nicht ohne riesigen Aufwand beeinflusst werden können, da ich dann Parameter in den mdls ändern müsste, übrigens auch ein Manko des bestehenden Systems. Momentan könnte ich ausschließlich die Transformationsmatrix ändern. Also entfallen diese Features schon mal.

Bleibt noch das hier übrig; es ist nicht viel mehr als bei den Jokerstraßen, wo ich es zudem noch zehnmal ausgeben muss:

Quote

Wenn die Konfiguration aus irgendwelchen Gründen futsch geht, sind Gleistypen weg und werden mit Dummys ersetzt oder Parameter ändern sich, was in manchen Fällen problematisch sein kann: Wenn sich bei verbauten Straßentypen die Breite ändert kann man sie nicht mehr abreißen. Das erfordert also einige Checks. Aber das weißt du bestimmt bereits...

Auf die Dummys werde ich hinweisen. Wichtig ist, dass die Settings nicht verlorengehen, und dass eingebaute Klone möglichst gelöscht werden. Ansonsten ist ja wie bei ganz normalen Gleisen: Wenn die Mod fehlt, sind noch Dummys da, bei denen mir bis auf das Zumüllen des Savegames keine schädliche Wirkung bekannt ist, außer natürlich in uralten Spielversionen, worauf ich auch hinweisen werde. Sollten irgendwelche Mods mit diesen Dummys nicht zurechtkommen, liegt das Problem bei diesen Mods - aber letztendlich empfehle ich ja auch, die Dummys zu löschen, solange sie nicht in großen Mengen eingebaut wurden. Habe sogar extra einen Zähler dafür eingebaut.

In die Settings sollte nichts manuell eingetragen werden (zuminest nicht, wenn man nicht weiß, was man tut), und für das Sicherungsproblem gibt es den SettingsSaver, der auch unterstützt wird. Separate Settings sind vielleicht ein Nachteil gegenüber dem Jokerstrassen-Konzept, wo die Settings in den Mod-Einstellungen gemacht werden und dann im Savegame verbleiben. Ich könnte mir noch einmal Gedanken machen, ob ich sie via save-load aus der Game-API heraus ins Savegame schreiben könnte.

Konfigurationen können nicht rückwirkend geändert werden, da stets ein neues Gleis erstellt wird. Ein Vorteil gegenüber den Jokerstraßen! Klone können übrigens auch nicht nochmals geklont werden, um Chaos und lange Namen zu vermeiden. Und um dreistes Abkupfern zu vermeiden, funktioniert die Mod immer nur über die Originale und kann im Gegensatz zum SettingsSaver auch keine eigenen speicherbaren Gleisdateien erbrüten.

Ach ja, ein von dir noch gar nicht erwähntes anderes Problem konnte ich auch lösen.

Bei der Gelegenheit ist mir aber noch eine Frage aufgefallen: Im UG-Wiki ist von einer Vergabe von IDs für dynamisch erzeugte Dateien im Repository die Rede. Bei diesen IDs soll es sich wohl nicht um Strings, sondern um Nummern handeln. merkwürdigerweise habe ich sowas noch nie gesehen. Ist jemandem von euch schon einmal so ein Fall begegnet?

Was mich etwas irritiert hat: Im UG-Wiki befindet sich ein Musterskript für die Erzeugung dynamischer Bahnhofsmodule aus dynamisch erzeugten Gleisen. Hier ein Codeschnippsel:

if trackName ~= "standard.lua" and trackName ~= "high_speed.lua" then
    for __, catenary in pairs({false, true}) do
    mod.fileName = "trainstation_" .. tostring(trackName) .. (catenary and "catenary" or "")

Was macht tostring dort? Daraus schließe ich, dass der Gleisname auch mal eine Zahl sein könnte, sonst bräuchte man das ja nicht. (Wobei man es nach den Lua-Regeln selbst dann nicht unbedingt brauchen würde. )

VacuumTube: Ich habe die Sache mit den Modifiern in RunFn noch einmal überprüft. Ich hatte zunächst selber ein wenig Sorge, dass es hier Probleme geben könnte. Aber es besteht kein Grund zur Panik: Die Modifier verändern zwar nicht die Klone, die zu diesem Zeitpunkt noch gar nicht existieren, aber die Klone kopieren wiederum in postRunFn die normalen Gleise und deren modifizierte Parameter, wie ich schon schrieb. Dadurch, dass die Klone bei jedem Spielstart neu generiert werden, werden die Daten aus runFn auch ständig in den Klonen aktualisiert.

Sollten die Klone eigene Werte setzen, haben diese natürlich Vorrang, was auch Sinn macht.

Fremde modifizierende Mods in postRunFn wären sogar das größere Problem. Zu diesen Mods gehört z.B. mein eigener Menü-Manager, wo dann die Ladereihenfolge ein Rolle spielt. Größtenteils kann ich aber zumindest hier diese Probleme durch ein Workaround abfangen.