Zunächst mal frosch, danke für die umfrangreiche Antwort. Sowas in dem Stil hab ich mir gewünscht, weil so kann man wirklich mal zum Punkt kommen, was man tun kann damit diese verschiedenen Spielstile harmonieren können.

Erstmal Frage / Anmerkung zu meinem eigenen Patch, nachdem ich mir nicht sicher bin ob die Vorstellung die du davon hast vollständig mit der Realität übereinstimmt:

Zitat:24-hour timetables

1. wie kommst du auf den Namen? Mit 24h hat das Patch soweit eigentlich garnix zu tun, ich lote nur gerade aus ob ich das ändern sollte. Die Kernidee ist eigentlich Fahrpläne mit absoluten Zeitangaben statt relativ, nicht mehr; und dazu dann natürlich entsprechend GUI.
(ich verwende den Namen unten trotzdem damit du nicht total verwirrt bist von was ich rede )
2. Der Screenshot zeigt die große Version, von der ich schon längst den Kern abgespalten habe. Siehe
http://www.tt-forums.net/viewtopic.php?f...0#p1118565

Kurz gesagt sind die Routes und die Extradialoge für Stationen etc. eh schon draußen. Was bleibt ist die Fahrplangestaltung selber, und da sehe ich (unten mehr) ehrlichgesagt nicht dass ich so stark in den grundsätzlichen Spielablauf eingreife.

(anwendbar auf den trunk ist das aber derzeit leider nicht, weil da jemand refactored hat - das ist meine nächste Aufgabe für dieses patch...)

(10.08.2014 13:09)frosch schrieb:  Es gibt einfach diverse Features, die nicht zusammen funktionieren, und es auch nie tun werden.

Das betrifft aber nur Features, die so implementiert werden dass sie nicht abschaltbar sind. Für Fahrpläne trifft das beispielsweise nicht zu: Die sind im jetzigen trunk-Stand in dem Sinn abschaltbar dass einfach kein Fahrplan beachtet wird wenn keiner definiert wird, und an dem Punkt hab ich auch in meinem Patch nichts geändert.

Zitat:Für viele Spielarten gibt es viele brennende Anhänger und Verfechter. Gemeinsam ist ihnen nur der mangelnde Respekt gegenüber anderen Spielarten.

Natürlich spielen unterschiedliche Leute unterschiedlich. Bei der Frage mit dem Respekt möchte ich als Patch-Entwickler aber schon widersprechen: Ein anderer Spielstil reduziert sich im Grunde auf die Frage "kann ich X noch machen, wenn dieser Patch im trunk wäre?". Die Antwort kann sein:

- das betrifft dich garnicht
- das geht jetzt so und so
- danke für den Hinweis, damit das funktioniert muss mein Patch dieses oder jenes anders machen
- (die vierte Möglichkeit die man ohne gute Gründe tunlichst vermeiden sollte ist natürlich, das geht dann nicht mehr)

Auf so was eingehen kann man aber klarerweise nur wenn sich die Leute zu Wort melden. Das ist ein Teil dessen was ich meinte mit, eine Art Roadmap bezogen auf ein Patch (was brauchen wir, damit es sich gut in das große Ganze einfügt) will auch erstmal erarbeitet werden.

Den Rest beantworte ich jetzt mal ausgehend von timetables, weil sonst wird das ausufernd.

Zitat:Cargo Distribution und Timetables setzen voraus, das Züge immer die gleichen Strecken in der gleichen Taktung fahren.

Korrekt.

Zitat:Conditional Orders, programmierbare Signale u.s.w. machen genau das Gegenteil: Der Spieler entwirft komplexe Mechaniken, wo der Zug lang fährt, wann er wo hält, oder ggf. volle Stationen überspringt (der Realismus geprägte Spieler wird hier feststellen, das Passagiere beim betreten einen Zuges nie wissen, sohin er fährt; andere mögen natürlich gerade dies als realistisch werten ).

Da haben wir aber doch höchstens das Problem dass sich die zwei Features nicht gut vertragen wenn man sie in einem Spiel zusammen einsetzt, oder? Wenn ich keinen Fahrplan definiere, dafür aber Coniditional orders oder programmierbare Signale verwende, wird das Spiel nie versuchen an einer Station länger als nötig zu warten. Umgekehrt, wenn ich einen Fahrplan habe, aber Conditional orders und programmierbare Signale komplett ignoriere fährt mein Zug halt nach Fahrplan, fertig.

Wenn ich eine Conditional Order einbaue, und für die nachfolgenden Stationen ein Fahrplan definiert ist, dann wirds schwieriger, aber wenn die Kette dann wieder zusammengeht geht vielleicht sogar das (beispielsweise gehe entweder zu A, Ankunft 5.8., Abfahrt 7.8., oder zu B, Ankunft 12.8., Abfahrt 14.8., dann immer zu C, Ankunft 22.8.).

Also, mir kommt vor wir haben hier das Problem dass gewisse Features beim Spielen nicht gut harmonieren, aber auf Codeebene seh ich jetzt eigentlich noch kein Problem, man muss sich halt als Spieler irgendwann entscheiden ob man lieber das eine oder das andere verwendet.

Oder übersehe ich hier was?

Zitat:Jeder kann ja mal schätzen, wie viele Monate fonsinchen daran gearbeitet hat, dass Cargo Distribution mit Conditional Orders einigermaßen funktioniert. Und wieviele Bug Reports es dazu gab.

Ich kann es mir lebhaft vorstellen.

Zitat:Zusammengefasst:
Wenn die offiziellen Trunk Versionen alle Spielvarianten bedienen möchten, so kann man nur grundlegende Funktionen aufnehmen, die den Spielstiel nicht zu sehr festnageln.

Da stimme ich dir zu; man hat aber schon einen weiten Spielraum Features so zu gestalten, dass das mit dem Festnageln eben nicht passiert.

Zitat:Andere Features sind hingegen sehr speziell. Funktionen wie 24-hour timetables oder Head2Head sind zwar faszinierend, betonieren aber mehr oder weniger einen Spielstiel fest.

Bezüglich 24h timetables: Wo betoniere ich im Vergleich zu den Timetables die jetzt im trunk sind etwas fest?

Zitat:Dies gilt nicht nur für die Spieler, sondern auch für die Entwickler. Wer möchte seinen Patch mit einem anderen Patch kompatibel machen, für den sie/er kein Interesse hat?

... und wer möchte ein Patch über Jahre hinweg immer wieder an einen sich weiter entwickelnden trunk anpassen?

Will sagen, wenn ich dadurch aus dem Zustand rauskomme stecke ich natürlich die entsprechende Arbeit rein. Nur da sind wir halt wieder beim Thema Roadmap für ein Patch: Wo sehen Leute die Probleme, was muss man ändern damit es harmoniert?

Zitat:Das schlimmste ist dann, wenn ein solches Nieschen-Feature in den Trunk kommt. Dann gibt es hunderte Inkompatibilitäten, und keiner möchte sie beheben, da keiner an beiden Features interessiert ist. Es aber trotzdem genügend Grauzonen-Spieler gibt, die versuchen mit beidem zu spielen (bewusst oder unbewusst), und diese Inkompatibilitäten finden.

Naja, also ein bißchen kann man aber schon abschätzen, welche Aspekte betroffen sind und welche nicht.

Zitat:Tja, was bleibt als Lösung? Trunk kann nur universelle Funktionen aufnehmen, die für mehrere Dinge nützlich sind.

... oder die andere Features nicht stören, und dafür kann man als Patch-Entwickler durchaus aktiv was tun, wenn einem die entsprechenden Probleme auch mitgeteilt werden.