Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Constraints
#1
Hi Community,
Die Constraints sind ein tolles Werkzeug um die Fahrzeugzusammenstellungen einzuschränken. Ich finde allerdings die Umsetzung aktuell recht unflexibel und unnötig kompliziert (Angabe Prev/next)
Was mich immer wieder an den Constraints stört ist
1. dass man einen Wagen nur einmal oder beliebig oft einsetzen kann, ohne diesen mehrfach zu definieren.
2. dass man in festen Multiple Units immer prev und next angeben muss.

Meine Idee dazu ist recht einfach: Die Fahrzeuge mit ihren restlichen Werten haben erstmal nichts mit der Zusammenstellung zu tun. Also könnte man die Constraints aus den dats der Fahrzeuge raus nehmen und in eine (oder mehrere) dats auslagern. Vorzugsweise sollte diese Datei auch nicht von makeobj übersetz werden, sondern beim Spielstart eingelesen werden.

In der/den Constraints Datei(en) würde man dann alle Constraints definieren und dabei auf die Fahrzeug Objekte verweisen. Auf ein solches Objekt kann mehrfach verwiesen werden. Dadurch würde man es ermöglichen über Constraints Wagenzusammenstellungen aus der Realität abzubilden, ohne gleich das Depot vollzumüllen. In meinem Depot gibt es alleine 16 Wagen für den Eurostar E320...
Man sollte sich nochmal Gedanken drüber machen wie genau man die Constraints dann definieren möchte. Die aktuelle Lösung mit prev/next finde ich eher unpraktisch.

Meine Ideen dazu wäre etwas ähnliches wie einen regulären Ausdruck dafür zu verwenden.
Eine Constraint Zeile wäre dann z.B. etwas wie
"(ICE2_powerHead (ICE2_car|ICE2_post)* ICE2_diningCar
(ICE2_car|ICE2_post)* ICE2_cabTail)* (ICE2_cabHead (ICE2_car|ICE2_post)*
ICE2_diningCar (ICE2_car|ICE2_post)* ICE2_powerTail)*",
Wobei "*" für beliebig häufig, "?" für optional und "|" für oder steht und die ICE_... Objekte alle in einer dat definiert wurden.
Für relativ einfache Constraints wie hier (ein ICE2 besteht aus maximal 2 Teilzügen, wobei niemals 2 Triebköpfe aneinandergekuppelt werden, ein Teilzug kann vorwärts oder rückwärts fahren und enthält immer einen Steuerwagen, einen Speisewagen und einen Triebkopf)
wäre ein solcher Ausdruck auch noch recht übersichtlich. Für komplexere Constraints wird es dann unübersichtlich aber solche komplexen Constraints wären mit dem aktuellen System garnicht erst möglich ohne zig Wagen zu definieren.

Meine andere Idee dazu wäre etwas ähnliches wie die BNF zu verwenden.
Kurzfassung der BNF: Teilzusammenstellungen bekommen einen Namen und
diese kann man an anderer Stelle wieder mit und bzw. oder (rekursiv)
aneinanderketten.

eine BNF zu dem obigen Ausdruck wäre die folgende:
ICE2_CARS:=ICE2_CARS ICE2_CARS|ICE2_car|ICE2_post|_EPSILON_
ICE2_MID:=ICE2_CARS ICE2_diningCar ICE2_CARS
ICE2:=ICE2_powerHead ICE2_MID ICE2_cabHead
ICE2_REVERSE:=ICE2_powerTail ICE2_MID ICE2_cabTail
ICE2_COMP:=ICE2|ICE2_REVERSE|ICE2 ICE2|ICE2 ICE2_REVERSE|ICE2_REVERSE ICE2_REVERSE

wobei _EPSILON_ für "garnichts" steht. Es geht auch ohne das Epsilon aber dadurch wird der Ausdruck länger.
Man
müsste dann festlegen welche dieser Definitionen tatsächlich einen
fahrbaren Zug beschreiben und welche nur Hilfskonstrukte sind.

In beiden Fällen müsste man auch etwas wie ein "nimm alles an" Wort einführen, um zi signalisieren, dass an dieser Stelle alles erlaubt ist. none würde wegfallen. Schön wären noch reservierte Worte, die für alle Loks, alle Güterwagen, alle Postwagen bzw. alle Personenwagen stehen aber ich glaube an dieser Stelle kann das Spiel die nicht sauber voneinander unterscheiden.

Ich selbst habe noch nie in C++ programmiert (Simutrans ist in C++ geschrieben oder?), würde bei dieser Funktion aber so weit wie ich kann mithelfen.

Worüber ich mir noch keine genaueren GEdanken gemacht habe ist die Frage wie man im Falle des regulären Ausdrucks herausfinden kann welche Fahrzeuge als nächstes erlaubt sind.
Zitieren
#2
Das ist System der Beschränkungen ist intern aber ganz und gar nicht mit den regulären Ausdrücken kompatibel. Das müsste dann von Grund auf neu gemacht werden.

Allerdings ist es vermutlich mit der Skript-engine möglich, auch Fahrzeugen Skirpte zuzuweisen, die dann die Zusammenstellung überprüfen. Ob das (oder auch reguläre Ausdrücke) allerdings nicht zuviel für Ottonormalgrafiker ist ...
Zitieren
#3
Geht das mit den Scripten jetzt schon? Wen ja würde mich das echt interessieren.
Wie auch immer: Der Hauptpunkt ist, dass das aktuelle System in dem die Constraints strikt an ein Fahrzeug gebunden sind zu vielen Wagen im Depot führt und man die Werte für jedes ansonsten identische Fahrzeug einzeln anpassen muss.
Ich als Ottonormalpixler, als Grafiker würde ich mich nicht
bezeichnen, überlege mir immer vorher wie die MU zusammenstellbar sein soll und vergesse bei eintragen in die dat immer wieder einen Eintrag in den aktuellen
Prev/next Constraints einzutragen. Wenn ich mal nichts vergessen habe
einzutragen, dann habe ich irgendwo den Index nicht hochgezählt oder
mich bei einem Objektnamen vertippt.
Ich fände es also wirklich pixlerfreundlicher die Constraints vom Rest losgelöst übersichtlich in einer Datei zu haben.
Ist es also ohne gleich alles neu schreiben zu müssen möglich die Constraints vom Rest des Fahrzeugs zu lösen und die Constraints so zu basteln, dass einem Fahrzeug mehrere Constraint Gruppen (ich nenne sie jetzt mal so) zugeordnet werden?
Intern existieren dann vermutlich nach wie vor mehrere Fahrzeuge (eines Je Constraint Gruppe) aber im Depot würde man dieses nur als eines Darstellen, da alle Daten bis auf die Constraints identisch sind.
Die Frage ist dann blos welcher der Wagen wird genommen, wenn es mehrere mögliche Wagen an der Stelle gibt...
Es ist also wohl doch nicht ganz so einfach. Dennoch: Die aktuellen Constraints erlauben es nicht ohne das Depot und die dats vollzuspammen Wagenreihungen zu definieren und das finde ich sehr schade, da z.B. Speisewagen aufgrund der geringen Kapazität so quasi nie ingame zu sehen sind.
Aktuell löse ich das Problem, indem ich Wagen definiere hinter denen ein Speisewagen folgen kann und die gleichen Wagen nochmal so definiere, dasss diese auf einen Speisewagen folgen können. Nur hinter letztere kann none folgen. Ist aber echt mehr ein Kompromiss.
Wie genau man diese Contraint Dateien umsetzt kann man sich ja überlegen. Für den genannten Ottonormalpixler, der nur einfache Constraints verwendet, die einfach nur MUs aus Triebkopf, Wagen, Triebkopf zusammenstellen oder einen Tender an eine Dampflok zwingen (mehr habe ich zumindest bisher in pak128 nicht gefunden) wären die beiden vorgeschlagenen Systeme auch kein Problem.
In einem Fall wäre das etwas wie
"Dampflok_RVg_1E0 Dampflok_RVg_1E0 _ANY_"
bzw.
RVg_1E0_COMP:=Dampflok_RVg_1E0 Dampflok_RVg_1E0 _ANY_
und im Falle einer für pak128 schon komplizierten MU wäre es einfach
"(Haru_Spike-PSE_Head1 Haru_Spike-PSE_Head2 Haru_Spike-PSE_Waggon* Haru_Spike-PSE_Tail2 Haru_Spike-PSE_Tail1)*"
bzw.
PSE_CARS:=Haru_Spike-PSE_Waggon PSE_CARS|PSE_CARS
PSE:=Haru_Spike-PSE_Head1 Haru_Spike-PSE_Head2 PSE_CARS Haru_Spike-PSE_Tail2 Haru_Spike-PSE_Tail1
PSE_COMP:=PSE_COMP PSE

Die 2. Variante ist ewas mehr zu schreiben aber imho sind beide Varianten übersichtlicher und grafikerfreundlicher als die prev/next Constraints und bieten wenn man es denn benötigt noch viel mehr Möglichkeiten als die aktuellen.
Zitieren
#4
Mit Timeline ginge es schon das Depot übersichtlicher zu halten.

Man braucht nur diversen Fahrzeugen ein sehr frühes Ausführungsdatum zu geben. Durch die automatische Reihung wird es trotzdem angereiht, auch wenn es nicht angezeigt wird.

Hat halt den Nachteil, das dann alles Blau wird für veraltet und in den Daten das falsche Ausführungsjahr steht.
Zitieren
#5
@FrankP das ist auch ein nützlicher Kompromiss über den ich bisher noch nicht nachgedacht habe. Leider aber eben auch wieder nur ein Kompromiss, da es wie du schon sagtest eben nur mit timeline funktioniert und trotzdem die Werte für jedes ansonsten identische Fahrzeugs einzelnd angepasst werden müssen. Außerdem sind dadurch die Linien permanent blau, was zumindest für mich immer bedeutet, dass ich die Linie überprüfen und erneuern sollte.
Das 2. Problem löse ich aktuell mit einem dat precompiler der Makros in dats auflöst. So muss ich zumindest alle Daten bis auf den Objektnamen und natürlich die Constraints nur einmal setzen. Aber so wirklich gut ist die Lösung auch wieder nicht, da das am Ende auch wieder nur zu vielen quasi identischen Objekten übersetzt wird.
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste