Hallo Jan,
danke für Deine Meinung, auf die ich wie folgt antworten möchte:
Jan Eisold hat geschrieben:Tagchen,
M Boden hat geschrieben:[...] Dein Lösungsvorschlag ist sicher praktikabel, hört sich allerdings nicht sehr flexibel an. Es scheint mir etwas schwierig zu sein, mal eben einen Zug operativ eine andere Strecke bei vollständiger Zugsicherung fahren zu lassen. Vielleicht, weil ich eine Störung (fabriziert) habe, weil gebaut werden soll oder weil vielleicht einfach nur die Lokführer mal wieder streiken
[...]
Ein solcher Ansatz geht allerdings über den eigentlichen "Sinn" von BAHN deutlich hinaus: Derzeit wird im Wesentlichen ein Betriebsablauf unter normalen Bedingungen, also wie er im Regelfall ablaufen würde, dargestellt. Das künstliche Einbauen von großen Störungen, die während der Simulation dispositve Entscheidungen erfordern, ist da eine völlig andere Qualität. Wer schonmal mit einem professionellen Simulationstool gearbeitet hast, in dem solche Dinge explizit vorgesehen sind, der kann sich ungefähr vorstellen, wie weit BAHN davon noch entfernt ist und welchen Eingabeaufwand sowas bedeuten würde. Jede mögliche Dispositionsentscheidung muss man der Simulation nämlich vorher irgendwie beibringen, in dem man die entsprechenden Bedingungen und Restriktionen eingibt. Ganz einfaches Beispiel: Wenn ein Zug über eine andere Strecke umgeleitet werden soll, wäre es nett, wenn er irgendwann auch an sein eigentliches Ziel kommt und nicht planlos umherfährt. Für ein halbwegs komplexes Eisenbahnnetz sind das unzählige Informationen. Und dafür müssten ersteinmal Standards geschaffen werden.
So komplex hatte ich mir das gar nicht vorgestellt.
Wenn ich in meinem Beispiel oben aber den Knoten Coswig bei laufenden Betrieb umbauen will und daher alle Züge von Leckwitz über die neue Spange nach Böhla umleiten möchte, kostet mich das nach meinem Vorschlag ein paar Vorbereitungen an vielleicht 5 Weichen, damit die Zuge wieder ankommen, wo sie sollen. Ich muß nicht unzähliche Signale und Signalanlagen umwidmen, damit alle auf der Strecke fahrenden Züge auch auf diese reagieren. Mit den derzeitigen Optionen reagieren auf ein Signal entweder alle Züge oder nur bestimmte Linien. Dabei sind Signale in Wirklichkeit doch strecken- und nicht liniengebunden.
Im Übrigen fährt ein Zug auch jetzt schon im Nebel rum, wenn ich meine Einstellungen an Weichen o.ä. nicht sauber gemacht habe. Insbesondere dann, wenn ein Zug zeitgebunden zum Einrücker gemacht wird, wegen einer Störung aber nicht an dem eigentlich vorgesehenen Ort ist. Da rückt bei mir eine Strab 8 schonmal über Hauptbahnhof nach Trachenberge ein
Deine Bedenken mit dem Umgang der Funktion bzw. dem Antlitz einer Programmiersprache teile ich grundsätzlich auch. Allerdings wächst der Mensch ja bekanntlich mit seinen Aufgaben. Zudem halte ich eine Fahrwegbeschreibung nach dem Muster : FS109;H591;W134,1;W132,2;H590 (Fahrstraße109, Start Signal H591; Weiche 134 Richtung1; Weiche 132 Richtung2; Ende Signal H590) letzlich für deutlich übersichtlicher, als die manchmal mit Zeiten und Linien zusammengewürfelten Bedingungsketten, die man in Taktpunkten oder Weichen oder sonstetwas eintagen kann.[...]Wenn ich hier im Forum surfe, stelle ich fest, dass unwahrscheinlich viele User sich (auch) mit Eisenbahn beschäftigen. Gerade für diejenigen wäre die Fahrstraßengeschichte sicher eine tolle Sache. Und ich bin überzeugt, dass dies neue Nutzer erschließen würde und vielleicht auch Ehemalige zurück holen dürfte.
Wenn man sowas einführt, dann müsste es so einfach zu handhaben sein, dass quasi alle Eingaben automatisch erzeugt werden und man nur noch den jeweiligen Zügen/Linien/Zugtypen/... ihre Fahrwege/Fahrstraßen zuweisen braucht. Wenn man aber alles selber eingeben muss, wird das insbesondere die Nutzer, die schon vom "neuen" Signalsystem in BAHN 3.84 abgeschreckt wurden, nicht überzeugen.
Eben! Wenn ich mir überlege, wieviele Signalanlagen man manchmal in den Signaldialogfeldern eintragen muss, auf die das Signal reagieren soll oder die es ein- oder ausschalten soll, wundert es mich nicht, dass es viele abschreckt. Das ganze ist manchmal so kryptisch, dass selbst erfahrene BAHNer micht mehr genau wissen, was sie tun. Man sieht ja nicht unbedingt auf den ersten Blick, welche Signalanlage man jetzt für genau welche Funktion vorgesehen hat.
Ich hatte mir das aber eben als eine Art Zusatzfunktion vorgestellt, die optional verwendet werden kann, aber nicht muss.
Das umzusetzen klingt immer so schön einfach, aber frag mal einen Programmierer...
Das alte System muss auch schon aus Gründen der Kompatibilität zunächst irgendwie erhalten bleiben.
Na ja, ein bissel programmieren kann ich auch
Natürlich soll das alte System erhalten bleiben. Für einfache Blockstrecken oder eben den Stab-Betrieb ist es unverzichtbar.
Aus meiner Sicht wäre zum Beispiel folgender Ansatz denkbar: Hauptsignale können wahlweise mit dem jetzigen Signalsystem oder als Fahrstraßensignale funktionieren. Letztere würden so funktionieren, dass Züge sich an definierten Punkten (möglichst weit genug vor dem Vorsignal) ihre jeweilige Fahrstraße anfordern. Diese Anforderungen werden am Signal gespeichert. Wenn möglich, d.h. die Fahrstraße ist in ganzer Länge frei und nicht in Teilen bereits durch einen anderen Zug reserviert, wird diese Fahrstraße reserviert (so, wie jetzt an Kreuzungen auch Fahrwege reserviert werden können). Eine Fahrstraße reicht dabei stets von einem Hauptsignal zu einem anderen Hauptsignal oder auch zu einem anderen Zielelement (beispielsweise Gleisabschlüsse oder spezielle Elemente, die es derzeit noch nicht gibt). Für diese Fahrstraßen müsste es eine automatische Suchfunktion geben, die man bei Änderungen stets durchlaufan lassen müsste (in einem großen Netz könnte das u.U. Stunden dauern). Denkbar wäre ggf. auch ein spezieller Editor, bei dem man die Fahrstraßen z.B. mit der Maus eingibt (Startsignal, Weichen, Zielsignal, Auflösepunkte). Aber auch den müsste erstmal einer schreiben...
Das deckt sich fast vollständig mit meiner Idee.
Was die Suchfunktion betrifft, weiß ich ehrlich gesagt aber nicht, wozu die dienen soll. Einen Editor halte ich auch nicht für unbedingt nötig. Ob ich jetzt in einem Signal 20 Signalanlagen oder später in einem Fahrstraßendialog 10 Fahrwegelemente eintragen muss, macht nicht wirklich einen Unterschied.
Für alle möglichen Sonderfälle (z.B. Vereinigen von Zugflügeln, Wenden im Gleis etc.) bräuchte man trotzdem noch spezielle Lösungen. Mit viel Programmieraufwand könnte man so ein System schaffen, welches halbwegs handhabbar ist und die wesentlichen Grundfunktionen der in Deutschland üblichen Eisenbahnsicherungstechnik darstellen kann. Das wäre sicher nicht ganz schlecht, aber eben doch nur eine Krücke, wenn man BAHN nicht zu einer wirklichen Stellwerkssimulation erweitern möchte.
Nun, hier könnte die Abwärtskompatibilität mit dem bestehenden System durchaus gute Dienste leisten. Wenn Rangierfahrten vom Signal ausgenommen werden könnten, könnten diese so arbeiten, wie bisher. Auch die Rangierfahrt kann schon jetzt nicht in einen reservierten Abschnitt einfahren, gleichwohl kann kein Zug (respektive Fahrstraße) in einen von einer Rangierfahrt reservierten Bereich eindringen.
Es geht auch weniger um die Sicherungstechnik bei der Eisenbahn, eher um deren Logik. Daher brauchts auch keine Stellwerkssimulation, weil es ja nicht unbedingt sein muss, dass man bei jeder Zugfahrt in Echtzeit die Signale selbst stellt.
Aber bevor man solche Dinge wie Fahrstraßen vorsieht, müssten aus meiner Sicht erstmal andere Defizite gelöst werden. Wir haben in BAHN beispielsweise immer noch nur eine rudimentäre, um nicht zu sagen eigentlich gar keine richtige Fahrdynamik. Solange es an solchen elementaren Dingen hapert, brauchen wir eigentlich nicht über Erweiterungen reden, die darauf aufbauen müssten.
Das sehe ich etwas anders. BAHN hat doch eigentlich eine völlig andere Intuition. Wer sich eine virtuelle Modellbahn bauen will, ist bei der Konkurrenz sicher besser aufgehoben. Da wird man aber kaum ganz Ostsachsen reinkriegen. ohne das der PC das rauchen anfängt. Man sollte die optische Detailtreue nicht zum Maß der Dinge machen. Dafür ist BAHN, glaube ich, nicht erfunden worden. Ich bin der Meinung, es dient der Simulation der Funktion eines Netztes und nicht dessen Aussehen.
Ausserdem hat man die Fahrdynamik mit Langsamfahrstellen und Vorsignalen für den eigentlichen Zweck des Programms recht gut im Griff...
MfG Jan
Ich danke Dir für Deine Antwort und deine Gedanken.
Viele liebe Grüße aus BaWü in meine (leider viel zu weit entfernte) alte Heimat
Matthias
