Beiträge: 7.540
Themen: 251
Registriert seit: Apr 2013
Bewertung:
27
15-11-2013, Friday-03:11:21
Es war so im Programm, aber führt zu dauernd geschlossenen Schranken, speziell bei KI-Strecken, die bevorzugt Bahnübergange machte.
Beiträge: 54
Themen: 4
Registriert seit: Jul 2010
Bewertung:
0
15-11-2013, Friday-18:39:38
Hallo,
also das ist auch ne gute Idee. Zwar hat man dann wieder eine globale Regelung die für alle Strecken gilt, aber es würde glaube ich schon Vielen, die jetzt Probleme mit verstopften Bahnübergängen haben, sehr weiterhelfen.
Ich denke ein realistischer Wunsch ist das allemal.
Viele Grüße
Beiträge: 7.540
Themen: 251
Registriert seit: Apr 2013
Bewertung:
27
15-11-2013, Friday-18:59:32
So einfach konfigureirbar ist das nicht, sonst waere es schon drinnen. Das zieht schon einen ganzen Schwanz an Aenderungen nach sich, da ein Signal zum Beispiel nur auf Gruen schalten koennte, wenn der Bahnuebergang frei ist. Daher muesste der Signalcode sch anders verhalten.
Beiträge: 54
Themen: 4
Registriert seit: Jul 2010
Bewertung:
0
17-11-2013, Sunday-20:33:08
Hallo,
wieso ist dafür eine so große Änderung notwendig? Ich dachte der Mechanismus funktioniert jetzt schon so, dass einfach vier Felder vor dem Bahnübergang die Schließung eingeleitet wird. Wo wäre das Problem, wenn man nun einfach selbst definieren kann, wie viele Felder vorher der Bahnübergang schließne soll. Der Mechanismus bleibt ja derselbe. Oder war deine Aussage an meinen Beitrag gerichtet?
Viele Grüße
Beiträge: 7.540
Themen: 251
Registriert seit: Apr 2013
Bewertung:
27
18-11-2013, Monday-00:45:52
Die Aussage vier Felder gilt für alle Signale (auch Bahnübergänge). Etliche Routine sind darauf ausgelegt, dass Fahrezuge vier Felder vorher abbremsen.
Komplizierte Signale nur damit die Bahnübergänge später schließen, halte ich für keine gute Idee. Im übrigen sind Bahnübergänge etwas, was sehr gründlich Multithreading erschwert.