Ich spiele OTTD seit Version 0.3.x mehr oder weniger regelmäßig.
Mittlerweile sind wir ja schon bei Version 1.4.x angekommen.

Gibt es bekannte Meilensteine für die zukünftige Entwicklung?
Früher gab es mal eine Roadmap die mehr oder weniger regelmäßig aktualisiert wurde.
Finde so was heute leider nicht mehr und habe auch sonst keinen Überblick über die Ziele.

Vielleicht kann man das ja hier drinn mal stichwortartig sammeln?

Die so genannte "Roadmap" wurde abgeschafft, weil es eher eine "Wunschliste" war, als eine echte Beschreibung der Entwicklungstätigkeit. In einem Hobbyprojekt wie OpenTTD kann man die Entwicklung nicht auf die gleiche Weise steuern wie in einem kommerziellen Projekt, denn man kann niemanden zwingen, an etwas zu arbeiten.

Na ja, sowas das auch gar nicht gemeint...
Aber es gibt doch bestimmt so ein paar Eckpunkte die man sich als Ziel gesetzt hat...
Mir fällt da z. B. 32 Bit Grafiken...

Aber genau sowas meine ich. 32bpp war niemals "Ziel". 32bpp passierte nur, weil sich mal einer hingesetzt hat, und das brauchbar implementiert hat. Solche "Ziele" bleiben einfach nur "Wünsche", solange sich keiner hinsetzt, und die tatsächliche Arbeit tut. Und weil man das nicht steuern kann, gibt es eben keine "Ziele", sondern nur "Wünsche" (und ggf. "Nicht-Ziele")

Naja, soooo einfach ist das nicht. Es gibt eine grosse Anzahl von sinnvollen (genügend kleinen) Spielerweiterungen, wo "sich mal einer hingesetzt hat", die aber dennoch nie in den trunk aufgenommen worden sind.

Gruß
Michael

Das nennt sich "notwendiges, aber nicht hinreichendes, Kriterium".

Folgende Dinge würde ich gerne sehen:
z.B Tunnelbahnhöfe(Also in Tunnel integriert. Spart eine menge platz in Städten)
Trajektverbindungen(Also Eisenbahnfähren)
Traktionswechsel(Also E-Loks fahren mit jenem Zug auf Elektrifizierten Strecken, und dann fährt die Diesellok im Wechselbahnhof mit dem Zug weiter auf nicht Elektrifizierten Strecken) Dies könnte man via "Umrüsten" machen.
Dementsprechend auch Flügelzüge bzw Kurswagen(Was aber weniger machbar ist denke ich)
Tunnel unter dem Meeresspiegel sind anscheinend immer noch zukunftsmusik.
Mitunter würde ich eine manuelle Städte gestaltung in Szenarien echt gut heißen(Momentan ist es ja so, dass eine zufallsgenerierte Stadt erstellt wird.) Die genaue Bestimmung der Anfangseinwohnerzahl.

Noch wichtiger als Tunnelbahnhöfe wären mir allerdings Tunnel- und Brückensignale.

(08.08.2014 14:50)Eddi schrieb:  Aber genau sowas meine ich. 32bpp war niemals "Ziel". 32bpp passierte nur, weil sich mal einer hingesetzt hat, und das brauchbar implementiert hat. Solche "Ziele" bleiben einfach nur "Wünsche", solange sich keiner hinsetzt, und die tatsächliche Arbeit tut. Und weil man das nicht steuern kann, gibt es eben keine "Ziele", sondern nur "Wünsche" (und ggf. "Nicht-Ziele")

Aktuelles Beispiel: Ich hab das Patch für Fahrpläne mit absoluten Zeitangaben geschrieben, irgendwann den unbedingt nötigen Teil extrahiert damit es kleiner wird.

Grade aktuell hab ich gemerkt dass sich irgendwer hingesetzt hat und den bestehenden Code im trunk (auf ich glaube durchaus sinnvolle und nachvollziehbare Weise) refactored hat.

Für mich bedeutet das jetzt natürlich wieder dass ich mich auch hinsetzen muss und meine patch queue an die entsprechenden Änderungen anpassen muss (da es grob gesagt meinem jetzigen Verständnis nach um die Umwandlung von Direktzugriffen auf Variablen in Funktionsaufrufe, nebst einer weiteren explizit NOSAVE gecachten Variable geht ist das auch wirklich ein Querschläger der ein Überarbeiten des kompletten Patches erzwingt) --- die Alternative wäre, in den Status "ich bin mit OpenTTD in der derzeitigen Version zufrieden und ignoriere zukünftige Änderungen, sondern spiele nur noch auf der aktuell gepatchten Version" überzugehen.

Was ich sagen will: Sowas macht Arbeit, und da fände ich es schon sinnvoll wenn man sich mal auf eine Roadmap in dem Sinn einigen könnte dass man als Patch-Entwickler der eine selbsterkannte Schwachstelle im Spiel verbessern möchte weiß auf welches Ziel man hinarbeiten kann / soll. (also, deutlicher gesagt, Roadmap auch gerne (nur) in dem Sinn dass die enthaltenen Punkte schon mit jemandem besprochen sind der auch daran aktiv daran arbeitet, weil dass es so jemanden braucht ist mir auch klar, eine Wunschliste ist ganz klar eine andere Kategorie).

In dem Fall ist die Schwachstelle dass ich es unwartbar fand, einen Fahrplan rein auf Reisezeiten basieren zu lassen, was meiner Erfahrung nach bei Änderungen regelmäßig zu Problemen führt, und außerdem bei größeren, aufeinander abgestimmten Linienführungen schon fast Buchführung außerhalb des Programms erzwang (z.B. wenn ich einen Taktknoten gestalte der auf bestimmte Weise von verschiedenen Linien angefahren wird). Schlussfolgerung meinerseits damals als ich das Patch angefangen habe: Ich brauch Fahrpläne in Form von Zugläufen sowie Bahnhofsfahrpläne wie in echt, wo absolute Zeiten drinstehen.

Ich denke, auf Basis so einer Analyse (hier nur ganz grob skizziert) kann man diskutieren, und im Idealfall weiß dann der Patch-Entwickler irgendwann ob 1. seine Arbeit einen Sinn hat, und 2. wie er ggf. weiterimplementieren kann. Und 2. kann man denke ich durchaus als Roadmap gezogen auf ein Patch sehen. Wenn 2. und der Patch-Entwickler die nötige Zeit reinstecken kann ist man im Idealfall in endlicher Zeit soweit dass man die Sache als fertig betrachten kann.

(oder anders gesagt: Ich finde man sollte unterscheiden zwischen aktuell erkannten Schwachstellen des Patches (hier passt die Benutzerführung noch nicht, da gibts eine Konstellation wo es abstürzt, so banale Dinge), und den Zielen wo man hinwill - letztere kann man auch diskutieren, solange bei ersteren noch Handlungsbedarf ist)

Aus eigener Erfahrung kann ich nämlich sagen: Rein aus dem fortwährenden Anpassen eines Patches an Änderungen im Trunk ergibt sich ein nicht zu vernachlässigender Arbeitsaufwand, alle paar Monate ein oder mehrere Abende bis alles wieder so läuft wie vorher ist da einfach realistisch.

Gegeben das nervt es einfach manchmal das Gefühl zu haben, ich arbeite da dran, und da gibts irgendein Orakel dessen geheimen Wünsche ich nicht genau kenne aber vielleicht irgendwann mal treffe. (jetzt etwas überzeichnet gesagt)

Letztendlich läuft alles darauf hinaus, dass OpenTTD auf sehr verschiedene Arten gespielt wird.
Es gibt einfach diverse Features, die nicht zusammen funktionieren, und es auch nie tun werden.

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

Nehmen wir mal diese Liste an Funktionen: (ich verwende die englischen Namen der Features, da ich die deutschen nicht kenne; dafür aber teilweise mit Bildern)
* Cargo Distribution (trunk)
* Timetables (trunk)
* Conditional orders (trunk)
* Self-regulating network (kein Patch, aber ein Spielstiel)

und die zugehörigen fortgeschrittenen Versionen:
* Cargo Destinations (celestar, michi_cc)
* 24-hour timetables (ic111)
* Timetable auto-separation (pavel1269)
* More conditional orders (Hirundo et al.)
* Programmable/restrictive signals (Ideensammlung)

Diese 4 Funktionen stehen in folgendem Konflikt:
Wer entscheidet,
* wo ein Zug langfährt,
* wo er hält,
* was und wieviel er lädt.

Cargo Distribution und Timetables setzen voraus, das Züge immer die gleichen Strecken in der gleichen Taktung fahren.
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 ).

Nun ist es aber natürlich nicht so, dass jeder Spieler sich für eine der Seiten entscheidet. Es gibt vieles dazwischen, und die trunk Features versuchen irgendwie einen "kleinsten gemeinsamen Nenner" dazwischen zu finden.
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.

Die Fahrstrecken sind nicht er einzige Bereich, in denen es konflikt-trächtige Features gibt. Ein weiterer Bereich ist zum Beispiel die Güter-Produktion und Belieferung.
* Cargo Destinations verteilt Waren automatisch zwischen Zielen, wenn man die Ziele nicht anfährt bekommt man die Waren nicht zum Transportieren.
* GameScripts und diverse Goal-Server erfordern das Beliefern von bestimmten Zielen mit möglichst viel oder regelmäßiger Fracht.
* Industry NewGRF wie ECS oder PBI haben Bedarf an bestimmten Waren in bestimmten Verhältnissen und Maximal-Mengen.

Natürlich funktionieren diese drei Dinge zusammen überhaupt nicht.

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.

So ist z.B. Cargo Distribution für den Trunk ein nützliches Feature, da es die Warenverteilung übernimmt. Gleichzeitig ist es aber offen genug, nicht hart festzulegen, wohin die Waren wirklich fließen. Dadurch ist es flexibler als Cargo Destinations, und kann eher mit GameScripts und NewGRF in Einklang gebracht werden.

Andere Features sind hingegen sehr speziell. Funktionen wie 24-hour timetables oder Head2Head sind zwar faszinierend, betonieren aber mehr oder weniger einen Spielstiel fest. Entsprechend polarisierend sind die Meinungen: Manche können nicht ohne spielen, andere verstehen nicht, wie man mit soetwas spielen kann.
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?
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.

Tja, was bleibt als Lösung? Trunk kann nur universelle Funktionen aufnehmen, die für mehrere Dinge nützlich sind.
Andere Funktionen müssen Add-Ons verbleiben: Als NewGRF, GameScript oder Patch.
Für Cargo Destinations wird es sicherlich irgendwann GameScript Funktionen geben. Andere Patches (wie z.B. Infrastructure Sharing, oder der längst vergessene Vorgänger "Subsidiaries") werden vermutlich für immer Patches bleiben.

Zitat:Andere Patches (wie z.B. Infrastructure Sharing, oder der längst vergessene Vorgänger "Subsidiaries") werden vermutlich für immer Patches bleiben.

Seufz... damit beschäftige ich mich gerade.

Da kommt ja z.B. noch das Problem Kosten/Einnahmen-Verteilung dazu...


OT: Was ist eigentlich die neueste Implementation von Infrastructure Sharing bzw. wo ist sie enthalten?
Die aus dem HardGamePatchPack?

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.

... so, und damit ich hier nicht nur abstrakt über was rede hab ich jetzt noch die besagten Anpassungen an den trunk gemacht, will sagen von dem Patch gibts jetzt auch wieder ein Release was mit Trunk funktionieren sollte:

http://www.tt-forums.net/viewtopic.php?f...1#p1128411

Features kurz zusammengefasst:
- Den Fahrplan-Dialog auf das erwähnte Konzept absoluter Zeiten umgestellt
- Einen kleinen Extradialog, damit man die Zeiten schnell erfassen kann (Zeit mit Buttons +/- 1/5/10 auswählen, dann zur nächsten einzupflegenden Zeit gehen)
- Mögliche Einheiten derzeit Tage / Monate / Jahre. Ich verwende normalerweise Monate, speziell für Eddi der untere Screenshot wo ich grade auf Tage umstelle
- Im Screenshot zwei Posts weiter unten eine tabellarische Ansicht des ganzen, um einen Fahrplan wirklich in übersichtlich zu kriegen.
- Über dem Zug wird eine eventuelle Verspätung / Verfrühung angezeigt (die grüne "-3" im Screenshot signalisiert dass er drei Tage zu früh angekommen ist). Könnte man aber natürlich zum optionalen GUI-Feature erklären. Mit den Ladeindikatoren harmoniert es.
- Und, natürlich, wenn der Spieler das alles ignoriert fahren die Fahrzeuge wie üblich einfach ohne Fahrplan.
- Den traditionallen Dialog gibts weiterhin, den erreicht man indem man oben rechts auf "Orders" klickt. Wiederum: Welcher standardmäßig aufgeht wäre im Zweifelsfall was für die GUI-Optionen.

Einige Known Bugs & Tasks gibts noch (siehe englisches Forum), aber die Grundfunktionalität sollte funktionieren. Und wie gesagt: Das Ziel ist eigentlich wirklich, das ganze so zu implementieren dass es wie die Fahrpläne bisher optional bleibt.

@ic111, gibt es auch eine fertig kompilierte Version OTTD mit deinem Patch?
Ich kann das nämlich nicht selber würde deinen Patch aber sehr gerne ausprobieren!

Das ist bei mir ähnlich. (Eigentlich sogar gleich)

Hm, gute Frage. Ein vorcompiliertes Release ist nämlich etwas was ich noch nie gemacht hab. Was ist denn da die beste Strategie? Über was für ein Betriebssystem reden wir? Gibts irgendwelche Optionen für make / configure mit denen ich ggf. cross-compilieren könnte? (mein eigenes Betriebssystem ist ein Debian Linux).

Je nachdem wie die Antwort auf die Fragen ist werd ich mal schauen was ich tun kann. Evtl. aber erst nachdem ich noch ein paar Sachen behoben habe.

Und falls mir das jemand ohne großen Aufwand abnehmen kann bin ich auch nicht unglücklich

ca. 85% der Nutzer spielen auf irgendeiner Windoze-Version. Unter Debian könntest Du mit Hilfe des MinGW-Cross-Compilers etwas reissen, um dafür eine Version zu bauen. Der findet sich bei Debian in den Standard-Paket-Repositories. Für Linux lohnt sich wegen der Anzahl verschiedener Distributionen höchstens die statically linked Binary. OSX ist mit Cross-Compiler extrem schwer hinzubiegen und gibt es nicht vorkonfektioniert, sprich muss selber erstellt werden.

Um es hier auch noch festzuhalten: Das mit dem cross-compilieren entpuppt sich als harte Nuss für mich, ich hab da jetzt einige Stunden investiert und bin grademal übers configure drübergekommen.

Von mir ist demzufolge vermutlich nicht so bald mit einem Binary zu rechnen, falls überhaupt...

Tja, ich braüchte es für Windows. ....
Vielleicht findet sich hier ja jemand der mir hilft

Hallo Bernhard,

bin dabei eine Version für Windows zu erstellen.

Verwende die aktuelle trunk version 26728 und die Patchversion v4 von TIP.