Zitat:Ich vermute, es wäre erheblich aufwändiger oder sogar unmöglich, aber wenn der Pfad eines Zuges beim Passieren von P1 oder P2 bis zum übernächsten Signal vorausberechnet wird und dabei erkannt wird, dass der Zug am wahrscheinlichsten nach P5 fährt, könnte man ihn ohne Höchstgeschwindigkeit weiterfahren lassen.

Es gibt ja sowas! Bei YAPF gibt es eine Formel die die nächsten 5 Signale und ihre Zustände für die Streckensuche berücksichtigt. Also existiert der Grundpfad eines Zuges, zwar nicht immer zu 100% aber anscheinend über die nächsten 5 Signale.....

Also, es macht für mich folgendes keinen Sinn: wenn ich im Kreuzungsbereich Blocksignale setze (selbst wenn sie die Geschwindigkeit messen und weitergeben), ist im Augenblick, wo ein Zug diese Kreuzung passiert, die Kreuzung für andere Züge gesperrt, also auch, wenn sich deren Wege nicht kreuzen würden. Also ist für mich das Setzen von Blocksignalen in Kreuzungsbereichen nicht sehr logisch, wenn ich die Pfadsignale nehmen kann. Wenn also das Feature bei den Blocksignalen da wäre, würde ich folgende zwei Punkte in kauf nehmen müssen, wenn ich sie im Kreuzungsbereich setze:

- bei Zugdurchfahrten im Kreuzungsbereich, dieser Block für alle gesperrt
- bei Durchfahrt des Zuges, bei Vermittelung der Geschwindigkeit an alle Signale, die an der Kreuzung stehen, Verlangsamung der Geschindigkeit auf diesen einen Zug, zumindest für eine bestimmte Zeit

Daher würde ich sie ja nicht in Kreuzungsbereichen einsetzen und dieses Feature muss ja nicht zwingend auf die Pfadsignale programmiert werden.

Von daher würde ich doch nur folgendes umsetzen, (wenn ich es könnte, vielleicht muss ich mich mal richtig schlau machen und den Versuch starten, dieses mal zu programmieren): ein Blocksignal mit der Funktion: Erkennung der maximalen Geschwindigkeit eines Zuges (Zugart/ Waggons - deren maximale Geschwindigkeit - ist vielleicht sowas wie eine Tabelle, wenn man so will) und Vermittlung an den Block (bzw. an das Signal) dahinter und nachdem der Zug das nächste Signal durchfahren hat, wird der vorletzte Block mit der Geschwindigkeitsbegrenzung wieder freigegeben.

Ist das denn nicht machbar? Oder habe ich da einen Gedankenfehler?

Gruß
Zhonary

(01.02.2013, 11:12)Zhonary schrieb: - bei Durchfahrt des Zuges, bei Vermittelung der Geschwindigkeit an alle Signale, die an der Kreuzung stehen, Verlangsamung der Geschindigkeit auf diesen einen Zug, zumindest für eine bestimmte Zeit

Wenn man in Kauf nimmt, dass die gesamte Kreuzung für einen bestimmten Zeitraum verlangsamt wird, unabhängig von allen möglichen Pfaden, dann ist doch die Komplexität der Implementierung für Pfad- und Blocksignale dieselbe. Und auch ich würde das in Kauf nehmen.

(01.02.2013, 11:12)Zhonary schrieb: Von daher würde ich doch nur folgendes umsetzen, (wenn ich es könnte, vielleicht muss ich mich mal richtig schlau machen und den Versuch starten, dieses mal zu programmieren): ein Blocksignal mit der Funktion: Erkennung der maximalen Geschwindigkeit eines Zuges (Zugart/ Waggons - deren maximale Geschwindigkeit - ist vielleicht sowas wie eine Tabelle, wenn man so will) und Vermittlung an den Block (bzw. an das Signal) dahinter und nachdem der Zug das nächste Signal durchfahren hat, wird der vorletzte Block mit der Geschwindigkeitsbegrenzung wieder freigegeben.

Das Durchfahren eines Signals hebt die Limitierung des vorletzten auf, das finde ich gut. Allerdings würde ich die Limitierung zusätzlich an einen Countdown koppeln. Wenn man ansonsten das letzte Signal einer Strecke durchfährt würde vorletzte nie mehr freigegeben werden.

Und mit der Entnahme der Höchstgeschwindigkeit aus der Tabelle habe ich so meine Schwierigkeiten. Steigungen und Kurven blieben unberücksichtigt. Auch wenn drei Züge hintereinander fahren, der erste kann max. 80 km/h, die folgenden beiden können 200 km/h, da würde der dritte immer auch den zweiten auffahren. Das würde ich dann schon nicht mehr in Kauf nehmen wollen, bzw. dann kann man sich die Mühe auch sparen. Nein, eine Messung oder Weitergabe der aktuellen Geschwindigkeit müsste es schon sein. Geht sowas?

Ob was geht, oder nicht, liegt mehr oder weniger im Talent des Programmierers.
Das wirklich Begrenzende ist die Rechenleistung, was nützt einem das Feature wenns nach 10 Zügen zu ruckeln beginnt.

Es gibt mehrere Arten an Kreuzungsbereichen, für jede von denen macht es mehr oder weniger Sinn das Feature zu benutzen.
Können wir mal sowas wie eine Liste von : "Wie soll Was Wann passieren" erarbeiten?
1. Vorschlagsteil von mir :

Zitat:Zu Lösen ist es über ein Extra Signal, damit man es zB nur auf bestimmten Strecken anwenden kann.
Also Nur die Signale des neuen Typs übergeben die Geschwindigkeiten an benachbarte Signale gleichen Typs. Somit kann durch setzen eines Normalen Blocksignals die Handlungskette unterbrochen werden.

Macht man nur 1 extra Signal, das als Block ausführen, oder macht man 2 extra Signale, 1x Block 1x Pfad?

(01.02.2013, 17:04)Sallarsahr schrieb:

Zitat:Zu Lösen ist es über ein Extra Signal, damit man es zB nur auf bestimmten Strecken anwenden kann.
Also Nur die Signale des neuen Typs übergeben die Geschwindigkeiten an benachbarte Signale gleichen Typs. Somit kann durch setzen eines Normalen Blocksignals die Handlungskette unterbrochen werden.

Macht man nur 1 extra Signal, das als Block ausführen, oder macht man 2 extra Signale, 1x Block 1x Pfad?

Ich befürchte, wenn die Performance unter der Signalerweiterung leidet, braucht man auch gar nicht erst mit einem Extrasignal anfangen. Man könnte von diesen Extrasignalen auch nur eine begrenzte Menge einsetzten bis Ruckeln oder irgendwelche Fehler einsetzen. Und wenn man etwas nicht in vollem Umfang nutzen kann, birgt das eigentlich nur Frustpotential.

Wenn die Performance kein Thema ist, sollten der „Einfachheit“ halber wenn möglich alle Signale erweitert werden und der Funktionsumfang (Geschwindigkeitsanpassung an/aus, Zeitfenster von x Sekunden) in den Spieleinstellungen regelbar sein. Wenn man aber über Extrasignale nachdenkt, dann sollten sie neben der dynamischen Höchstgeschwindigkeit noch mehr können, wie z.B. eine individuell einstellbare Höchstgeschwindigkeit. Das wäre für die „Modelleisenbahnbauer“ unter uns sicher sehr interessant, um Züge in Rangierabschnitten oder Ortsdurchfahrten zur Reduzierung der Lärmbelästigung abzubremsen.

Und noch eine Idee in den Raum geworfen: wenn eine Signalerweiterung aus programmiertechnischen Gründen zu schwierig ist, wie verhält es sich mit Extrasignalen, die nur über die Funktion der dynamischen Geschwindigkeitsregelung verfügen? Die also weder Pfad noch Block freigeben, sondern lediglich die Geschwindigkeit dynamisch und/oder individuell regeln. Dann müsste man halt vor einem Block oder Pfadsignal ein solches Geschwindigkeitssignal aufstellen. Etwas umständlicher zum Spielen, aber vielleicht eher zu programmieren?

Also nur der Vollständigkeit halber möchte ich mal meine eigene "Vision" anbringen, wie man das Problem angehen könnte.

1. Verabschiedet euch mal von der Idee, das an "Signalen" festzumachen, Signale in OpenTTD sind "dumm" [wenn sie nicht programmierbar/restriktiv sind, das ist aber ein anderes Thema] und können nur rot oder grün anzeigen.
   
2. Züge sollten einen "Bremsweg" reservieren, der auf Basis der aktuellen Geschwindigkeit berechnet wird. Die Berechnung der Länge [in Feldern] sei hier mal offen gelassen.
   
3. Im Bereich von Blocksignalen wird nur der Bremsweg selbst reserviert, allerdings werden alle anderen Blocksignale in der Nähe der Reservierung auf rot geschaltet, als ob ein Zug im Block wäre. Also Signale innerhalb der Reservierung sind fest auf grün und können nicht mehr "spontan" direkt vor dem Zug auf rot geschaltet werden.
   
4. Im Bereich von Pfadsignalen wird wie gewohnt weiter reserviert, bis ein Signal oder das Streckenende erreicht wird
   
5. Sollte der Bremsweg nicht vollständig reserviert werden können, dann wird die Höchstgeschwindigkeit entsprechend des real reservierten Bremsweges herabgesetzt.
   
6. Außerdem wird der Verlauf der Reservierung dafür benutzt, welche "Kurvenhöchstgeschwindigkeit" (sowie Gleistypen, Brücken, Bahnübergänge) für die Strecke gilt.
   

Das sollte ungefähr 3 Probleme auf einmal lösen, und benötigt noch nichtmal die Position/Geschwindigkeit von anderen Zügen in der Umgebung.

1. Die Züge müssen nicht mehr innerhalb von 1 Feld vor dem Signal zum stehen kommen. Je nach Schwierigkeitsgrad könnte man diesen "Bremsmodus" auch komplett deaktivieren, dann werden halt ggf. rote Signale überfahren (Das kann nur noch bei Bauarbeiten des Spielers passieren)
   
2. Durch die automatische Verringerung der Höchstgeschwindigkeit schwankt bei schnelleren Zügen die Geschwindigkeit nicht mehr zwischen 0 und max, sondern pendelt sich irgendwo in einem Bereich ein, der etwas höher/niedriger ist, als der Vorausfahrende Zug [je nach Signalabstand]
   
3. Die Berechnung der Kurvengeschwindigkeit hängt nicht mehr von der Zuglänge und von der Wagenlänge ab, sollte also etwas weniger obskure Nebenwirkungen haben.
   

Das hört sich grundsätzlich sehr gut an und war etwas das, was ich mir eingangs vorstellte.

Allerdings ist natürlich mit umfangreicheren Reservierung von Wegen sicher ein deutlich häufiger Speicherzugriff nötig, als bei der Verwendung von Signalen, weil deutlich mehr zu prüfen ist und auch mehr Felder beteiligt sind, als bei Signalen mit Streckenblockfunktion (bei "Magnetschwebebahnautobahnen" mit Mach 0,6 und Signale auf jedem Feld, was keine Kreuzung ist, macht das freilich keinen Unterschied).

Die Frage bei dem von dir vorgestellten Verhalten von Blocksignalen ist nur, wie man das Reservierungsrecht unter mehreren Zügen verteilt. Ein stehender Zug wird den Block u.U. sehr lange belegen, weil er vor der Einfahrt in den Block anfahren muss, sollte allerdings ein solch anfahrender Zug dafür sorgen, dass ein Zug, der sonst durchfahren könnte, auch erst anhalten muss, pflanzt sich das Problem natürlich fort. Andererseits würde ein zu starkes Vorrecht für durchfahrende Züge den Nebeneffekt haben, das Züge, die in die Strecke eingefädelt werden sollen, keine Chance haben, eine ausreichend große Lücke zu finden. [*] In der Regel sollten sich solche Phänomene aber nur bei stark ausgelasteten Strecken auftreten und ein Anzeichen für zu geringe Streckenkapazität sein.

Positiv, aber ein Luxusproblem, wäre es deshalb, wenn gleich schnell fahrende Züge ihren Abstand so wählen, dass entweder ein Zug dazwischen passt, oder wenn sie direkt bis an den Sicherheitsabstand auffahren würden, was allerdings eine umfangreichere Beeinflussung des Zuges erfordern würde.

* = Diese Probleme hat man natürlich in der Realität auch. Oft ist das kein so großes Problem, weil Strecken in der Regel von Knoten zu Knoten geführt werden, und in den Knoten (Bahnhöfen) ausreichend Kapazität zum Puffern besteht und u.U. auch bestimmte Variationen bei den Fahrstraßen in Ein- und Ausfahrt möglich sind.

(04.02.2013, 12:41)Eddi schrieb:

2. Züge sollten einen "Bremsweg" reservieren, der auf Basis der aktuellen Geschwindigkeit berechnet wird. Die Berechnung der Länge [in Feldern] sei hier mal offen gelassen.
   

Bildlich stelle ich mir das als wachsenden bzw. schrumpfenden Schatten vor, den ein Zug vor sich herschiebt.
Das finde ich in der Tat sehr elegant. Zumal dies weitere interessante Auswirkungen auf die Strategieentwicklung des Spielers haben könnte:

1. Schnelle Züge mit langem Bremsweg machen auf kurzen Strecken weniger Sinn als bislang.
   
2. Züge und Waggons könnten mit einem Bremskraftwert als neue Eigenschaft versehen werden. Bei stark ausgelasteten Strecken empfiehlt es ich natürlich auf Züge mit einem möglichst hohen Bremskraftwert zu setzen.
   

(04.02.2013, 13:53)pETe! schrieb: Allerdings ist natürlich mit umfangreicheren Reservierung von Wegen sicher ein deutlich häufiger Speicherzugriff nötig, als bei der Verwendung von Signalen, weil deutlich mehr zu prüfen ist und auch mehr Felder beteiligt sind, als bei Signalen mit Streckenblockfunktion (bei "Magnetschwebebahnautobahnen" mit Mach 0,6 und Signale auf jedem Feld, was keine Kreuzung ist, macht das freilich keinen Unterschied).

Aber die Züge werden doch bloß (fiktiv) länger. Korrigiert mich, aber hat das Auswirkungen auf den Speicherzugriff?

(04.02.2013, 13:53)pETe! schrieb: Die Frage bei dem von dir vorgestellten Verhalten von Blocksignalen ist nur, wie man das Reservierungsrecht unter mehreren Zügen verteilt. Ein stehender Zug wird den Block u.U. sehr lange belegen, (…)

Das Reservierungsrecht an Signalen bleibt wie es ist. Der Zug, der als erstes seine Bremswegreservierung in einen Block/Pfad schiebt, reserviert den Block. Der Zug, der als zweites seine Bremswegreservierung an das rote Block/Pfadsignal heran schiebt, kriegt den Block/Pfad als zweiter. Somit wird wie bisher eingefädelt.

Ich frage mich allerdings auch zwei Dinge:

1. Ist die Programmierung der Bremswegreservierung denn einfacher umzusetzen?
   
2. Kann man die Länge der Bremswegreservierung überhaupt gescheit auslooten, sodass man von einer befriedigenden Verbesserung zu Stop-and-Go-Fahrten sprechen kann?
   

(04.02.2013, 13:53)pETe! schrieb: Allerdings ist natürlich mit umfangreicheren Reservierung von Wegen sicher ein deutlich häufiger Speicherzugriff nötig

Das könnte ein Trugschluß sein, denn über die gesamte Bewegung eines Zuges gesehen ist die Anzal der erfolgten Reservierungen gleich, nur der Zeitpunkt verschiebt sich. Zur Zeit wird im Bereich von Blocksignalen alle Felder unter dem Zug reserviert, also pro Einfahrt in ein neues Feld eine Reservierung. Das wäre auch bei meinem Vorschlag so, nur daß diese Reservierung um den Bremsweg nach vorne verschoben wird (Hinzu kommt nur die Berechnung der Bremsweglänge und das Suchen des Endes der Reservierung)

Zitat:Ein stehender Zug wird den Block u.U. sehr lange belegen

Den Einwand verstehe ich nicht so richtig. Ein stehender Zug hat natürlich einen Bremsweg von 0, belegt also keinen Block außer den, wo er gerade steht. Und das Einfahren in eine dicht bepackte Strecke ist so oder so ein großes Problem, da müßte es auszuprobieren sein, ob das mit dieser Lösung besser oder schlechter funktioniert. (Stichwort: Prioritätssignale, Zyklotron, ...)