(11.12.2011 17:39)Eddi schrieb:  ...aber "Alle 2 Felder ein Signal" sollte man sich vielleicht zweimal überlegen.

Dann wird es aber echt mal Zeit für eine Integration von LZB! Denn gerade auf stark oder beseonders schnell befahrenen Strecken hilft die "alle zwei (oder drei) Felder ein Signal"-Strategie ungemein, den Verkehr flüssig zu halten! Ich möchte das als simulierte LZB zumindest nicht missen!

(11.12.2011 23:02)Sven schrieb:  

(11.12.2011 17:39)Eddi schrieb:  ...aber "Alle 2 Felder ein Signal" sollte man sich vielleicht zweimal überlegen.

Dann wird es aber echt mal Zeit für eine Integration von LZB! Denn gerade auf stark oder beseonders schnell befahrenen Strecken hilft die "alle zwei (oder drei) Felder ein Signal"-Strategie ungemein, den Verkehr flüssig zu halten! Ich möchte das als simulierte LZB zumindest nicht missen!

Bei LZB fahren die Züge in Bremswegabstand. Das würde, übertragen auf OpenTTD bedeuten, dass Züge auch einen realistischen Bremsweg bräuchten.
Zusätzlich wäre es mit deiner LZS-Simuliererei auch vorbei, wenn Züge entweder nur so schnell fahren würden, dass sie vor dem nächsten Signal noch anhalten können, oder nur so schnell fahren, wie sie Signalblöcke reservieren konnten.

Das was man mit extrem kurzen Signalabständen (kürzer als Zuglänge) nämlich simulierst, ist eher Fahrt auf Sicht, wie sie bei der Straßenbahn üblich ist, da ist die Geschwindigkeit dann auf 70 km/h begrenzt. MIt LZB hättest du dann sicher einen Sicherheitsabstand vor deinem Zug, der die Zuglänge deutlich, wenn nicht sogar um ein Vielfaches übersteigt. Sicher, dass du das willst?

(11.12.2011 23:02)Sven schrieb:  Hallo

(11.12.2011 17:39)Eddi schrieb:  ...aber "Alle 2 Felder ein Signal" sollte man sich vielleicht zweimal überlegen.

Dann wird es aber echt mal Zeit für eine Integration von LZB! Denn gerade auf stark oder beseonders schnell befahrenen Strecken hilft die "alle zwei (oder drei) Felder ein Signal"-Strategie ungemein, den Verkehr flüssig zu halten! Ich möchte das als simulierte LZB zumindest nicht missen!

Spieltechnisch ist das kein mMn Problem. Dieses Spielverhalten wird ja meist bei Hochgeschwindigkeitsstrecken eingesetzt (oder sollte es jetzt zumindest). Dort sind aber auch höhere Umsätze und somit Gewinne möglich. Das gleicht sich so ein wenig aus. Der Profit fällt mit aktivierten Infrastrukturkosten halt ein wenig niedriger aus als ohne/vorher. Wenn man (bisher) solche Strecken bauen konnte, war Geld sowieso nicht mehr das Problem.

@Eddi: Klar, bei Kreuzungsfeldern, die in alle Richtungen Gleise enthalten, steigen die Infrastrukturkosten unmittelbar. Darauf muss man sich als Spieler einstellen. Allerdings steigen die Kosten pro Gleis/Straße/wasauchimmer ja auch mit der absoluten Anzahl von Gleis-, Straßen- wasauchimmer-Feldern. Es ist somit auch ein Unterschied, ob ich stumpf pro Richtung eine sechsgleisige Strecke mit einer ausufernden Kleeblattkreuzung in die Landschaft zimmere oder nur die wirklich notwendige Infrastruktur errichte und diese so weit als möglich optimiere.

Tschö, Auge

(12.12.2011 00:45)pETe! schrieb:  

(11.12.2011 23:02)Sven schrieb:  

(11.12.2011 17:39)Eddi schrieb:  ...aber "Alle 2 Felder ein Signal" sollte man sich vielleicht zweimal überlegen.

Dann wird es aber echt mal Zeit für eine Integration von LZB! Denn gerade auf stark oder beseonders schnell befahrenen Strecken hilft die "alle zwei (oder drei) Felder ein Signal"-Strategie ungemein, den Verkehr flüssig zu halten! Ich möchte das als simulierte LZB zumindest nicht missen!

Bei LZB fahren die Züge in Bremswegabstand. Das würde, übertragen auf OpenTTD bedeuten, dass Züge auch einen realistischen Bremsweg bräuchten.
Zusätzlich wäre es mit deiner LZS-Simuliererei auch vorbei, wenn Züge entweder nur so schnell fahren würden, dass sie vor dem nächsten Signal noch anhalten können, oder nur so schnell fahren, wie sie Signalblöcke reservieren konnten.

Das was man mit extrem kurzen Signalabständen (kürzer als Zuglänge) nämlich simulierst, ist eher Fahrt auf Sicht, wie sie bei der Straßenbahn üblich ist, da ist die Geschwindigkeit dann auf 70 km/h begrenzt. MIt LZB hättest du dann sicher einen Sicherheitsabstand vor deinem Zug, der die Zuglänge deutlich, wenn nicht sogar um ein Vielfaches übersteigt. Sicher, dass du das willst?

Nein, das stimmt nicht. Auch die LZB ist eine Technik zum Fahren im festen Raumabstand, nur dass die Blöcke in Form von Signalmasten nicht direkt sichtbar sind.
Zudem sind die Blöcke sehr klein, meines Wissens 500 Meter. bei der Hochleistungs-LZB der Münchner S-Bahn noch kleiner. Die LZB ist also nur eine Führerstandssignalisierung, also eine Art wie ich den Lokführer einen Signalbegriff übertrage.
LZB läße sich relativ simpel in OpenTTD integrieren. Man müsste nur ein SIgnalset aus unsichtbaren Signalen erschaffen.
Schwierig wirds wenn man auch eine Rückkopplung auf die Fahrzeuge haben möchte. Denn es gibt auch Fahrzeuge, die keine LZB-Ausrüstung haben. Diese müssen sich weiter an ortsfeste Signale orientieren.

Quelle: http://books.google.de/books?id=Wrh4YI_K...ZB&f=false

Interessant, was alles "simpel integrierbar" ist... Ich warte auf den Patch von Dir.

Warum Patch, das geht doch über Newgrf? Ich habe leider keine Ahnung wie man Newgrf bearbeiet. Wenn ich die hätte würde ich mir wohl die German Signals-grf nehmen und die Grafiken der Flügelsignale gegen eine leere Grafik tauschen, denn die LZB sieht man ja nicht. Sollte das austauchen einer Grafik sehr schwierig sein, nehme ich das natürlich zurück.

Natürlich kannst du relativ einfach die Signalgrafiken durch unsichtbare Grafiken ersetzen, aber das hat
1. nicht wirklich was mit dem realen LZB zu tun und
2. wünsche ich dir schon jetzt viel Spass, ein falsch gesetztes Signal zu suchen.

(12.12.2011 13:27)Addi schrieb:  Natürlich kannst du relativ einfach die Signalgrafiken durch unsichtbare Grafiken ersetzen, aber das hat
1. nicht wirklich was mit dem realen LZB zu tun und
2. wünsche ich dir schon jetzt viel Spass, ein falsch gesetztes Signal zu suchen.

zu 1.) warum nicht? Die LZB hat auch Blöcke, es sind halt nur nicht physikalisch sichtbare Signale vorhanden, sondern virtuelle. Damit diese der Lokführer "sehen" kann, werden sie auf die Anzeige im Führerstand abgebildet. Wenn jemand der Meinung ist es wäre anders dann bitte mit Quellen hinterlegen.

2.) Wie soll man ein im Gleis verlaufenes Kabel schon visulaisieren? Ich würde mir da mit Schildern behelfen "LZB Anfang" und "LZB Ende".

Man könnte ja "Eurobalisen" zeigen, aber dafür hat man keine Bounding Box, das wird also auch wieder kompliziert.

Ich hatte das was Logital da vorschlägt auch schon öfter angedacht.
Man muss ja die Signale nicht gegen "nichts" austauschen ... vlt. Kilometerseine oder so was?
Und falsch gesetzte Signale muss man nicht laneg suchen, denn selbstverständlich setzt man zu Beginn eines LZB-Abschnittes ein "normales" Signal, und am Ende auch.
Weichenstraßen usw. sollte man natürlich ausnehmen!

Alos Logital, welches Signalset pimpen wir?

Naja, ich habe nur die Funktionsweise der deutschen LZB gelernt. Daher würde ich das deutsche Signalset nehmen, glaube german Signals heißt das.

Man könnte ja als Stütze so einen kleinen gelben Kasten neben das Gleis legen, der sollte aber wirklich nur 1x1 Pixel groß sein. Einen Mindestblockabstand von 3 Feldern würde ich dennoch nicht unterschreiten, aber das kann ja jeder selbst einstellen.

Meine Aussage bezieht sich auf die einzige mir bekannte Signallose Zugsicherung ETCS, wo mindest ab Level 3 keine klassischen Blöcke mehr existieren.
Nichtsdestotrotz bringt das ersetzen der Signalgrafik durch unsichtbare Signale keine "echte Besserung" gegenüber dem Status Quo (gerade auch in Hinsicht auf YAIM, worum es ja in diesem Thread geht), die funktionsweise und Anzahl benötigter Signale bleibt exakt gleich.

Ein grf kann man natürlich trotzdem erstellen, nur nützt es mMn. nicht wirklich was...

(12.12.2011 13:33)Logital schrieb:  

(12.12.2011 13:27)Addi schrieb:  Natürlich kannst du relativ einfach die Signalgrafiken durch unsichtbare Grafiken ersetzen, aber das hat
1. nicht wirklich was mit dem realen LZB zu tun und
2. wünsche ich dir schon jetzt viel Spass, ein falsch gesetztes Signal zu suchen.

zu 1.) warum nicht? Die LZB hat auch Blöcke, es sind halt nur nicht physikalisch sichtbare Signale vorhanden, sondern virtuelle. Damit diese der Lokführer "sehen" kann, werden sie auf die Anzeige im Führerstand abgebildet. Wenn jemand der Meinung ist es wäre anders dann bitte mit Quellen hinterlegen.

Bei Wikipedia steht dazu beispielsweise "Die LZB ermöglicht die Unterteilung der Strecke in eine größere Zahl kleinräumigerer Blöcke. Damit kann die Leistungsfähigkeit einer Strecke gesteigert werden. Bei hinreichend kleiner Blocklänge ist praktisch ein Fahren im absoluten Bremswegabstand möglich".
Wenn die LZB-Teilblöcke natürlich so groß sind, wie die herkömmlichen Signalblöcke, kann man die Leistungsfähigkeit nicht steigern, sondern lediglich Fahrten zulassen, die einen Bremsweg haben, der länger ist, als der (Vor-)Signalabstand, sowie das Aufstellen der Lichtsignale einsparen. Dieses Verfahren ist für Hochgeschwindigkeitsstrecken interessant.

(12.12.2011 14:03)Logital schrieb:  Man könnte ja als Stütze so einen kleinen gelben Kasten neben das Gleis legen, der sollte aber wirklich nur 1x1 Pixel groß sein. Einen Mindestblockabstand von 3 Feldern würde ich dennoch nicht unterschreiten, aber das kann ja jeder selbst einstellen.

Wie gesagt, das nennt sich "Fahren auf Sicht". In einem Abstand, der kürzer als eine durchschnittliche Zuglänge ist, bei Höchstgeschwindigkeit hinter anderen Zug herzufahren, wirst du auch bei LZB nicht können.

(12.12.2011 15:19)Addi schrieb:  Nichtsdestotrotz bringt das ersetzen der Signalgrafik durch unsichtbare Signale keine "echte Besserung" gegenüber dem Status Quo (gerade auch in Hinsicht auf YAIM, worum es ja in diesem Thread geht), die funktionsweise und Anzahl benötigter Signale bleibt exakt gleich.

Ein grf kann man natürlich trotzdem erstellen, nur nützt es mMn. nicht wirklich was...

Man muss halt nicht nur die Grafiken ersetzten sondern eben auch die Kosten manipulieren.
Die Frage ist (hiermit an die Devss gerichtet): Kosten unterschiedliche Signale unterschiedlich viel?
Dann wäre es ja einfach

(12.12.2011 16:09)Bernhard schrieb:  Die Frage ist (hiermit an die Devss gerichtet): Kosten unterschiedliche Signale unterschiedlich viel?

Das meine ich nicht.

Allgemein: Es gibt noch genau einen freien Signaltyp im Maparray, alles weitere (beispielsweise zwei wegen LZB Anfang und LZB Ende) benötigt mindestens eine kleinere Auseinandersetzung mit der Implementierung des Maparray, um dafür Platz zu schaffen, vielleicht sogar deutlich ausführlicher als einem 'mal eben so lieb sein kann, da die Anzahl freier Bits rar sind.

Zusätzlich: SignalGRAFIKEN können zwar via (New)GRF ersetzt werden, SignalFUNKTIONEN können via NewGRF natürlich NICHT implementiert werden und brauchen mehr oder minder umfangreiche Änderungen im Code der Pathfinder selbst.

Den notwendigen Arbeitsaufwand schätze ich auf ähnlich groß wie denjenigen ein, der uns PBS brachte Zur Erinnerung: das brauchte ca. 1 Jahr, michi wird's besser wissen

Korrektur: es gibt zwei freie Signaltypen (hab ich das nich letztens schonmal korrigiert?) (insgesamt 8, bisher 6 in Benuzung)

Oh weh, was hab' ich da wieder losgetreten...

(12.12.2011 15:57)pETe! schrieb:  Wie gesagt, das nennt sich "Fahren auf Sicht". In einem Abstand, der kürzer als eine durchschnittliche Zuglänge ist, bei Höchstgeschwindigkeit hinter anderen Zug herzufahren, wirst du auch bei LZB nicht können.

Nein, natürlich nicht. Der Abstand zwischen den Zügen wird abhängig von der Geschwindigkeit und den Daten des Zuges berechnet und kann bei Vmax bis zu mehreren Kilometern betragen. (Hab' jetzt leider keine konkreten Werte zur Hand.)
Meine Formulierung war insofern sicher ein wenig unglücklich, dass die kurzen Blöcke in TT nur den einen Teil der LZB simulieren, nämlich das nahe Heranfahren an den vorher fahrenden Zug (was aber beim Vorbild nur unter bestimmten Bedingungen möglich ist). Diese Bedingungen werden in TT natürlich nicht korrekt abgebildet.

Die Idee einer Signalgrafik in Form eines gelben Kabelverteilers (oder anders) finde ich gut.

Grüße, Sven

Pete schrieb:

"Wenn die LZB-Teilblöcke natürlich so groß sind, wie die herkömmlichen Signalblöcke, kann man die Leistungsfähigkeit nicht steigern, sondern lediglich Fahrten zulassen, die einen Bremsweg haben, der länger ist, als der (Vor-)Signalabstand, sowie das Aufstellen der Lichtsignale einsparen. Dieses Verfahren ist für Hochgeschwindigkeitsstrecken interessant."

Die LZB wurde zuallererst deswegen eingeführt, weil es ab 160 km/h (1.) nicht mehr möglich ist innerhalb des Vorsignalabstandes (1000 bis 1300 Meter) bis zum Stillstand zu bremsen und (2.) die Erkennbarkeit eines Signals bei solchen Geschwindigkeiten schwierig wird.

Die Leistungsfähigkeit ist eine andere Geschichte, hier ist LZB natürlich auch vorteilhaft, siehe Münchner S-Bahn im Stammstreckentunnel, aber das kam erst viel später. Auf den meisten Hochgeschwindigkeitsstrecken mit LZB ist weniger los als auf einigen Hauptbahnen ohne LZB. Wenn es vorranig um die Leistungsfähigkeit gehen würde hätte die Rheinschiene als erstes mit LZB ausgreüstet werden müssen.

Kann mal jemand den LZB-Kram in ein neues Thema splitten?

(12.12.2011 20:29)Logital schrieb:  Die LZB wurde zuallererst deswegen eingeführt, weil es ab 160 km/h (1.) nicht mehr möglich ist innerhalb des Vorsignalabstandes (1000 bis 1300 Meter) bis zum Stillstand zu bremsen und (2.) die Erkennbarkeit eines Signals bei solchen Geschwindigkeiten schwierig wird.

Richtig. Und mindestens innerhalb dieses Abstandes darf sich ein Zug befinden, um ein Zugsicherung zu gewährleisten. Die 500m, von denen du geschrieben hast, sind somit nicht passend. Eine LZB wird bei OpenTTD höchsten durch "alle 10 Felder ein Signal" simuliert, kürzere Abstände sind unpassend.