Unterteilung der Lkw in Bezug auf Anhänger

[The Transporter]

Grundsätzlich ist mein Ansatz ja für die Lkw's gedacht, die Schiene ist eher zweitrangig.
Um einem Lkw eine Anhängergruppe zuzuordnen, muß bei jetzigen Stand, jeder Anhänger einzeln mit constraint genehmigt werden. Anhänger die im constraint Block nicht aufgeführt sind, sind auch nicht erlaubt angehängt zu werden. Bei 40 Anhänger im Set wäre dann der constraint Block in der dat dementsprechend 40 Zeilen lang. Was viel Aufwand ist, und auch sehr fehleranfällig ist.
Bei meinem Ansatz wäre das jeweils nur ein kurzer Einzeiler (z.B. traction_engine=3), der auch noch bei Zugmaschine und den Anhänger gleich ist. Also ganz einfach und übersichtlich ist.
Ich bin auch mittlerweile zu der Ansicht gekommen, das 10 oder 20 traction_engine Typen doch zuwenig sind, um die damit vielfältigen Möglichkeiten abzudecken. 100 (0-99) oder unbegrenzt sollte dann doch sein. Mir sind immer neue Spielvarianten eingefallen.
Ich finde die es besser wenn vom Grafikset die Vorgaben gemacht werden, das sorgt für eine klare Linie.
Wer viel mit den Fahrzeugen arbeitet, der hat die paar Zahlen schnell im Kopf, und muß nicht lange ansehen. Wer nur hi und da mal damit arbeitet, der muß sowieso nachsehen wie es funktioniert. Und sehe ich bei den Zahlen auch kein Problem.
Dein System gibt zwar mehr Freiheiten, sorgt aber, bei reichlich Nutzung ganz schnell zu einem heillosen Wust. Dein System versagt aber genau dann, wenn aus irgendeinem Grund des Referenzfahrzeug entfernt oder auch nur umbenannt wurde, dann läuft der Alias ins leere, was der stabilität von Simutrans nicht wirklich bekommt.
Bei meinem System müßte dazu schon eine ganze Fahrzeuggruppe entfernt werden, was schon prinzipbedingt keinen Sinn machen würde. Da liegt meine Idee eindeutig auf der stabileren Seite.

[prissi]

Gruppen ist recht einfach zum implementieren, speziell wenn es Zahlen sind. Strings wird schon etwas komplizierter.

Allerdings müsste dann man vermutlich zwei Einträge "Muss in Gruppe xyz sein" und "darf nicht in Gruppe xyz sein" haben, sonst gehen wieder nur die Hälfte der Bedingungen.

[Leartin]

Bei meinem Ansatz wäre das jeweils nur ein kurzer Einzeiler (z.B. traction_engine=3), der auch noch bei Zugmaschine und den Anhänger gleich ist. Also ganz einfach und übersichtlich ist.

Verstehst du immer noch nicht, dass bei meinem Ansatz ebenfalls bei jedem Fahrzeug nur eine Zeile benötigt wird, oder warum hebst du das als Vorteil deines Systems hervor?

Dein System gibt zwar mehr Freiheiten, sorgt aber, bei reichlich Nutzung ganz schnell zu einem heillosen Wust. Dein System versagt aber genau dann, wenn aus irgendeinem Grund des Referenzfahrzeug entfernt oder auch nur umbenannt wurde, dann läuft der Alias ins leere, was der stabilität von Simutrans nicht wirklich bekommt.

Das stimmt so nicht. Wenn das "Referenzfahrzeug" gelöscht wird, dann gibt es eben kein Fahrzeug mit diesem Objektnamen mehr, das stört aber Fahrzeuge mit diesem Alias nicht.
Wenn in den Constraints des Zugfahrzeuges der entsprechende Eintrag gelöscht wird versagt das System - allerdings versagt es ja bei dir auch, wenn im Zugfahrzeug die Traction_engine gelöscht oder geändert wird, da ist man wieder gleich auf.
Die Behauptung, Constraints würden eher geändert werden, ist nicht weitblickend - theoretisch stimmt es zwar, aber nur bei Addons zu denjenigen Paksets, die das System nicht aktiv nutzen. Diejenigen Addons, die bei deinem System gar nicht erst möglich wären. Wenn die Paksetentwickler das System aktiv verwenden, dann steht in den Constraints sowas wie "GROUP_HORSECART", das löscht doch kein vernünftiger Entwickler.

[The Transporter]

1.)   The Transporter schrieb:
   Bei meinem Ansatz wäre das jeweils nur ein kurzer Einzeiler (z.B. traction_engine=3), der auch noch bei Zugmaschine und den Anhänger gleich ist. Also ganz einfach und übersichtlich ist.

Verstehst du immer noch nicht, dass bei meinem Ansatz ebenfalls bei jedem Fahrzeug nur eine Zeile benötigt wird, oder warum hebst du das als Vorteil deines Systems hervor?

Du hast mal wieder nicht gelesen, was ich geschrieben habe!
Ich habe Dein System mit dem von Dir zitierten Satz überhaupt nicht angegriffen, sondern nur einen Vergleich mit dem "ist" gemacht.

2.) Wenn in den Constraints des Zugfahrzeuges der entsprechende Eintrag gelöscht wird versagt das System - allerdings versagt es ja bei dir auch, wenn im Zugfahrzeug die Traction_engine gelöscht oder geändert wird, da ist man wieder gleich auf.

Nicht ganz, weil es in Deinem System nur 1 Referenzfahrzeug gibt, bei meinem aber eine ganze Gruppe. Wie ich schon geschrieben habe (was Du wohl auch nicht gelesen hast), müßte bei meinem System die ganze Gruppe gelöscht werden (nicht nur ein einzelnes Fahrzeug), erst wenn die ganze Gruppe gelöscht werden würde, wären wir auf dem selben Stand.

3.) Die Behauptung, Constraints würden eher geändert werden, ist nicht weitblickend

Wer hat das wann geschrieben?????

4.)Diejenigen Addons, die bei deinem System gar nicht erst möglich wären

?????
Du hast Dir doch noch garnicht die kleinste Mühle gemacht, zu verstehen was ich erreichen möchte. Du versuchst dauernd irgendwelche Nachteile in meinem System zu erfinden!

5.)Wenn die Paksetentwickler das System aktiv verwenden, dann steht in den Constraints sowas wie "GROUP_HORSECART", das löscht doch kein vernünftiger Entwickler.

Also sind bei Deinem System doch Vorarbeiten von den Grafiksetentwickler nötig.
Übrigens stehen wir an dem Punkt auf den Selben (siehe Zitat 2.) Stand

Kann es sein, das Du Dich mit meiner Idee angegriffen fühlst, so wie Du alles nur schlecht machst bzw. falsche Behauptungen aufstellst, ohne wirklich zu lesen, was geschrieben wurde?
Eine sachliche Diskussion läßt Du ja nicht zu.
Für Dich gibt es nur Dein System, alles andere wird nicht zugelassen!

Schön wäre es, wenn sich auch mal ein paar andere zu dem Thema melden würden.

[makie]

Was soll der Streit.
Solange ihr niemand gefunden habt der das umsetzt ist das reine heiße Luft.
Und wenn ihr jemand findet, dann wird er das letztendlich so machen wie er das für richtig hält.

Meinen Vorschlag kann ich wenigsten selbst umsetzen.
Mal sehen ob es mir der Mühe Wert ist. Steht jedenfalls ganz hinten in meiner to do Liste.

[prissi]

Das Depotfenster macht eher wenig Arbeit, aufwendiger ist die Führung der Gruppen, wen wenn es Strings sein sollen, das Einbinden in makeobj. Zahlen (etwa beschränkt auf 1 bis 31) kann man leicht bitweise abklappern, Strings müsste man nach wegtype hashen und durchzählen, das wird es aufwendiger.

Zu klären ist, wenn sich constraits und Gruppen auschliessen, also jemand nicht mit x darf, aber x diesen als Nachfolger bestimmt. Was dann?

[Wurzelgnom]

...
Zu klären ist, wenn sich constraits und Gruppen auschliessen, also jemand nicht mit x darf, aber x diesen als Nachfolger bestimmt. Was dann?

Das Problem gibt es jetzt bereits auch schon.

Anderer Vorschlag

Wie wäre es eine eigene Definitionsdatei dafür zu verwenden. Diese wäre als Textdatei dann frei zugänglich. Vor allem stünde nur das benötigte drin ( die Objektnamen ). Auch Addon-Fahrzeuge könnte man so einfach eingliedern ohne für jedes Set eine eigene Pak-Datei zu bauen.

NEXT würde dann so definiert

FahrzeugA = Fahrzeug 1, Fahrzeug3, Fahrzeug L

Und das PREV könnte man dabei automatisch erzeugen. Wenn ein Fahrzeug folgen darf, muss ja zwangsläufig das andere auch vorangestellt werden dürfen. Zumindest für Straßenfahrzeuge wäre das durchaus machbar denke ich.

Hauptproblem bei der Fahrzeugreihung ist das Verstreute. Also das die Einträge in mehreren Datendefinitionen in diversen Dateien stehen und man da schnell was übersieht.

[The Transporter]

Am Depotfenster habe ich keine Änderung vorgesehen.
In Bezug auf das Depotfenster verhält es sich ja gleich, wie die aktuell lange constraint Einträge.

Da die Idee speziell für die Straßenfahrzeuge gedacht ist, würde ich sagen das Grundsätzlich bei den Straßenfahrzeugen nur 1 Anhänger erlaubt ist, außer es wird durch einen normalen constraint Eintrag explizit ein oder 2 zusätzlich Anhänger erlaubt.

Sollte das System auch für die Schiene Anwendung finden, wird es sowieso komplizierter, da hier besonders die Tender eine besondere Behandlung brauchen. Tender müßten sich Transparent verhalten, also die Gruppe der Lok annehmen, an die sie angehängt werden.
Bei den Schienenfahrzeugen darf dann auch keine Beschränkung der Anzahl von Wagen geben.

Bei Triebzüge mit ihren besonderen Wagen- Lokkombinationen wie z.B. den ICE oder S-Bahnzüge, ist es sinnvoller beim alten constraint zu bleiben. Hier werden ja die Loks und Wagen vom der Bauart schon vorgegeben.

Da nur die Zugfahrzeuge die eigentlichen Gruppen bilden, und die Anhänger bzw. Wagen nur diesen Gruppen zugeordnet werden, gibt es auch keine Zuwangsreihenfolge wie beim constraint Eintrag. Die Anhänger bzw. Wagen können frei gekuppelt werden, und schließen sich nicht aus. Es geht eigentlich nur darum, den Zugfahrzeugen ein Anhängergruppe zuzuordnen.

Edit:
Ich möcht nicht den constraint Eintrag komplett ersetzen, aber in vielen Bereichen die Zuordnung der Fahrzeuge vereinfachen.
Der normale constraint Eintrag macht bei vielen Fahrzeugkombinationen durchaus Sinn (S-Bahnen, Triebzüge), ist aber besonders im Bereich Straßenverkehr viel zu Aufwendig, kompliziert und fehleranfällig.

[Leartin]

Du hast mal wieder nicht gelesen, was ich geschrieben habe! Ich habe Dein System mit dem von Dir zitierten Satz überhaupt nicht angegriffen, sondern nur einen Vergleich mit dem "ist" gemacht.

Zwischen den Beitrag, von dem ich zitierte, und deinem Beitrag davor war nur einer von mir, deshalb sehe ich es als Antwort an mich.
Du hast einen Vergleich mit dem Ist gemacht, das ist mir klar. Dass ein neues System kürzer wäre, als das Ist, sollte eben auch klar sein. Im Kontext sieht es stark danach aus, als würde behauptet werden, es wäre kürzer als meine Alternative. Daher die Frage, ob du denkst, dein System sei kürzer als meines (so würde deine Aussage für mich am meisten Sinn ergeben), bzw. falls nicht, welchem Zweck die Aussage dienen sollte, welche Intention du hattest. Inwiefern soll das für dich zeigen, dass ich nicht gelesen hätte?

Nicht ganz, weil es in Deinem System nur 1 Referenzfahrzeug gibt, bei meinem aber eine ganze Gruppe. Wie ich schon geschrieben habe (was Du wohl auch nicht gelesen hast), müßte bei meinem System die ganze Gruppe gelöscht werden (nicht nur ein einzelnes Fahrzeug), erst wenn die ganze Gruppe gelöscht werden würde, wären wir auf dem selben Stand.

Nochmal ganz langsam:
Wenn du beim Zugfahrzeug schreibst "Traction_Engine=X" schreibe ich "Constraint[0][next]=X"
Wenn du beim Wagon schreibst "Traction_Engine=X" schreibe ich "Alias=X" (ursprünglich "constraint_group=X" - aber alias ist kürzer und prägnanter)
Es gibt in beiden Fällen kein Objekt X, das gelöscht werden könnte.
Gelöscht werden könnten lediglich die Einträge bei einem spezifischen Fahrzeug.
Entsprechend ist deine Aussage hier leider falsch. Ja du hattest sie schon zuvor geschrieben, und auch da war es eine Fehlannahme.

3.) Die Behauptung, Constraints würden eher geändert werden, ist nicht weitblickend
Wer hat das wann geschrieben?????

Du hast behauptet, bei meinem System würde eher was gelöscht werden. Das wäre nur dann der Fall, wenn man davon ausgehen müsste, dass eher jemand einen Constraints-Eintrag ("Constraint[0][next]=X") ändert, als einen neuen Parameter ("Traction_Engine=X"). Da ich dachte, du hättest verstanden, wie es funktioniert, habe ich es so gedeutet.
Aber du meintest wohl ein Referenzfahrzeug als Objekt? (Was halt für das Funktionieren des Systems egal wäre...)
Egal, die Antwort lautet: Niemand hat das je wirklich geschrieben.

4.)Diejenigen Addons, die bei deinem System gar nicht erst möglich wären
????? Du hast Dir doch noch garnicht die kleinste Mühle gemacht, zu verstehen was ich erreichen möchte. Du versuchst dauernd irgendwelche Nachteile in meinem System zu erfinden!

Nochmals:
Wenn der Paksetautor dein System nicht umsetzt und die entsprechenden Einträge macht, dann hat der Addon-Ersteller nichts von der bloßen Existenz deines Systems. Solange der Paksetautor keine Traction_Engine-Einträge bei seinen Fahrzeugen hat, kann der Addon-Ersteller keinen dazu passenden Wagen erstellen. Dies sind also Addons, die bei deinem System nicht möglich wären.
Mein System bietet hier Schlupflöcher. Es ist möglich, einem bestehenden Fahrzeug mit festen Constraints neue Anhänger unterzujubeln. Die Gefahr daran ist natürlich, dass der Paksetautor jederzeit was ändern kann, unter anderem auch die Objektbezeichnungen von Fahrzeugen. Hier kann genau das passieren, wovon du schreibst: Das Referenzfahrzeug für das Addon wird umbenannt/gelöscht, die Constraints in Zugmaschinen entsprechend ebenso, und das Addon kann nicht mehr angehängt werden. Das Szenario ist realistisch - aber, ich wiederhole: Es kann passieren, dass Addons nicht mehr funktionieren, die mit deinem System gar nicht erst möglich gewesen wären.
Bitte, sage mir, was an dieser Aussage falsch sein soll.

5.)Wenn die Paksetentwickler das System aktiv verwenden, dann steht in den Constraints sowas wie "GROUP_HORSECART", das löscht doch kein vernünftiger Entwickler.
Also sind bei Deinem System doch Vorarbeiten von den Grafiksetentwickler nötig.

Warum ist das so schwer zu verstehen?
Vorarbeiten sind nicht NÖTIG. Du musst nicht hergehen, und allen deinen Fahrzeugen zusätzliche Parameter geben, um es sinnvoll zu nutzen.
Im Gegensatz zu deinem System, bei dem du auf einen Schlag bei allen LKW und allen LKW-Anhängern die Constraints entfernen und die traction_engine angeben MUSST, sobald du einen zusätzlichen LKW-Anhänger mit dem System einführen willst, KANNST du das bei meinem System ebenfalls machen, um einen aussagekräftigen Namen wählen zu können.
Alternativ kannst auch einfach für neue LKW-Anhänger ein Alias verwenden, das dem Objektnamen des ersten LKW-Anhänger in den Constraints entspricht, und erstmal sonst nichts ändern, so dass der riesige Constraints-Block zumindest nicht mehr weiterwächst (Das Hauptproblem ist schließlich nicht, die Constraints in einen neuen LKW zu kopieren, sondern, einen neuen Anhänger in alle bestehenden LKWs einzutragen).
Langfristig ist das freilich nicht sinnvoll, und für aktive Paksets, bei denen noch Zukunftspläne bestehen, wäre es in jedem Fall empfehlenswert, die nötige Vorarbeit zu leisten. Diese Vorarbeit wäre bei beiden Systemen in etwa gleich (Jeweils alle Constraints löschen und eine neue Zeile rein). Pak128German würde sicher die nötige Vorarbeit leisten. Ein Pak128 hingegen, das nicht ganz so aktiv entwickelt wird... würde sich jemand finden, der die ganze Vorarbeit leistet, oder gehen sie komplett leer aus?

Und nicht vergessen: Es kommt auch auf die Einsatzart an. In Pak192.comic können LKW-Anhänger nicht bunt gemischt werden, sondern jeder LKW-Typ hat ein, zwei Anhänger, die grafisch eben dazu passen (quasi gleiches Planendesign). Es wäre völlig witzlos, jedem LKW seine eigene Traction_Engine zuzuweisen, damit nur sein Anhänger dazupasst, aber immer noch Addons möglich sind. Hingegen jedem LKW zu sagen, dass man vorne nichts anhängen kann, hinten aber sich selbst, um dann jedem Anhänger den LKW-Namen als Alias zu geben wäre praktisch so wenig Aufwand, dass man es auch bei kleiner Stückzahl machen kann (dass man sich spätestens bei sowas mit Nummern verhaspelt ist auch klar).

Kann es sein, das Du Dich mit meiner Idee angegriffen fühlst, so wie Du alles nur schlecht machst bzw. falsche Behauptungen aufstellst, ohne wirklich zu lesen, was geschrieben wurde?
Eine sachliche Diskussion läßt Du ja nicht zu.
Für Dich gibt es nur Dein System, alles andere wird nicht zugelassen!

Ich würde mein System gerne im Spiel sehen. Es würde sich zwar technisch nicht widersprechen, beides zu integrieren, aber wenn erstmal ein System steht wird es kein Interesse mehr am anderen geben. Daher halte ich es für sinnvoll, im Vorfeld Vor- und Nachteile zu erläutern.
Es geht also nicht darum, etwas schlecht zu machen, sondern darum, die Nachteile zu nennen. Dein System hat viele Vorteile, insbesondere gegenüber dem IST-Zustand und für Pak128.German. Aber da mein System flexibler ist und kann, was deines kann, aber auch andere Dinge, kann ich halt kaum einen Vorteil deines Systems nennen.
Eine falsche Behauptung habe ich dabei nicht gemacht, und ich halte es für eine Frechheit deinerseits, das zu behaupten. Im Wesentlichen machst du gerade, was du mir vorwirfst: Du liest nicht wirklich, was ich schreibe, bzw. entgeht dir der Inhalt. Da du es nicht verstehst, stellst du falsche Behauptungen auf. Ist es wirklich sachlich, so zu agieren?

Anderer Vorschlag

Wie wäre es eine eigene Definitionsdatei dafür zu verwenden. Diese wäre als Textdatei dann frei zugänglich. Vor allem stünde nur das benötigte drin ( die Objektnamen ). Auch Addon-Fahrzeuge könnte man so einfach eingliedern ohne für jedes Set eine eigene Pak-Datei zu bauen.

NEXT würde dann so definiert

FahrzeugA = Fahrzeug 1, Fahrzeug3, Fahrzeug L

Meine erste Interpretation war,dass du im Zugfahrzeug angeben willst, dass "FahrzeugA" angehängt werden darf, und dann in dieser externen Textdatei editieren, für welche Fahrzeuge "FahrzeugA" steht. Es würden also mehrere Zugfahrzeuge auf "FahrzeugA" verweisen, und immer, denn ein Anhänger erstellt wird, schreibt man dessen Namen mit auf die Liste. Falls das korrekt wäre: Stell dir vor, du könntest in der Dat eines Anhängers irgendwie "FahrzeugA" angeben, und dieser Anhänger würde automatisch in der Liste zu FahrzeugA eingetragen. Man würde sich also ein manuelles editieren, insbesondere für Addons, sparen. Wäre praktisch, oder?
Solltest du dem soweit zustimmen: Das wäre 1:1 das System, das ich vorschlage, mit der Textdatei als nützliche Nebenausgabe - nicht zum manuellen editieren, aber als Hilfestellung für Addon-Ersteller.

Falls du hingegen meintest, dass gar keine Constraints in der Dat angegeben werden, und alles über ein externes Dokument läuft, in dem alle Fahrzeuge eingegeben werden müssen - hätte ich im Prinzip nichts dagegen, aber es würde halt auch nichts gegen den Constraint-Wulst unternehmen. Man hätte ja trotzdem unzählige unübersichtliche Einträge, und auch wenns nur in einer Datei ist wäre es umständlich, ein neues Fahrzeug bei zig Zeilen einzutragen. Hinzu kommt, dass ein Durchschnittsnutzer, der Addons hinzufügt, diese Datei eher nicht anfassen sollte, weil viel zu schnell was kaputt gehen könnte.

[The Transporter]

Ideen totreden/schlagen ist auch ein Weg Simutrans weiter zu bringen, aber nicht unbedingt vorwärts.

Zwischen den Beitrag, von dem ich zitierte, und deinem Beitrag davor war nur einer von mir, deshalb sehe ich es als Antwort an mich.

Falsch, es stand in der Zeile direkt davor, klarer Beweis, das Du es nicht wirklich gelesen hast
Hier das Original

Um einem Lkw eine Anhängergruppe zuzuordnen, muß bei jetzigen Stand, jeder Anhänger einzeln mit constraint genehmigt werden. Anhänger die im constraint Block nicht aufgeführt sind, sind auch nicht erlaubt angehängt zu werden. Bei 40 Anhänger im Set wäre dann der constraint Block in der dat dementsprechend 40 Zeilen lang. Was viel Aufwand ist, und auch sehr fehleranfällig ist.
Bei meinem Ansatz wäre das jeweils nur ein kurzer Einzeiler (z.B. traction_engine=3), der auch noch bei Zugmaschine und den Anhänger gleich ist. Also ganz einfach und übersichtlich ist.

Wenn du beim Zugfahrzeug schreibst "Traction_Engine=X" schreibe ich "Constraint[0][next]=X"

Auch falsch. Hast Du meine Idee wirklich gelesen? Ich glaube nicht.
Meine Idee, ordnet einerZugfahrzeugruppe eine Gruppe von Anhängern zu, nicht mehr und nicht weniger.
Bei Deiner Lösung wird einem Fahrzeug die anhängeeigenschaft eines Referenzfahrzeuges zugeordnet.

Du hast behauptet, bei meinem System würde eher was gelöscht werden.

Wo soll ich das geschrieben haben?
Bleib doch mal bei den Tatsachen!

Dies sind also Addons, die bei deinem System nicht möglich wären.

Die Addons wären schon möglich können nur das nicht vorhandene System nicht nutzen, ist  also keine Veränderung zum aktuellen "Ist" Stand.
Keine Verbesserung, aber auch keine Verschlechterung.

Dein System hat viele Vorteile, insbesondere gegenüber dem IST-Zustand und für Pak128.German. Aber da mein System flexibler ist und kann, was deines kann, aber auch andere Dinge, kann ich halt kaum einen Vorteil deines Systems nennen.

Du hast Dir gerde in einem Satz selber widersprochen. Erst bestätigst Du, das mein System viele Vorteile hat, dann es gibt keine zu nennen.

Du liest nicht wirklich, was ich schreibe, bzw. entgeht dir der Inhalt. Da du es nicht verstehst, stellst du falsche Behauptungen auf. Ist es wirklich sachlich, so zu agieren?

Wenn ich Deine Texte nicht lesen, und verstehen würde, könnte ich dann so auf Deine Details antworten.
Du stellst ja die Frage der sachlichkeit, Du bist es doch, der ein Kontext zwischen uns unterbindet, indem Du auch jegliches meinerseits nur als schlecht und unmöglich dastellst.

Aber weißt Du was?
Als nurnoch Spieler brauche ich weder Deine, noch meine Idee.
Beide Idee sind nur Ersteller von Fahrzeugen interessant.

Und da ich keine Bock mehr habe mit Dir weitere Sinnlose Diskussionen darüber zu führen. Ziehe ich hiermit das Ganze zurück, und möchte nicht, das es umgesetzt wird.


Herzlichen Glückwunsch!!!
Du hast es wiedermal geschafft.


Es lohnt sich halt nicht Ideen zu Simutrans zu äußern.!!