Also in der openttd.cfg ist es das:
wait_oneway_signal = 255
wait_twoway_signal = 255
wait_for_pbs_path = 255

denke ich mal.

Die Konsole öffnet man mit der Taste ^, allerdings finde ich den Konsole-Befehl nicht in der Wiki : http://wiki.openttd.org/Console

Eddi schrieb:Also ich baue immer nur Pfadsignale, auch auf freier Strecke, weil es einfacher ist, als ständig zu wechseln.

Ich hab´ ja schon öfter angemerkt dass ich der Meinung bin dass das OTTD Pfadsignalsystem zu wenig Signale vorsieht/erfordert. Nicht nur das dies mMn nicht vorbildgetreu ist, es hat auch Nachteile, wie zB hier beschrieben:

Johannes schrieb:Die von dir angesprochenen Signale habe ich dort hingestellt, damit der Weichenbereich schneller wieder für andere Züge freigegeben wird.

Gruß
Michael

Hab beides mal eingestellt. Funktioniert wunderbar.

Danke und Gruß
Johannes

(14.01.2010 13:36)Bernhard schrieb:  Also in der openttd.cfg ist es das:
wait_oneway_signal = 255
wait_twoway_signal = 255
wait_for_pbs_path = 255

denke ich mal.

Die Konsole öffnet man mit der Taste ^, allerdings finde ich den Konsole-Befehl nicht in der Wiki : http://wiki.openttd.org/Console

Danke für die Erinnerung

Es müßte set_lalala WERT sein.

(14.01.2010 13:59)mb schrieb:  [...] zu wenig Signale [...] nicht vorbildgetreu [...]

Bitte zeige mir einen halbwegs komplexen real existierenden Bahnhof, wo direkt hinter dem Weichenbereich ein Signal steht.

"Eddi schrieb:Bitte zeige mir einen halbwegs komplexen real existierenden Bahnhof, wo direkt hinter dem Weichenbereich ein Signal steht.

ZB ein Zwischensignal.

Das war aber gar nicht die Frage. Sondern dass es durchaus von spieltechnischer Relevanz sein kann den Streckenblock möglichst kurz zu halten, besonders da wir (im Spiel) weder zwischen Hp1 und Hp2 differenzieren können noch über andere Finessen verfügen (Zwischensignale, Zs3, Zs10, ..). Man muss das nicht tun, und man musste Blocksignale in TTD auch noch nie so aufstellen. Es ist i.a. aber sinnvoll, besonders in Bezug auf "presignals".

MaW: wenn eine Kreuzung nur wenige unabhängige Pfade zulässt sollte man sie möglichst kleinflächig ausführen. Es hat keinen Sinn den anschliessenden Weichenbereich zu weit auszudehnen.

Gruß
Michael

(14.01.2010 22:05)mb schrieb:  Das war aber gar nicht die Frage. Sondern dass es durchaus von spieltechnischer Relevanz sein kann den Streckenblock möglichst kurz zu halten, besonders da wir (im Spiel) [nicht] differenzieren können [...]

Dann hast du aber das falsche Argument vorgetragen. Wenn du eine spieltechnische Unzulänglichkeit darlegen willst, dann hat das nichts mit "vorbildgetreu" zu tun.

Zitat:Es ist i.a. aber sinnvoll, besonders in Bezug auf "presignals".

Presignals sind aber bei YAPP obsolet.

Zitat:Es hat keinen Sinn den anschliessenden Weichenbereich zu weit auszudehnen.

Doch, es hat einen Sinn, nämlich daß bei einer verstopften Strecke der Weichenbereich für entgegenkommende Fahrzeuge frei bleibt. Wenn man trotzdem in gleicher Richtung die Zugdichte erhalten will, wie mit dem umstrittenen Signal, dann kann man stattdessen die Ausfahrt für eine Zuglänge doppelgleisig gestalten.


Das eigentliche Problem bei der Vorbildtreue ist nämlich, daß im Vorbild der Signalabstand um ein vielfaches größer ist als die Zuglänge, weil nämlich das Spiel die Bremswege vernachlässigt. [in jeder Situation kommt ein Zug noch rechtzeitig vor einem Signal zum stehen.] Wenn das Spiel erzwingen würde, daß der Signalabstand [= Bremsweg bei höchstgeschwindigkeit] 3-8 mal der Zuglänge entspricht, dann würde diese Diskussion auch komplett anders verlaufen.

Eddi schrieb:

mb schrieb:Das war aber gar nicht die Frage. Sondern dass es durchaus von spieltechnischer Relevanz sein kann den Streckenblock möglichst kurz zu halten, besonders da wir (im Spiel) [nicht] differenzieren können [...]

Dann hast du aber das falsche Argument vorgetragen. Wenn du eine spieltechnische Unzulänglichkeit darlegen willst, dann hat das nichts mit "vorbildgetreu" zu tun.

Worauf ich hinauswollte war dass das YAPP-System anscheinend die Signalzahl minimiert bzw den Spieler dazu veranlasst, was weder vorbildgetreu noch in jedem Fall spieltechnisch von Vorteil ist. Johannes´ Beispiel habe ich lediglich als Beispiel genommen, insofern hängen beide Argumente durchaus zusammen.

Eddi schrieb:

mb schrieb:Es ist i.a. aber sinnvoll, besonders in Bezug auf "presignals".

Presignals sind aber bei YAPP obsolet.

Bei TTDPatch auch, trotzdem benutze ich sie und dies ist auch aus den o.e. Gründen sinnvoll.

Eddi schrieb:

mb schrieb:Es hat keinen Sinn den anschliessenden Weichenbereich zu weit auszudehnen.

Doch, es hat einen Sinn, nämlich daß bei einer verstopften Strecke der Weichenbereich für entgegenkommende Fahrzeuge frei bleibt. Wenn man trotzdem in gleicher Richtung die Zugdichte erhalten will, wie mit dem umstrittenen Signal, dann kann man stattdessen die Ausfahrt für eine Zuglänge doppelgleisig gestalten.

Bei der Verwendung von presignals bleibt der Weichenbereich frei und auch die Zugdichte wird maximiert, ganz ohne einen doppelgleisigen Ausbau, den man natürlich zusätzlich vornehmen kann wenn dafür Bedarf besteht.

Eddi schrieb:Das eigentliche Problem bei der Vorbildtreue ist nämlich, daß im Vorbild der Signalabstand um ein vielfaches größer ist als die Zuglänge, weil nämlich das Spiel die Bremswege vernachlässigt. [...] Wenn das Spiel erzwingen würde, daß der Signalabstand [= Bremsweg bei höchstgeschwindigkeit] 3-8 mal der Zuglänge entspricht, dann würde diese Diskussion auch komplett anders verlaufen.

Hier gebe ich dir 100% recht. Genau dies ist der Grund warum bei der grossen Bahn an solchen Stellen fast nie Signale stehen.

Gruß
Michael

Zitat:Eddi schrieb:
mb schrieb:
Es ist i.a. aber sinnvoll, besonders in Bezug auf "presignals".

Presignals sind aber bei YAPP obsolet.

Bei TTDPatch auch, trotzdem benutze ich sie und dies ist auch aus den o.e. Gründen sinnvoll.

In OTTD ergibt das aber nie einen Sinn. Das OTTD Pfadsignalsystem ersetzt problemlos das komplette Vor/Kombisignalsystem. Presignals und Pfadsignale zu koppeln ist dort nie sinnvoll.

Chrima schrieb:

mb schrieb:

Eddi schrieb:

mb schrieb:Es ist i.a. aber sinnvoll, besonders in Bezug auf "presignals".

Presignals sind aber bei YAPP obsolet.

Bei TTDPatch auch, trotzdem benutze ich sie und dies ist auch aus den o.e. Gründen sinnvoll.

In OTTD ergibt das aber nie einen Sinn. Das OTTD Pfadsignalsystem ersetzt problemlos das komplette Vor/Kombisignalsystem. Presignals und Pfadsignale zu koppeln ist dort nie sinnvoll.

Ich gebe zu das der thread mittlerweile an Umfang zugenommen hat.

Trotzdem. Dein Einwand wurde schon behandelt und es wurde mehrfach erklärt

- dass sowohl in OTTD als auch in TTDPatch "presignals" von PBS/YAPP ersetzt werden können bzw werden,
- warum es trotzdem sinnvoll sein kann zusätzliche Signale zu verwenden.

Ich weise einfach noch mal auf Johannes´ Aussage hin die ganz zu Anfang stand:

Johannes schrieb:Die von dir angesprochenen Signale habe ich dort hingestellt, damit der Weichenbereich schneller wieder für andere Züge freigegeben wird.

mb schrieb:[...] wenn eine Kreuzung nur wenige unabhängige Pfade zulässt sollte man sie möglichst kleinflächig ausführen. Es hat keinen Sinn den anschliessenden Weichenbereich zu weit auszudehnen.

Weil nämlich dadurch die Zugfolge verringert wird. Eddi schlägt dagegen zwar ein zusätzliches Gleis vor aber mit Zusatzsignal und zusätzlichem Gleis kann man die Zugfolge natürlich wiederum steigern.

PS: Ich habe mal dein quoting repariert.

Gruß
Michael

mb schrieb

Zitat:PS: Ich habe mal dein quoting repariert.

Danke

Eddis Variante ist in OTTD die bessere Lösung des Problems, weil es:
a) die Zugfolge verringert UND
b) der Weichenbereich nicht durch einen wartenden Zug blockiert wird.

Oder anders: Eddis Lösung ermöglicht nur den Zügen ein Einfahren in den Weichenbereich, die frühestens halten, wenn sie diesen Bereich komplett verlassen haben.

Das kann Johannes`Variante nicht.

(15.01.2010 13:02)Chrima schrieb:  mb schrieb

Zitat:PS: Ich habe mal dein quoting repariert.

Danke

Eddis Variante ist in OTTD die bessere Lösung des Problems, weil es:
a) die Zugfolge verringert UND
b) der Weichenbereich nicht durch einen wartenden Zug blockiert wird.

Oder anders: Eddis Lösung ermöglicht nur den Zügen ein Einfahren in den Weichenbereich, die frühestens halten, wenn sie diesen Bereich komplett verlassen haben.

Das kann Johannes' Variante nicht.

Das ist aber nicht das Einzig zu beachtende. Steht, wie in Johannes' Variante am Ausgang eines Weichenbereichs ein Signal und hinter diesem Signal ein wartender Zug, fährt im ungünstigsten Fall ein weiterer, aus dem Bahnhof ausfahrender Zug in den Weichenblock, womit der (mindestens teilweise) blockiert ist. Soweit wurde das schon konstatiert. Weder der weiter vorne wartende Zug, noch der im Weichenblock können weiterfahren, solange der Grund für den Stau nicht weggefallen ist. Das trifft aber genauso auf den Fall zu, dass das Signal auf der Ausfahrtsseite hinter dem Weichenblock fehlt.

Die Unterschiede im Verhalten sind folgende:

• Der Zug, der in Johannes' Fall den Weichenblock blockiert, wartet im Bahnhof und belegt dort ein Gleis.
• Ohne Stau ist die Frequenz der Abfahrten in eine Richtung niedriger, weil der Block auf der Ausfahrtsseite länger ist.
• Der Weichenblock bleibt (bis auf die ihn durchfahrenden Züge) immer frei.
  

Die bei Stau andauernde Belegung eines Gleises wäre nur durch die Vergrößerung des Bahnhofs zu umgehen (mehr Gleise/Bahnsteige). Mit, wie von Eddi vorgeschlagen, mehreren Ausfahrtsgleisen kann man die Ausfahrtsfrequenz im Bahnhofsbereich vergrößern. Tja, und der Weichenbereich bleibt immer noch frei.

@Johannes: Ja, es gibt auf offener Strecke keine Vorteile mit PBS. Es gibt aber auch keine Nachteile. Das Umkehren der Züge kann man mit den Einstellungen in der openttd.cfg verhindern, ein Durchfahren eines Streckenabschnitts in falscher Richtung verhindert man (auch auf offener Strecke) mit (einem) PBS-Einwegsignal(en), weil dort somit kein Pfad gefunden werden kann.

Tschö, Auge

... eine Frage die mich immer beschäftigt: brauchen YAPP / PBS-Signale mehr Rechenpower?

Eine sehr große Map, auf der nur PBS-Signale verbaut wurden, wird die eher lahm als eine, auf der lange Strecken mit normalen Signalen gebaut wurden?

Tendenziell wahrscheinlich ja, neue Feature brauchen in der Regel mehr Rechenzeit, aber mir ist kein vergleichbarer Test bekannt.

Wenn das Spiel zu langsam wird, kannst du das "path_backoff_penalty" [oder so änhlich] raufsetzen, dann versucht ein am Signal wartender Zug nicht so oft, erneut einen Pfad zu reservieren.

Aus neueren Versionen sind mir da auch keine Probleme bekannt (unter Rev 3464 gab es arge Probleme, aber das ist ja Steinzeit ).

Ja, der Unterschied ist, daß die alte Implementierung auf NPF aufbaute, was etwa um den Faktor 10 langsamer ist... deshalb wurde ja auch YAPF angefangen, was krasserweise sogar schneller war als der alte Pfadfinder (NTP von Ludde, nicht der originale TTD-Pfadfinder, wo sich die Züge bei jeder kleinen Ecke verfahren haben)

(16.01.2010 11:33)Bernhard schrieb:  ... eine Frage die mich immer beschäftigt: brauchen YAPP / PBS-Signale mehr Rechenpower?

Das hängt ganz von der Situation ab, da es verschiedene gegenläufige Effekte gibt. In einem typischen Spiel dürfte sich das auf etwa den gleichen Rechenbedarf wie ohne YAPP einpendeln.

Beim einfachsten Fall (keine Abzweigung zwischen zwei Signalen) ist YAPP grundsätzlich langsamer, aber nur so viel, wie es braucht, um die Reserviert-Bits zu setzen (was sehr wenig ist). Da wird man sich schwer tun, die Verlangsamung auch nur zu messen, geschweige denn auch zu spüren.

Sobald zwischen zwei Signalen mehrere Abzweigungen sind, ist YAPP sogar effizienter. Ohne einen reservierten Pfad muss nämlich an jeder Abzweigung der Pfad neu berechnet werden, mit Pfad nur einmal bei Eintritt in den Signalblock. (Ein Pathfinder-Aufruf ist um Größenordnungen teurer als das Setzen von ein paar Bits.)

In einer Situation ist YAPP allerdings langsamer, und zwar wenn ein Zug auf einen freien Pfad wartet. An einem normalen Signal wartet der Zug einfach, bis das Signal grün wird, an einem Pfadsignal wird regelmäßig aktiv nach einem Pfad gesucht. Spürbar wird das aber erst, wenn im Spiel sehr viele Züge gleichzeitig auf einen Pfad warten.

Signalproblematik:

Egal wie man auch die gleise setzen will... oder signale... aber... Hey leute... es kann doch wohl nicht so schwer sein bei der Programmierung der Züge, dass der zug allgemein, sobald er an eine kreuzung kommt, dass wenn er an de reine einfahrt ein rotes signal vorfindet, (Weil sich ein zug dahinter befindet) dass er sich dann eine andere einfahrt sucht, wo da signal grün ist, und dort dann rein fährt.

also einfach ausgedrückt: kreuzung: alle wege mit signalen, alle signale auf rot. weil ein zug dahinter. signal auf rot, sollte eigentlich bedeuten: "hier kann ich nicht reinfahren", was macht zug? zug fährt trotzdem los, und fährt bis ans rote signal und steht dann mitten auf der kreuzung.

wenn zug aber an eine kreuzung kommt, sollte er nicht in die kreuzung einfahren, wenn dort alle signale auf rot stehen, er sollte warten, bis er auf der anderen seite der kreuzng ein grünes signal vorfindet. oder?

Hallo

• Setze die Signale hinter der Kreuzung so weit weg, dass der Zug die Kreuzung nicht versperrt.
• Benutze Einfahrsignale vor der Kreuzung.
  

signalproblematik2:

das ganze pfade berechnen nützt nix wenn die züge sich nicht nach den signalen richten:

einfache kreuzung: von osten nach westen von norden nach süden:

Von norden: 1. signal auf dem linken gleis auf der linken seite, bedeutet einfahrt. 1. signal auf dem rechten gleis auf der rechten seite bedeutet ausfahrt, und das so im uhrzeigersin rundherum, bis alle 4 himmelsrichtungen versorgt sind.

Also bleiben wir mal bei norden: zug kommt an die kreuzung: alle signale stehen auf rot, weil im moment auch alle ausfahrten belegt sind. was macht zug? fährt trotzdem auf die kreuzung, obwohl, keine einzige ausfahrt frei ist.

"ja klar" heist es jetzt dafür gibt es doch die einfahrt und ausfahrtssignale...

nützt aber wenig, wenn die trotdem nicht auf grün schalten, und das obwohl die kreuzung frei ist...