Eine weitere Version: http://www.tt-forums.net/viewtopic.php?f...4#p1130214

Autofill ist jetzt fertig, und außerdem gibts Unterstützung dafür mehrere Ankünfte / Abfahrten auf einmal um einen bestimmten Betrag zu verschieben. Beispielsweise in folgendem Fall:

- Zug verlässt A am 10.3., erreicht B nach 5 Zwischenhalten am 8.5., hat dort eine große Wendezeit
- Ich will noch einen anderen Zug vorlassen, d.h. A soll A am 18.3. verlassen, und am 16.5. ankommen
- Mit dem unten beschriebenen Feature klicke ich die Order in A und die in B an und wähle als Offset 8 Tage aus.

Grundsätzlicher Ablauf:

- Die oberste Zeile markieren (die mit Start, Länge, Offset)
- << oder >> -Button anklicken
- Entweder nochmal << bzw. >> klicken, dann bezieht es sich auf den ganzen Fahrplan
- Ansonsten die erste zu ändernde Order anklicken
- Die letzte zu ändernde Order anklicken

Es öffnet sich das bekannte Fenster, in dem eine Zeitdauer ausgewählt werden kann, z.B. 3 Tage oder 1 Monat. Wenn man das bestätigt, werden alle Ankünfte bzw. Abfahrten gemäß der Selektion oben um den angegebenen Betrag verschoben.

Standardmäßig wird bei der ersten Order die Abfahrt, bei der zweiten die Ankunft angenommen, das Verhalten kann man aber mit Strg umdrehen. Abgesehen davon wird der Ablauf oben durch jeden anderen Klick im Fahrplan-Fenster abgebrochen, d.h. das Risiko das man drin gefangen bleibt besteht nicht.

Klingt zugegeben ein wenig kompliziert, ich hab aber Hilfetexte eingefügt, und denke im übrigen dass das der beste Weg ist um das zu erreichen was ich wollte, nämlich festgelegte Bereiche eines Fahrplans auf einmal verschieben können.

In anderen GUIs würde ich da mit MultiSelection arbeiten, das geht aber in OpenTTD aus verschiedenen Gründen nicht.

Technisch ist das im übrigen das letzte Patch der Queue, d.h. es sollte bitte nicht der Maßstab für eine Berurteilung der Bauaurt "ist das Patch aber kompliziert / groß" sein.

Wahrscheinlich werd ich (entweder jetzt oder irgendwann in der Zukunft) noch die Ankunfts- und Abfahrtsfahrpläne in das Patch re-integrieren. 1. weil ich sie schon implementiert habe, 2. weil sie irgendwo eine natürliche Erweiterung sind, 3. weil man sie genau wie das oben genannte Feature auch wieder rausnehmen können wird ohne das restliche Patch zu beeinträchtigen.

Abgesehen von dieser Baustelle bin ich bei dem Patch dann aber im Status "Bugfixing & Patch-Queue-Aufräumen", d.h. falls jemand meint es fehle noch ein Feature bitte mit einer guten Begründung melden

So, die Bahnhofsfahrpläne funktionieren jetzt auch wieder. http://www.tt-forums.net/viewtopic.php?f...1#p1130271

Ein Screenshot findet sich hier: http://www.tt-forums.net/download/file.php?id=180546

Ein Problem was man auch im Screenshot gut sieht ist folgendes:

Was nimmt man als Zielort einer Fahrt im Bahnhofsfahrplan? Meine (derzeit nur für Abfahrtsfahrpläne implementierte) Heuristik ist folgende:

1. Ignoriere Wegpunkte, Non-Stop-Orders und Depot-Orders
2. Nimm die erste Station, bevor eine Station zum zweiten Mal angefahren würde

Das funktioniert meistens, ein Beispiel wo es nicht das macht was man will sieht man aber auch im Screenshot: Wenn ich den Zug nach dem Zielbahnhof erstmal im Abstellbahnhof verräume (z.B. weil ich ihn kraft Fahrplänen erst 3 Monate später wieder auf dem Weg zurück brauchen kann) dann taucht natürlich der auf. Und bei Ringfahrten kann es auch komische Resultate geben.

Wobei mir grade einfällt, ich könnte auch noch "Weder laden noch entladen"-Bahnhöfe ignorieren, dann wär ich auch die Abstellbahnhöfe los...

Alternativ könnte ich mir ein Flag an der Order "Das Ziel ist wichtig" vorstellen. Leidet aber daran dass ich kein freies Flag sehe, und extra dafür eine neue Variable einführen wäre wohl auch Overkill. (GUI-Seitig wär das sogar machbar, den zwei-Klick auf die Fahrplan-Zeile (also das wie man bei der Ziel-Zeile das Halten vorne, mittig, hinten steuert) hab ich nämlich noch nicht mit Funktion versorgt...).

Sonstige Ideen?

In der fettgedruckten Kopfzeile kann ich vielleicht noch wenn definiert statt der Zugnummer den Namen des Fahrplans anzeigen, damit wären dann auch richtige Linienbezeichnungen im Fahrplan machbar (z.B. S5 nach Foo, RE 7 nach Bar, etc.).
(ja, Fahrpläne können Namen haben, hab ich ursprünglich mal mit ganz anderen Hintergedanken eingebaut, könnte aber hier nützlich werden).

sieht super aus !!!!

Danke

Noch ein paar Stunden Bugfixing später gibts wieder ein neues Release: http://www.tt-forums.net/viewtopic.php?f...0#p1130340

Damit betrachte ich das Patch jetzt als Feature-complete, die meiste Arbeit die jetzt noch reingesteckt werden will sollten die Spieler garnicht mitbekommen (Dokumentieren, Code in einigen Fällen richtig auf die Patches verteilen, etc.).

aktuelle Version für Windows ist auch erstellt.

Windows-Binary mit v13 Stand 31.08.2014: download Timetabe Improvement Patch - Windows binary

Danke!

Nach dem TrainFever Release habe ich dann wieder Zeit für TTD .... ich freue mich auf diesen Patch!

Klingt nach einem interessanten Patch. Schön, dass sich der Sache jemand angenommen hat. Inzwischen ist die Fahrplantechnologie ja schon weit ausgereift mit einigen netten Features. Ich werde den Patch mal testen, obwohl ich ihn wahrscheinlich in keinem großen Netzwerk testen werde. Um ein großes Netzwerk aufzubauen benötige ich zwingend die 24-Stunden Anzeige.

Danke fürs Testen

Ein Kommentar zu der 24h-Sache: Ich persönlich spiele immer so, dass das was in der Realität beispielsweise ein Taktknoten zur vollen Stunde ist, im Spiel ein Taktknoten z.B. zum Geraden Monatsanfang ist.

Das passt dann meiner Erfahrung nach ganz gut für eine angemessene Zugdichte auf der Strecke.

Typische Intervalle sind dann 2 oder 4 Monate, d.h. es gibt meinetwegen Züge mit Offset 0, 4, 8 Monate für einen Fahrplan der Länge 12 Monate.

Wenn so ein Zug dann beispielsweise immer am 27.5. an einem Bahnhof ankommt, kann man da gut einen Anschluss mit Fahrplanlänge 2 Monate dazubasteln, der immer am 4.6. abfährt und am 26.7. wieder zurückkommt (und dann am 4.8. wieder abfährt).

Auf die Weise sind für mich Tage ungefähr sowas wie in der Realität Minuten.

Ein anderer Aspekt ist, dass ich Fahrpläne so gut symmetrisch um einen bestimmten Monatsanfang machen kann, z.B. könnte der oben erwähnte Zubringerzug einen Fahrplan haben wie

4.6. Abfahrt am Knotenbahnhof A
16.6. Abfahrt in B
25.6. bis 5.7. Aufenthalt am Endbahnhof C
14.7. Abfahrt in B
26.7. Ankunft in A

[einen Depotbesuch müsste man beim Spielen mit Pannen noch reinbauen, der macht die Sache meist leicht assymmetrisch an irgendeiner Stelle]

Mit der Vorgangsweise komm ich eigentlich auch bei größeren Netzwerken ganz gut zurecht, auch wenn ein 24h-Support realitätsgetreuer ist, da stimm ich gerne zu, ändert aber nix dran dass es den im Trunk derzeit nicht gibt.

Bug den ich gerade behoben habe für die nächste Version: Man kann derzeit nicht bei einem neu gebauten Fahrzeug als erstes das Startdatum des Fahrplans setzen.

Zuerst das Offset setzen, und dann das Startdatum geht aber.

Gibt es zu diesem Patch eigentlich ein (mehr oder weniger) ausführliches dt. Tutorial? Oder bin ich nur zu doof. es zu finden?

Hm, das meiste was ich dazu bisher getippt habe ist Englisch, der Rest in diesem Thread zu finden.

Ich versuch mal was zu schreiben:
Ich hab die bereits vorhandene Fahrplan-GUI komplett rundüberarbeitet. Sie kann jetzt sowohl bei Fahrplänen als auch den restlichen Einstellungen alles, d.h. die traditionalle GUI ist was ihre Features angeht eigentlich nicht mehr nötig.

Wenn Du die mal offen hast:
Oben sind Eigenschaften zum Fahrplan generell, unten die einzelnen Anweisungen. Jede Zeile ist markierbar, die Buttons ändern sich entsprechend.

Zuerst füllt man zweckmäßigerweise die oberste Zeile aus: Jeder Fahrplan hat ein Startdatum und eine Länge. Die Idee ist dass die einzelnen Ankünfte und Abfahrten dazwischen sind (es passiert aber nix schlimmes wenn das mal nicht der Fall ist, außer dass die entsprechenden Zeilen rot markiert werden um drauf hinzuweisen). Also beispielsweise:

Startdatum 1.1.1925, Länge 4 Monate

Dann kann man Ankünfte und Abfahrten festlegen, am besten zuerst bei der ersten Anweisung beginnen. Es geht eine separate GUI auf, in der man mit Choose & Next jeweils zur nächsten Abfahrt / Ankunft springen kann; Ziel: Das ganze mit möglichst wenig Klicks ausfüllen können.

Ich mach es immer so, dass ich dieses kleine Fenster offen lasse während das Fahrzeug fährt, und immer dann wenn es wo vorbeikommt die nächsten Daten ausfülle.

Dann haben wir z.B. sowas wie
A-Dorf: Ankunft 27.1.1925, Abfahrt 3.2.1925
B-Stadt: Ankunft 12.2.1925, Abfahrt 17.2.1925
Wegpunkt C: Ankunft & Abfahrt 3.3.1925
(...)
D-Stadt: Ankunft 23.4.1925, Abfahrt 28.4.1925

Diese Ankunfts- und Abfahrtszeiten sind absolut angegeben.

Der Trick ist jetzt, dass sie sich um die Fahrplanlänge in die Zukunft verschieben, sobald das Fahrzeug von der letzten zur ersten Anweisung wechselt (also, von D-Stadt nach A-Dorf). Dann haben wir A-Dorf Ankunft 27.5.1925, Abfahrt 3.6.1925.

Mehrere Fahrzeuge können sich denselben Fahrplan teilen, indem die Fahrzeuge unterschiedliche Offsets gegebenüber demselben Fahrplan haben, also obiges Fahrzeug z.B. 0 Monate, ein anderes 2 Monate.

Das ist eigentlich schonmal die grundlegende Idee, dazu wie ich das in der Praxis verwende hab ich kurz drüber in Beitrag #29 schon was geschrieben.

Alternativ kann man sich das ganze natürlich von Autofill ausfüllen lassen (zweite Zeile markieren, Button anklicken).

Bei konkreteren Fragen kann ich auch konkreter antworten

Hui, das erklärt fast alles! Riesengroßes Dankeschön dafür ))

Auch von mir ein Dank für die deutsche Anleitung.
Übernächste Woche gehts bei mir mit Testen los, bis dahin leider keine Zeit!

Dank deiner Erklärung hab ich das System verstanden und stelle gerade auf meiner Karte alle 59 Linien auf deine Fahrpläne um, macht echt spaß zuzugucken wie die arrival/departure-Tafeln langsam immer mehr ziele bekommen, danke nochmal!
Aber eine Frage noch zum Verschieben von Orders um ein paar Tage wie oben beschrieben: Ich hab n Zug, der fährt aus Unna nach Enningerloh (bzw Enn-Unn, aber für meine Frage ist die Rückfahrt wichtig ), der braucht im autofill 382 Tage. Ich kenn aber meine vollen Strecken und will ihm 18 Tage Puffer geben, verteilt auf die Halte in Olfen und Münster Stadt, weil ich da überholstellen habe. Verstehe ich das dann richtig, dass ich dann von Olfen bis Enningerloh auf die >> gehen muss mit 9 Days offset und dann nochmal von Münster Stadt? Die Länge vom Fahrplan hab ich bereits angehoben auf 400.
Gruß Danny

Müsste, soweit ich verstehe was du machst, so funktionieren.

Erste zu verschiebende Anweisung anklicken, letzte zu verschiebende Anweisung anklicken, Zeit angeben ist der Ablauf.
(Der erste Klick wählt standardmäßig die Abfahrt dort aus, mit Ctrl die Ankunft; der zweite Klick wählt standardmäßig die Ankunft dort aus, mit Ctrl die Abfahrt).

Wenn man beim ersten Klick nochmal auf "<<" bzw. ">>" klickt, wählt man den ganzen Fahrplan aus.
Wenn man beim zweiten Klick statt auf eine Anweisung auf "<<" bzw. ">>" klickt, wählt man alles vom ersten Klick bis zum Ende des Fahrplans aus.

Im Zweifelsfall würd ich sagen, speicher mal zur Sicherheit und probier es aus, und falls irgendwas schiefgeht / aus deiner Sicht komisch ist meld dich nochmal...

Eine neue Version (v14) des Patches gibts unter http://www.tt-forums.net/viewtopic.php?f...9#p1058369

Warnung
Sie ist Savegame-Inkompatibel mit der vorherigen, d.h. mit dem derzeit im Umlauf befindlichen Binary von v13 erzeugte Spielstände werden sich nicht laden lassen damit.

Deswegen rate ich dazu, die neue Version nur zu verwenden wenn man ein neues Spiel anfangen will, bei vorhandenen Spielen bitte die alte weiterverwenden (das schadet denke ich auch nicht besonders, weil die Änderungen die für den Spieler überhaupt erkennbar sind halten sich in engen Grenzen).

An Bugfixes ist die fehlgeleitete Fehlermeldung wenn man bei einem neuen Fahrzeug als erstes das Startdatum festlegt weg, und einige Anpassungen an die Funktionsweise von Autofill gab es.

Ansonsten ist die große Änderung bei dem Release dass ich den Code aufgeräumt habe; und dem ist leider auch die Savegame-Kompatibilität zum Opfer gefallen.

gilt die Inkompatibilität für alle zukünftige Versionen?

Bei Patches kannst du grundsätzlich davon ausgehen, daß verschiedene Versionen nicht Savegamekompatibel sein werden, außer es steht explizit was anderes dran.

... und was dieses Patch im speziellen angeht:

v13-Spiele werden sich auch mit zukünftigen Versionen nicht laden lassen, das ist einfach so.

Gegenüber v14 werde ich (hoffentlich, versprechen kann man da natürlich nie was) keine Änderungen mehr am Savegame-Format brauchen.

Inkompatibel wird es dann wieder, wenn es am Trunk eine Savegame-Änderung gibt; dann (technischer Hintergrund) hab ich ein TIP-Spiel mit Savegame-Version 251 erzeugt, die obendrauf auf die derzeit am Trunk gültige 193 kommt; wenn jetzt am Trunk eine 194 dazu kommt, muss ich einen trivialen Reject in meinem Savegame-Versions-Patch fixen, und in den vorher mit meinem Patch erzeugten 251er-Spielständen fehlt die Änderung 194, was beim Laden höchstwahrscheinlich zum Abbruch führt.

Will sagen, eine Haltbarkeitsdauer von mehr als ein paar Monaten kann man den Spielständen nicht zubilligen, wenn man am Trunk dabeibleiben will.

Die einzige Lösung für das Problem ist, sich das OpenTTD-Release für die alten Spielstände dauerhaft zu behalten, dann kann man die alten Laden, kriegt aber natürlich neuere Softwareversionen nicht mit. Bei mir gibts auch etliche trunk_... - Verzeichnisse mit zu verschiedenen Zeitpunkten gebauten OpenTTDs...

Und trotzdem, dass ich vor längerer Zeit gespielte Spiele nie mehr ansehen kann, daran hab ich mich mit meinen langlebigen Patches gewöhnt.

Vermeiden könnte man das nur, indem man das Savegame-Format grundlegend ändert; nur mal als Gedankenspiel, würde man zumindest für manche Sachen (für den map-array natürlicht nicht) gepackte XML-Schnipsel abspeichern, müsste nicht jede Änderung ganz woanders dazu führen dass sich Savegames nicht mehr laden lassen. Aber, ich vermute mal das wird ein Gedankenspiel bleiben.