Zusi-Forum

Salut, das habe ich auch festgestellt und bislang immer so verstanden, dass der Buchfahrplan in deinem Beispiel die Sekunde 30 als "halbe Minute = 0,5" interpretiert, während das Ebula die tatsächliche Anzahl an Sekunden, also 30 als Komma-Zahl = ",3" anzeigt. Oder wird beim Buchfahrplan einfach auf halbe und ganze Minuten gerundet?

Wie sieht es denn bei Sekunde 45 aus: die dreiviertel Minute im Buchfahrplan = ",75" bzw. beim Ebula = ",45"?

Vielleicht weiß jemand im Team Süd, ob die Druckfahrpläne in der S-Bahn München damals überhaupt Sekunden hatten. Die Ebula-Vorgabe ist jedenfalls "10 Sekunden genau".

PS: Die Mehrzeiler-Geschichte ist etwas komplizierter, aber habe ich aufgenommen. Ich denke, ihr habt aber nichts dagegen, wenn ich mir es spare, zu jeder Meldung Empfangsbestätigungen zu posten.

Zur Mg noch eine Info: Die DB hatte wohl 11.12.2011 auf R/P umgestellt, zuvor hatte sie schon R+Mg zu Mg abgekürzt. Irgendwann noch weiter vorher hatte sie R+Mg aber schon mal ausgeschrieben. Ich habe mir den Punkt notiert.

Zu meiner Zeit hatten wir gedruckte Buchfahrpläne, die immer zum Fahrplanwechsel auf allen Fahrzeugen getauscht werden mussten. Da gab's keine kleinere Einheit als Minuten. Ich habe gestern beim Googlen ein Pamphlet gefunden, wo stand, die Anzeige ist in 1/10 Sekunden. Finde ich gerade aber nicht mehr. Dann wäre die Anzeige in ZusiDisplay richtig.

Habs wieder gefunden: Bei der Trassenanmeldung auf Seite 4 im Feld 13 sprechen sie von Zehntel-Minuten -> https://fahrweg.dbnetze.com/resource/bl ... 3-data.pdf" target="_blank

Michael Springer hat geschrieben:Da gab's keine kleinere Einheit als Minuten.

Dann schalte ich die Sekundenanzeige wohl per Default aus, oder?

Momentan mache ich bei Komma Bruchteile und bei : Sekunden. Im Ebula ist es laut 408.2341 "10 Sekunden genau"

Ich muss mal ganz ganz doll Danke rufen für den Buchfahrplan Ersteller.

Da ich ganz wild drauf bin, Wendezüge zu basteln und mir die timetable xml regelmäßig kaputt geht (keine Zeiten, jede zweite Zeile getauschte Kilometrierung...),
hat mir der Ersteller wirklich sehr geholfen das zu berichtigen.

Nicht auszudenken, wieviel Lebenszeit für das manuelle korrigieren draufgegangen wäre.
Gut, es hat schon seeeehr lange gedauert, rauszufinden dass der Laufweg mein Hauptproblem war.

Liebsten Dank!

Danke.

Ich bin jetzt dabei, die ganzen Change Requests umzusetzen und dann hoffe ich, dass ich danach so allmählich Richtung Veröffentlichung steuern kann. Aber ich möchte den Dank auch weiter geben an alle, die bei solchen Beta-Programmen mitmachen und mich und andere tatkräftig mit Hinweisen und Verbesserungsvorschlägen oder mit Meldungen, welche Dinge sie derzeit von Hand machen, unterstützen.

So.

Neu in Version 3.0.9.19:
* DLL 2006: Man kann wahlweise die Modi "R, P, G, Mg, WB", "R/P, G, WB" und das klassische "R+Mg, ..." einstellen. Obwohl R/P erst zum 11.12.2011 eingeführt wurde, habe ich es weiterhin als Standard für die DLL 2006 eingestellt, sonnst hätte ich eine DLL 2012 basteln müssen.
* DLL 2006: Die Gegengleiseinträge von Blocksignalen werden nun Standardmäßig in mehreren Zeilen angezeigt.
* Neu: Die Gegengleis-Einträge werden bei GWB dennoch eingetragen. Die Erkennung läuft so ab, dass ein Esig-Eintrag im Gegengleis vorhanden seien muss. So weit ich gesehen habe lief es zuverlässig, aber ich kann nicht ausschließen, dass es noch Fehler dort gibt.
* Neu: Bei Bildschirmskalierungen über 100% werden eine andere Standardschriftgröße eingestellt. Bei Skalierungen über 200% und vorhandener Bahnschrift wird die Bahnschrift als Standard verwendet. Für die meisten Nutzer wird das kein Einfluss haben, sofern sie Zusi nicht von Hand auf High-DPI gestellt haben.
* Neu: Andere Klammern für das Gegengleis
* Change: Kein Oberstrom im Gegengleis
* Neu: Verhaltensweise von LZB-Bks hinzugefügt und an Sbk angepasst

Download:
https://pkeus.de/~philipp/Zusi/3/Zusatz ... 0.9.19.zip" target="_blank


Ich würde darum bitten, dass ihr da noch mal drüber schaut. Ich fürchte, ich werde langsam Betriebsblind, und gerade das High-DPI habe ich auch nur rudimentär testen können. Wenn keine oder nur noch nicht-gravierende Bugs auftauchen, würde ich dann noch mal mit Carsten und Jens Rücksprache halten, mit der DLL demnächst die bisherigen DLLs zu ersetzen.

Ich weiß auch, dass es bei manchen Strecken in seltenen Fällen zu Nacharbeiten bei der Kilometrierung insbesondere im Gegengleis kommen wird und möchte mich schon mal bei den Autoren für die nötigen Nacharbeiten bedanken.

Die Klammer hängt bei Herbertshofen und BkSig FF200 ganz schön nah. Und beim Yen scheinen die Abstände nicht symetrisch zu sein. Also das die rechte Klammer mehr in den Buchstaben hängt



Michael

Wenn ein Zug in einem Tunnel beginnt, scheint die Tunnellinie keinen Anfang zu kennen



Was bedeuten eigentlich die -4 ?

Wenn Windows bei der Berechnung der Font Mist baut, ist jeder Versuch dagegen zu arbeiten mit größeren Schmerzen verbunden. Ich habe es aber jetzt mal trotzdem gemacht:

https://pkeus.de/~philipp/Zusi/3/Zusatz ... 0.9.20.zip

* Fix: Bei Start im Regelgleis wurde das Gegengleis nicht Initialisiert
* Change: Tunnel-Anfang wird bei horizontalen Linien zurückgesetzt
* Neu: Workaround-Modus für die Kombination Ziffern oder ¥ + Klammer

Edit: Nachtrag: Wie befürchtet:



Edit2: Vorerst behoben: https://pkeus.de/~philipp/Zusi/3/Zusatz ... 0.9.21.zip" target="_blank

Wunsch zum Aussehen des Outputs: Im Moment macht er die Spalten nur exakt so breit wie er sie gerade braucht. Dadurch wirkt alles sehr gedrängt. Es wäre schöner, wenn er z.B. die Fahrzeitspalten grundsätzlich so breit machen würde, dass auch noch ein Pluszeichen für Betriebshalt da rein passen würde, selbst wenn er es gar nicht braucht. Die Kilometrierungsspalten grundsätzlich so breit dass mindestens auch Hunderter-Kilometer reinpassen würden; Geschwindigkeitsspalten so breit dass in spitzen Klammern stehende 100er Geschwindigkeiten passen. Für die Breite der Spalte 3a gibt es übrigens beim Vorbild eine offizielle Spezifikation: 22 Zeichen breit (16 Zeichen für Namen von Betriebsstellen, plus 6 Zeichen für Sägelinien/Tunnel/E60 etc.).

Neu in 3.0.9.23:
* Hilfsgrößenberechnung geht nun auch von einem Rahmen aus und von +00:00 anstatt 00:00. Zeichenanzahl für 3a ist bereits auf 16 Zeichen.

https://pkeus.de/~philipp/Zusi/3/Zusatz ... 0.9.23.zip" target="_blank

Der Kilometersprung sollte nicht in spitzen Klammern stehen, auch wenn er aus dem Gegengleis kommt:


timetable.xml: http://www.echoray.de/devel/zusi3/ME82001.timetable.xml" target="_blank

Mein Part ist jetzt noch, rauszufinden warum Zusi den Sprung überhaupt generiert. Der ist nämlich nicht gewollt. Können Lauflängendifferenzen Regel/Gegengleis Kilometersprünge verursachen? Weil die Ausfahrsignale Nörten-Hardenberg nämlich versetzt zueinander stehen, und auffälligerweise genau dort dieser seltsame Sprung auftaucht.

Am Esig hast ja nur eine Laufwegverschiebung von ca. 32cm daher glaube ich das eher nicht.

Der Sprung ist ja 155m vor dem Yen. Kann es sein das da z.B. in der Weichenstraße oder so ungünstige Kilometrierungen an 2 Streckenvektoren aufeinanderstoßen? Nachtrag: Ein Sprung wird erzeugt, wenn mehr als 80m zu überbrücken sind. Vorher wird er von Zusi nicht erzeugt.

Michael

Können Lauflängendifferenzen Regel/Gegengleis Kilometersprünge verursachen? Weil die Ausfahrsignale Nörten-Hardenberg nämlich versetzt zueinander stehen, und auffälligerweise genau dort dieser seltsame Sprung auftaucht.

Es könnte schon sein, da es von P001 keinen Fahrweg ins Gegengleis gibt. Und er den Abstand als Kilometrierungswechsel ausgibt. Wie sieht es den aus, wenn du zum Test einen Bfpl generierst, wenn der Zug über P002 fährt (also P002 in der .trn Datei) ?

Alwin Meschede hat geschrieben:

Zwei Nebenfragen: Wenn ich den Beitrag richtig in Erinnerung habe, gibt es die Bahnschrift ja bisher sowieso nur für High-DPI, aber ist Absicht, dass die Darstellung komplett ohne Anti-Aliasing (weder ClearType noch Graustufen) erfolgt? Wenn ich Alwins Screenshot auf 50 % verkleinere, sieht das Ergebnis eigentlich auch nicht komplett unbrauchbar aus, und wenn die Schriftdarstellung von vorneherein auf die jeweils konkrete Auflösung mit ClearType und ggf. Hinting ausgelegt wäre, wäre vermutlich noch ein bisschen was an Lesbarkeit rauszuholen.

Zweites subtiles Problem: Leider hat die Bahnschrift offenbar nur proportionalbreite Ziffern an Bord, und gerade bei den Kilometerangaben, insbesondere in der Spalte 3b, fällt das dann doch etwas auf (z.B. 106,1 und 105,4). Leider liefert Bahnschrift wie gesagt offenbar keine Tabellenziffern mit, sodass eine Lösung dafür wohl etwas komplizierte werden könnte…

Und wo speichert deine DLL eigentlich ihre Einstellungen?

Edit: Nachtrag - die Antialiasing-Frage gilt wohl eigentlich generell -Zusis aktuelle Buchfährpläne nutzen nämlich ClearType.

Ich weiß, dass das Arbeit ist, aber ich würde euch gerne bitten, die Fehler mit dem km-Sprung im Gegengleis in der .timetable.xml zu beheben, indem die Fehler in der st3 oder in Zusi korrigiert werden, ich würde da nur sehr ungerne Klimmzüge veranstalten. Tut mir Leid, dass ich das euch aufbürde.

Die Klammern waren eine bewusste Abweichung, um die Nachfragen und das Verwirrungspotential während der Übergangszeit zu verringern. Wenn die Korrekturen flächendeckend durch gelaufen sind, kann ich das ändern, aber ich habe den Verdacht, dass es stark verwirrt, wenn ich sie jetzt gleich entferne. Alternativ könnte ich sie durch eine Fußnote ersetzen.

Der TextRenderingHint ist schon Projektiert, aber ich war bislang zu Faul, für ihn eine Graphische Oberfläche zu basteln, das reiche ich nach. Aber um es kurz zu machen: In meinen Augen würden ich ihn nicht verwenden. Ich finde es sieht nicht so gut aus wie ohne und es gibt ein paar Zeichen, die sich da irgendwie nicht dran halten wollen, und die fallen dann sofort auf.

Die Bahnschrift wird dadurch in meinen Augen auch nur besser. Es fehlt für eine gute Lesbarkeit einfach die Breite. Aber ich kann es ja mal zur Verfügung stellen, vielleicht hat ja jemand Lust noch zu spielen.

Die Einstellungen finden sich unter HKEY_CURRENT_USER\\Software\\Zusi3\\lib\\timetable\\Buchfahrplan2\\*

die Fehler mit dem km-Sprung im Gegengleis in der .timetable.xml zu beheben, und zwar indem die Fehler in der st3 oder in Zusi korrigiert werden

Meine Meinung: Das wird an vielen Stellen nicht möglich sein. Auch wenn es Dir nicht gefällt. In manchen Fällen muss sie unemfindlicher werden. Kein Mensch kann die Strecken so bauen, das Signale auf cm genau nebeneinander stehen. Einige Fälle sind klare Baufehler, die gehören korrigiert, aber es gibt andere Stellen wo das einfach nicht geht.

Der z. B., weil der im echten Plan auch so drin ist.


Michael

Kann es sein, dass die DLL von Jens Haupert Kilometersprünge im Gegengleis grundsätzlich ignoriert? Weil sie druckt den Sprung in Nörten-Hardenberg jedenfalls nicht an. Könnte das eine sinnvolle Strategie sein? Weil wirklich gewollte Kilometersprünge würden ja auch immer im Regelgleis auftauchen.

Ja, das klingt recht sinnvoll.

Carsten