Hallo,

sneg hat mich freundlicherweise darauf hingewiesen, dass einige Teile meiner Seiten recht unübersichtlich und für Einsteiger schwer verständlich daherkommen. Das ist das Resultat des längeren Wachstums der Seiten über Jahre hinweg, in denen neue Features hinzukamen, die irgendwo untergebracht werden wollten. Daher habe ich mir jetzt mal ein paar Gedanken gemacht, wie ich die ganze Sache besser strukturieren könnte.

Zunächst mal fliegt die Unterscheidung der verschiedenen Versionen von TTDPatch raus, inzwischen ist IMHO nur noch die 2.6 alpha Serie benutzbar. Das vereinfacht die Erläuterungen enorm, da man davon ausgehen kann, dass gewisse Features einfach mal vorhanden sind.

Dann soll die Seitenstruktur geringfügig angepasst werden:

• Grundlagen
  • Versionen/Installation
    • Download und Installation (Links zu entsprechenden Seiten und FAQs)
    • Konfiguration (Links zu den Manuals etc., Schalter, die grundlegend gesetzt sein sollten (für Signal-GUI und ähnliches, aber wirklich nur das allerwichtigste))
    • Grafikkonfiguration (auch nur knapp und mit Links zu FAQs und grfcrawler)
      
  • Baumöglichkeiten
    • Gleisbau allgemein (wo kann man überall Gleise hinlegen)
    • Brücken
    • Tunnel
    • Einfluss von Kurven
    • realistische Steigungen (mit Serpentinen und Kehrschleifen)
      
• Signale
  • Theorie
    • GUI-Erklärung
    • Begriffe wie Signalblock etc
    • Signalverhalten (Grundlagen einseitig/zweiseitig, Halt/Fahrt)
    • Wegfindung und Signale (zweiseitige Signale und Bahnsteigwahl etc)
      
  • Signaltypen (Übersicht, was es gibt, keine detaillierte Beschreibung mit Beispielen etc, eher so als Nachschlageseite mit Links zu den Detailseiten)
    • Standardsignale
    • Vorsignale
    • PBS in TTDX
    • eingeschränkte und programmierbare Signale in TTDX
    • YAPP
      
  • PBS in TTDX (Detailseite zur Konfiguration etc)
  • eingeschränkte und programmierbare Signale (Detailseite mit ausführlicher Erklärung)
  • YAPP (detailliert)
    
• Streckennetze (im Prinzip wie bisher, aber die Beispiele überarbeiten und genauer erklären, wo warum welches Signal steht, außerdem Beispiele mit YAPP hinzufügen)
• Bahnhöfe (bleibt im wesentlichen gleich, die Beispiele müssen aber auch hier überarbeitet werden)
• Fahrpläne
  • Grundlagen (die originalen Fahrplanoptionen aus TTDX)
  • Erweiterte Fahrpläne TTDX
  • Fahrplanoptionen in OTTD (komplett neuer Abschnitt)
    
• Tutorial(s) (komplett neuer Teilbereich, wo man anhand eines exemplarischen Spieles sieht, wie sich die ganzen theoretischen Ideen in der Praxis anwenden lassen, so nach dem Motto "ich will jetzt X machen, wie kann ich das machen, was muss ich beachten")
  • Einstieg bis zur ersten eingleisigen Strecke (Strecke bauen, Fahrplan setzen)
  • die ersten Signale (erweitern der eingleisigen Strecke, um weitere Züge fahren zu lassen)
  • der erste Knotenpunkt (komplexere Bahnhöfe, Umladerei von Frachten)
  • fortgeschrittene Netzwerke (Wegpunkte und besondere Signaltricksereien)
    

Die Abschnitte zu DBSetXL und GermanRV werden sich nicht ändern, die werden nur je nach Fortschritt aktualisiert.

Meinungen, Ideen, Ergänzungen?

Also ich würde darauf achten, daß die Pfadsignale (YAPP) bei der Signalübersicht möglichst weit vorne auftauchen, und daß darauf hingewiesen wird, daß diese die wahrscheinlich einfachste Signalisierungsvariante ist. Für 95% der Fälle braucht man nämlich keine anderen Signale.

Ich frage mich, ob es dann nicht sogar sinnvoll wäre, die ganze Seite so zu modularisieren, dass man Inhalte nach TTDPatch bzw. OpenTTD filtern könnte. Dann würde man nicht von Beispielen verwirrt werden, die mit Patch-Signalen gebaut sind und in OpenTTD ganz anders gebaut werden müssen. Außerdem würde die ganze Sache damit deutlich übersichtlicher, weil man nicht erst Erläuterungen überfliegen muss, die überhaupt nicht relevant sind.

Der Text würde vor allem merklich kürzer da, wie Eddi schon schreibt, bzgl der Signalisierung bei OTTD ein bemerkenswerter Trend zur Vereinfachung vorzuliegen scheint.

Gruß
Michael

Sooo, sogar noch pünktlich zum Nikolaus ist die überarbeitete Version nun (wenn auch noch unvollständig) online. Die Tutorials fehlen noch, da muss ich erstmal was spielen, um Material zum beschreiben zu haben, das wird dann denke ich über Weihnachten. Ich hab garantiert auch noch diverse Fehler drin, irgendwann sieht man ja beim Schreiben den Wald vor lauter Bäumen nicht mehr. Es wäre also schön, wenn mal jemand draufguckt und mich auf eventuelle Schnitzer und Fehler hinweist.

Gruß,
Uwe

In diesem Thread ist mir aufgefallen, dass ein simples Beispiel für einen Durchgangsbahnhof der bei allen Gleisen von beiden Seiten befahren werden kann, fehlt. Der Beispielsbahnhof mit Gleisen, die nur für eine Richtung sind, sind wohl gerade für Neulinge eher verwirrend, und gerade für die sind möglichst einfache Beispiele wichtig! Einen solchen Bahnhof wie auf deiner Seite habe ich bisher noch nie gebaut, einen solchen bei dem alle Gleise angefahren werden können allerdings schon X mal, und ich denk den meisten gehts ähnlich.

Auch sonst - scheitn es mir - hat es viele unnötige Bahnhöfe. Auf der Seite Kombinationen hat es zwar recht viele Beispiele, aber sind die wirklich nötig? Ein Neuling wird da wahrscheinlich recht überfordert sein. Wer die Signale einmal begriffen hat, kommt auch meist selber auf solche Lösungen.

Was ich damit sagen will: Ich hab mir die Seite jetzt nicht vollständig durchgelesen, aber es kommt mir oft vor, dass du zu sehr ins Detail erklärst. Aber gerade für Neulinge macht es das nicht wirklich einfach.


Ausserdem funktioniert der Filter nicht richtig. Z.B. bei den Durchgangsbahnhöfen:

Ist der Filter auf TTDPatch, zeigt er fünf Bahnhöfe an die nur für TTDP sind, einer für OTTD und einer für beide.
-> Der bahnhof für OpenTTD ist zuviel.

Ist der Filter auf OpenTTD, zeigt er vier Bahnhöfe an die nur für OTTD sind.
-> Es fehlt ein Bahnhof der für OTTD ist und der eine, der für beide ist.


Und was mir beim schnellen Durchklicken auch gerade noch aufgefallen ist:

Für die "gemeinsame Gleisnutzung (Anpassungen)" bei OpenTTD gibt es eine - wie ich finde - bessere Variante. Wenn man vor der Verzweigung auf beide Strecken ein YAPP Signal hinstellt, das von der Verzweigung weg zeigt, kann eine bessere zugfolge erzielt werden. Angenommen, es komme ein Zug von der engleisigen Strecke und will nach links, kann er dan normal tun, er reserviert die Strecke normal bis zur Ausweichstelle, das zusätzliche YAPP wird in dem Fall ja von hinten durchfahren. Kommt gleichzeitig von rechts ein Zug, kann er schon mal bis zum neueen YAPP direkt vor der Verzweigung vorfahren und dort warten, bis die Strecke frei wird, anstatt dass er bei der Ausweichstelle, die u.u. weit weg von der Verzweigung ist, warten muss. Dass sich die Züge gegenseitig blockieren, kann trotzdem nicht passieren.

Erstmal danke für die Kritik, ist immer gut wenn sich tatsächlich mal einer durchliest was ich da geschrieben habe

(12.01.2010 23:54)Addi schrieb:  In diesem Thread ist mir aufgefallen, dass ein simples Beispiel für einen Durchgangsbahnhof der bei allen Gleisen von beiden Seiten befahren werden kann, fehlt. Der Beispielsbahnhof mit Gleisen, die nur für eine Richtung sind, sind wohl gerade für Neulinge eher verwirrend, und gerade für die sind möglichst einfache Beispiele wichtig!

Du hättest gerne diesen Bahnhof?



Ich halte diese Konstruktion für ziemlich bescheiden, gerade für Anfänger, weil der Bahnhof ganz schnell komplett überlastet sein kann und dann die Strecke in beiden Richtungen komplett blockiert ist. Schlimmer noch, Züge können über die 90°-Verbindung umdrehen, anstatt in den Bahnhof einzufahren. Und selbst wenn man das verhindert bleibt immer noch das Problem, dass ein Zug, der auf das in Fahrtrichtung linkstmögliche Gleis fährt, die gesamte Kreuzung blockiert...

(12.01.2010 23:54)Addi schrieb:  Einen solchen Bahnhof wie auf deiner Seite habe ich bisher noch nie gebaut, einen solchen bei dem alle Gleise angefahren werden können allerdings schon X mal, und ich denk den meisten gehts ähnlich.

Einen solchen Bahnhof, auf dem man aus beiden Richtungen an alle Gleise fahren kann, habe ich noch nie gebaut, einen solchen wie in meinem Beispiel allerdings schon X mal, und ich denk dass das überhaupt kein Argument dafür oder dagegen ist.

(12.01.2010 23:54)Addi schrieb:  Was ich damit sagen will: Ich hab mir die Seite jetzt nicht vollständig durchgelesen, aber es kommt mir oft vor, dass du zu sehr ins Detail erklärst. Aber gerade für Neulinge macht es das nicht wirklich einfach.

Na offensichtlich ist es aber stellenweise noch nicht detailliert genug, sonst würden nicht immer die gleichen Fragen gestellt werden...

(12.01.2010 23:54)Addi schrieb:  Ausserdem funktioniert der Filter nicht richtig. Z.B. bei den Durchgangsbahnhöfen:

Habe ich korrigiert.

(12.01.2010 23:54)Addi schrieb:  Für die "gemeinsame Gleisnutzung (Anpassungen)" bei OpenTTD gibt es eine - wie ich finde - bessere Variante. Wenn man vor der Verzweigung auf beide Strecken ein YAPP Signal hinstellt, das von der Verzweigung weg zeigt, kann eine bessere zugfolge erzielt werden. Angenommen, es komme ein Zug von der engleisigen Strecke und will nach links, kann er dan normal tun, er reserviert die Strecke normal bis zur Ausweichstelle, das zusätzliche YAPP wird in dem Fall ja von hinten durchfahren. Kommt gleichzeitig von rechts ein Zug, kann er schon mal bis zum neueen YAPP direkt vor der Verzweigung vorfahren und dort warten, bis die Strecke frei wird, anstatt dass er bei der Ausweichstelle, die u.u. weit weg von der Verzweigung ist, warten muss. Dass sich die Züge gegenseitig blockieren, kann trotzdem nicht passieren.

Und wie verhinderst du, dass ein Zug von links kommt und dem Zug in der Mitte den Weg abschneidet? Das was du meinst funktioniert nur, wenn in der Mitte kein eingleisiger Abschnitt ohne Ausweichstelle ist. Ansonsten siehe dort?

(13.01.2010 19:48)Uwe schrieb:  

(12.01.2010 23:54)Addi schrieb:  Was ich damit sagen will: Ich hab mir die Seite jetzt nicht vollständig durchgelesen, aber es kommt mir oft vor, dass du zu sehr ins Detail erklärst. Aber gerade für Neulinge macht es das nicht wirklich einfach.

Na offensichtlich ist es aber stellenweise noch nicht detailliert genug, sonst würden nicht immer die gleichen Fragen gestellt werden...

Naja, was fehlt ist ein Schnelleinstieg. Wenn ich mit einem Bekannten OpenTTD spielen möchte, und ich bezüglich Netzgestaltung sage "Guck mal da", kommt meistens zurück, dass das zu viel ist, um es mal "querzulesen".

Hmm, da fällt mir auf, dass ich ja eigentlich über Weihnachten noch am Tutorial basteln wollte... evtl. ist das ja dann für einen Schnelleinstieg noch am geeignetsten.

(13.01.2010 19:48)Uwe schrieb:  Du hättest gerne diesen Bahnhof?

Genau so einen meinte ich.

(13.01.2010 19:48)Uwe schrieb:  Ich halte diese Konstruktion für ziemlich bescheiden, gerade für Anfänger, weil der Bahnhof ganz schnell komplett überlastet sein kann und dann die Strecke in beiden Richtungen komplett blockiert ist. Schlimmer noch, Züge können über die 90°-Verbindung umdrehen, anstatt in den Bahnhof einzufahren. Und selbst wenn man das verhindert bleibt immer noch das Problem, dass ein Zug, der auf das in Fahrtrichtung linkstmögliche Gleis fährt, die gesamte Kreuzung blockiert...

Eine 90° Kurve entsteht aber schnell beim bauen. Es lohnt sich kaum, diese konsequent zu vermeiden. Ausserdem hab ich noch nie beobachtet, dass ein Zug es vorzieht zurückzufahren, als vor dem PBS Signal zu warten, bis ein Gleis frei wird. YAPF ist schon relativ intelligent! Und das linksmöglichste Gleis wird ja sozusagen nur in "Ausnahmefällen" benützt. Wenn dieses nicht zur verfügung steht, muss der Zug einfach warten, und das ist ja nicht grad viel besser. Die Chancen, dass ein ICE der da eh nur rasch Durchfahren willsozusagen "durch die Lücke" passt ist relativ hoch.

(13.01.2010 19:48)Uwe schrieb:  Einen solchen Bahnhof, auf dem man aus beiden Richtungen an alle Gleise fahren kann, habe ich noch nie gebaut, einen solchen wie in meinem Beispiel allerdings schon X mal, und ich denk dass das überhaupt kein Argument dafür oder dagegen ist.

Meine Beobachtungen hier im Forum haben gezeigt, dass die Nachfrage nach "meiner Variante" um einiges höher ist als nach "deiner Variante"

(13.01.2010 19:48)Uwe schrieb:  

(12.01.2010 23:54)Addi schrieb:  Was ich damit sagen will: Ich hab mir die Seite jetzt nicht vollständig durchgelesen, aber es kommt mir oft vor, dass du zu sehr ins Detail erklärst. Aber gerade für Neulinge macht es das nicht wirklich einfach.

Na offensichtlich ist es aber stellenweise noch nicht detailliert genug, sonst würden nicht immer die gleichen Fragen gestellt werden...

Oder villeicht haben sie es einfach nicht verstanden? Ich kann mich nur wiederholen: durch möglicht einfache und simple Beispiele lernt man am besten. Wenn ich ein neuling wäre und deine komplizierten Spezialbahnhofskonstruktionen sehe, würde es mir wahrscheinlich auch schnell wieder abschalten.

(13.01.2010 19:48)Uwe schrieb:  

(12.01.2010 23:54)Addi schrieb:  Ausserdem funktioniert der Filter nicht richtig. Z.B. bei den Durchgangsbahnhöfen:

Habe ich korrigiert.

*ausprobier* iregendwie stimmts immernoch nicht...

(13.01.2010 19:48)Uwe schrieb:  

(12.01.2010 23:54)Addi schrieb:  [...]

Und wie verhinderst du, dass ein Zug von links kommt und dem Zug in der Mitte den Weg abschneidet? Das was du meinst funktioniert nur, wenn in der Mitte kein eingleisiger Abschnitt ohne Ausweichstelle ist.

Kommt von lins und rechts ein zug, fahren erst beide auf die Verzweigung zu. Der, der zuerst da ist, fährt weiter, der andere wartet. ich sehe da keine Probleme. So wie es jetzt ist, hat man dieses Problem sozusagen nur "nach aussen verschoben". Der Zug, der zuerst die Ausweichstelle verlassen kann, darf fahren, der andere Zug muss dann in der Ausweichstelle warten, anstatt dass er schon bis zur Verzweigung vorfahren kann wie in meiner Variante.


Und, was mir auch grad noch aufgefallen ist:

Dieser Bahnhof ist unnötig kompliziert:

Wofür braucht man da programmierbare Signale? Die Züge vom Signal A können ohnehin nur auf Gleis 1 + 2 fahren, die anderen sind den Gleisverbindungen wegen erst gar nicht zu erreichen. Das selbe gilt für Signale B und C. Und schon funzt der Bahnhof auch in OpenTTD

Oder wolltest du nur demonstrieren, was programmierbare Signale alles können? Dann wäre es aber ein eher unglückliches Beispiel.

(13.01.2010 23:08)Addi schrieb:  Eine 90° Kurve entsteht aber schnell beim bauen. Es lohnt sich kaum, diese konsequent zu vermeiden. Ausserdem hab ich noch nie beobachtet, dass ein Zug es vorzieht zurückzufahren, als vor dem PBS Signal zu warten, bis ein Gleis frei wird. YAPF ist schon relativ intelligent! Und das linksmöglichste Gleis wird ja sozusagen nur in "Ausnahmefällen" benützt. Wenn dieses nicht zur verfügung steht, muss der Zug einfach warten, und das ist ja nicht grad viel besser. Die Chancen, dass ein ICE der da eh nur rasch Durchfahren willsozusagen "durch die Lücke" passt ist relativ hoch.

Das stimmt zwar alles, aber Murphy ist Perfektionist - wenn irgendwas schiefgehen kann, wird das irgendwann auch passieren, und dann reagieren Züge plötzlich nicht so wie man es erwartet (und sei es nur, weil ein Zug plötzlich ins Depot will und darum an einer Stelle umdreht, die dafür nicht gedacht war). Man sollte also grundsätzlich so bauen, dass ein Zug gar nicht erst die Möglichkeit bekommt, falsch abzubiegen. In OpenTTD ist das Verbot von 90°-Kurven dabei schon recht hilfreich.

(13.01.2010 23:08)Addi schrieb:  

(13.01.2010 19:48)Uwe schrieb:  

(12.01.2010 23:54)Addi schrieb:  Was ich damit sagen will: Ich hab mir die Seite jetzt nicht vollständig durchgelesen, aber es kommt mir oft vor, dass du zu sehr ins Detail erklärst. Aber gerade für Neulinge macht es das nicht wirklich einfach.

Na offensichtlich ist es aber stellenweise noch nicht detailliert genug, sonst würden nicht immer die gleichen Fragen gestellt werden...

Oder villeicht haben sie es einfach nicht verstanden? Ich kann mich nur wiederholen: durch möglicht einfache und simple Beispiele lernt man am besten. Wenn ich ein neuling wäre und deine komplizierten Spezialbahnhofskonstruktionen sehe, würde es mir wahrscheinlich auch schnell wieder abschalten.

Also noch viel einfacher und simpler als die Konstruktionen mit YAPP gehts ja wohl nun wirklich nicht mehr. Dass man vorher verstanden haben muss, wie die YAPP-Signale funktionieren, ist halt nicht zu vermeiden.

(13.01.2010 23:08)Addi schrieb:  

(13.01.2010 19:48)Uwe schrieb:  

(12.01.2010 23:54)Addi schrieb:  Ausserdem funktioniert der Filter nicht richtig. Z.B. bei den Durchgangsbahnhöfen:

Habe ich korrigiert.

*ausprobier* iregendwie stimmts immernoch nicht...

Mist, dann muss ich mir das heut abend noch mal anschauen.

(13.01.2010 23:08)Addi schrieb:  

(13.01.2010 19:48)Uwe schrieb:  

(12.01.2010 23:54)Addi schrieb:  [...]

Und wie verhinderst du, dass ein Zug von links kommt und dem Zug in der Mitte den Weg abschneidet? Das was du meinst funktioniert nur, wenn in der Mitte kein eingleisiger Abschnitt ohne Ausweichstelle ist.

Kommt von lins und rechts ein zug, fahren erst beide auf die Verzweigung zu. Der, der zuerst da ist, fährt weiter, der andere wartet. ich sehe da keine Probleme. So wie es jetzt ist, hat man dieses Problem sozusagen nur "nach aussen verschoben". Der Zug, der zuerst die Ausweichstelle verlassen kann, darf fahren, der andere Zug muss dann in der Ausweichstelle warten, anstatt dass er schon bis zur Verzweigung vorfahren kann wie in meiner Variante.

Zug 1 kommt von links, fährt in den eingleisigen Abschnitt in der Mitte ein. Zug 2, ebenfalls von links kommend, rückt nach. Zug 1 kann nicht mehr zurück, weil Zug 2 im Weg steht. Und nun?

(13.01.2010 23:08)Addi schrieb:  Dieser Bahnhof ist unnötig kompliziert:

Wofür braucht man da programmierbare Signale? Die Züge vom Signal A können ohnehin nur auf Gleis 1 + 2 fahren, die anderen sind den Gleisverbindungen wegen erst gar nicht zu erreichen. Das selbe gilt für Signale B und C. Und schon funzt der Bahnhof auch in OpenTTD

Oder wolltest du nur demonstrieren, was programmierbare Signale alles können? Dann wäre es aber ein eher unglückliches Beispiel.

In TTDPatch braucht man dort programmierbare Signale. Wenn Gleis 1+2 belegt sind, wird der nächste Zug sonst nicht an Signal A warten, weil er einen Pfad zum nächsten Signal reservieren kann, und das steht an der vom Bahnhof wegführenden Strecke, entweder neben Signal B oder C. Merke: PBS überschreibt Vorsignalverhalten!
Wenn du ein besseres Beispiel für programmierbare Signale hast, nur zu.

(14.01.2010 07:41)Uwe schrieb:  Zug 1 kommt von links, fährt in den eingleisigen Abschnitt in der Mitte ein. Zug 2, ebenfalls von links kommend, rückt nach. Zug 1 kann nicht mehr zurück, weil Zug 2 im Weg steht. Und nun?

Ok, kommt drauf an, wie die eingleisige Strecke weitergeht. Kommt eine weitere Ausweichstelle (wovon ich ausgegangen bin) oder ein bahnhof, der mindestens soviele Gleise Besitzt wie Züge die ihn anfahren, dann gehts. Folgt aber z.B. ein eingleisiger Bahnhof, dann hast du rechts, dann könnten sich die Züge blockieren.

(14.01.2010 07:41)Uwe schrieb:  In TTDPatch braucht man dort programmierbare Signale. Wenn Gleis 1+2 belegt sind, wird der nächste Zug sonst nicht an Signal A warten, weil er einen Pfad zum nächsten Signal reservieren kann, und das steht an der vom Bahnhof wegführenden Strecke, entweder neben Signal B oder C. Merke: PBS überschreibt Vorsignalverhalten!

Verstehe ich das richtig? Gleis 1 + 2 sind besetzt und es kommt ein Zug von Signal A. Dann reserviert er einen Pfad zum Ausfahrtssignal neben Signal B oder C? Dann zeichne mir doch mal ein, wo der Zug da durchfahren würde. Oder reserviert TTDP etwa auch Pfade, die gar nicht durchfahren werden können?

TTDP-PBS funktionieren anders als YAPP. Wenn der Zug an eines der Signale A,B,C kommt, reserviert er zum nächsten Signal, was bei TTDP vor dem Bahnhof steht, und steckt deshalb in ner Sackgasse, wenn beide Gleise belegt sind. In OpenTTD steht dort kein Signal (oder nur die Rückseite) und deshalb muß eine Streckenreservierung bis auf den Bahnsteig gelangen, sonst bleibt der Zug stehen. Deshalb braucht man hier bei TTDP Programmierbare Signale, und bei OTTD nicht.

(14.01.2010 13:23)Eddi schrieb:  TTDP-PBS funktionieren anders als YAPP. Wenn der Zug an eines der Signale A,B,C kommt, reserviert er zum nächsten Signal, was bei TTDP vor dem Bahnhof steht, und steckt deshalb in ner Sackgasse, wenn beide Gleise belegt sind. In OpenTTD steht dort kein Signal (oder nur die Rückseite) und deshalb muß eine Streckenreservierung bis auf den Bahnsteig gelangen, sonst bleibt der Zug stehen. Deshalb braucht man hier bei TTDP Programmierbare Signale, und bei OTTD nicht.

TTDP-PBS hat mittlerweile (seit vielen, vielen Monaten), auch spezielle Signale, die auch von der "Rückseite" befahren werden können. Sie sind durch einen schwarz-weiß markierten Pfahl an der Stelle gekennzeichnet, wo sonst das Signal für die Gegenrichtung stehen würde.

(14.01.2010 09:04)Addi schrieb:  

(14.01.2010 07:41)Uwe schrieb:  Zug 1 kommt von links, fährt in den eingleisigen Abschnitt in der Mitte ein. Zug 2, ebenfalls von links kommend, rückt nach. Zug 1 kann nicht mehr zurück, weil Zug 2 im Weg steht. Und nun?

Ok, kommt drauf an, wie die eingleisige Strecke weitergeht. Kommt eine weitere Ausweichstelle (wovon ich ausgegangen bin) oder ein bahnhof, der mindestens soviele Gleise Besitzt wie Züge die ihn anfahren, dann gehts. Folgt aber z.B. ein eingleisiger Bahnhof, dann hast du rechts, dann könnten sich die Züge blockieren.

Deswegen steht das mit dem zusätzlichen Signal auch an anderer Stelle.

(14.01.2010 09:04)Addi schrieb:  

(14.01.2010 07:41)Uwe schrieb:  In TTDPatch braucht man dort programmierbare Signale. Wenn Gleis 1+2 belegt sind, wird der nächste Zug sonst nicht an Signal A warten, weil er einen Pfad zum nächsten Signal reservieren kann, und das steht an der vom Bahnhof wegführenden Strecke, entweder neben Signal B oder C. Merke: PBS überschreibt Vorsignalverhalten!

Verstehe ich das richtig? Gleis 1 + 2 sind besetzt und es kommt ein Zug von Signal A. Dann reserviert er einen Pfad zum Ausfahrtssignal neben Signal B oder C? Dann zeichne mir doch mal ein, wo der Zug da durchfahren würde. Oder reserviert TTDP etwa auch Pfade, die gar nicht durchfahren werden können?

Vergiss was ich da geschrieben hab, das war vor dem ersten Kaffee Tatsache ist, dass der Zug in den Block einfährt und dann vorm Bahnhof stehenbleibt, was ja nicht Sinn und Zweck der Aktion ist. Die programmierbaren Signale braucht man also. Alternativ könnte man auch die Durchfahrtsignale benutzen, die pETe angesprochen hat. Dann entspricht das Verhalten dem von YAPP in OpenTTD.

Uwe schrieb:In TTDPatch braucht man dort programmierbare Signale. Wenn Gleis 1+2 belegt sind, wird der nächste Zug sonst nicht an Signal A warten, weil er einen Pfad zum nächsten Signal reservieren kann, und das steht an der vom Bahnhof wegführenden Strecke, entweder neben Signal B oder C.

Eddi schrieb:TTDP-PBS funktionieren anders als YAPP. Wenn der Zug an eines der Signale A,B,C kommt, reserviert er zum nächsten Signal, was bei TTDP vor dem Bahnhof steht, und steckt deshalb in ner Sackgasse, wenn beide Gleise belegt sind.

Auf die Gefahr hin mich lächerlich zu machen.

Dass man dafür programmierbare Signale braucht halte ich für ein Gerücht. Ich habe das eben mal in TTDPatch (r2263) nachgebaut und, wie erwartet, funktioniert das ohne programmierbare Signale. Der Zug hält einwandfrei an "A" und da wird auch kein Pfad zu einem anderen Signal reserviert.

   


Hattest du in deinem Beispiel (ohne programmierbare Signale) noch irgendwelche Besonderheiten eingebaut?

Gruß
Michael

Ach mensch, jetzt macht doch nicht das Beispiel unbrauchbar, da muss ich mir ja ein neues ausdenken mb hat recht, das funktioniert an der Stelle tatsächlich ohne programmierte Signale, habs auch grad noch mal getestet. Was mich viel mehr stört ist aber, dass ich es gerade nicht hinbekomme, mit programmierten Signalen tatsächlich das Vorsignalverhalten funktionierend nachzubilden...

(14.01.2010 20:21)mb schrieb:  Der Zug hält einwandfrei an "A"

Mal abgesehen von dem unrealistischen Detail, daß der Zug an einem "Fahrt" zeigenden Signal hält...

Eddi schrieb:

mb schrieb:Der Zug hält einwandfrei an "A"

Mal abgesehen von dem unrealistischen Detail, daß der Zug an einem "Fahrt" zeigenden Signal hält...

Naja, zum Ausgleich fahren sie ja auch bei "rot" durch.

Ernsthaft: das könnte an Uwes spezieller Anordnung liegen (?), muss ich bei Gelegenheit mal untersuchen. Worauf es mir zunächst ankam war dir Richtigstellung dass PBS in TTDPatch eben nicht das unterstellte seltsame Verhalten zeigt sodass es für ein derart simples Problem bereits "programmierbare Signale" bedarf.

Gruß
Michael

Also ich hab da gestern abend auch noch mal rumgetestet gehabt, es scheint tatsächlich direkt mit der Anordnung der Gleise zu tun zu haben. Solange ein Zug keinen anderen Pfad reservieren kann, der ihn auch in Richtung des Ziels bringt, bleibt er an dem Signal stehen.

Bleibt die grundsätzliche Frage nach einem Anwendungsbeispiel für programmierbare Signale...