Beiträge von StefanDD

Discord Einladung
Trete unserem Discord-Server bei (klicke hier zum Beitreten).

    Gude Stefan, kleine korrektur das befreien ist erst nach 700m möglich, damit ist die Restlauflänge der ÜF 550m, in diesen ist ein befreien möglich (die 1000Hz ÜF läuft 1250m ab Beeinflussung). Das Startprogramm stellt ebenfalls den Zustand dar 700m der ÜF abgelaufen und läuft damit dann auch für 550m. Sollte es innerhalb dieser 550m (der noch im Hintergrund weiterlaufenden 1000hz ÜF) zu einer erneuten 1000hz Beeinflussung kommen und man hat sich Befreit wird direkt auf die im Leuchtmelder dargestellte Geschwindigkeit überwacht (85,70 oder 55km/h).

    Hallo Sebastian - hast absolut Recht; habe die 700m und die 550m in meinem Beitrag komplett vertauscht!

    zunächst ergänzend zum Thementitel: bitte messt auch die TTB-Umsetzung der PZB an den hier angelegten Maßstäben :S

    Hallo Benjamin,


    ich habe seinerzeit genau das gleiche gemacht -- mir vor 10 Jahren externe Leuchtmelder in einem mit Lua+EGSL gebastelten Fake-TS angeschaut und per Button Beeinflussungen erzeugt und per Zustandsdatei-Auslesen auf der TS Seite synchron in den TS geholt. Ich freue mich auch aufgrund Deines Blogs zum Simulator annehmen zu koennen, dass Eure PZB eine Zustandsmaschine ist und keine endlose empirische Kette von IFs fuer alle "gekannten" Situationen wie die meisten Addons.


    Mir fiel allerdings in Deinen Abbildungen der ueberwachten Geschwindigkeit (orange v_ueberachg?) auf, dass die nichtlinear ueber der Zeit abfaellt. Das waere aber m.M. nach nicht richtig - die linear abfallende v_pruef(t) ergibt ja eine parabolische v_pruef(s) (s Weg), aber nicht als v_pruef(t) Plot (die Abbildung "Überlagerungsfälle: Ein Blick unter die Haube").

    innerhalb dieser 1200m darf man dann nicht über 85 KM/h fahren.

    Fast!. Wenn man sich innerhalb der 700m restliche UF-Lauflaenge der 1000Hz befreit (nach Ablauf von 550m moeglich), kann man so schnell fahren wie man will. Allerdings stimmt es, dass bei erneuter 1000Hz Beeinflussung innerhalb dieser 700m dann sofort die Zugartabhaengige Kurvenendgeschwindigkeit geprueft wird -- ja, bei Zugart O sind das 85km/h (bei U nur 55km/h). Das liegt daran dass die im Hintergrund noch laufende 1000Hz reaktiviert wird - die ist aber nach 550m schon auf 85kmh abgefallen. Sie wird reaktiviert und um weitere 1250m verlaengert. Aber Du koenntest auf 100 km/h beschleunigen solange Du am Signal wieder bei 85km/h bist -- ratsam ist das nicht, aber es knallt nicht!


    Die allerwenigsten Payware-Addons simulieren Ueberlagerungen -- vR aber ab der BR101 koennen Ueberlagerungen von UF1000/1000R mit neuer UF1000 und UF500 und alle Seiteneffekte (Dunkelblinken des 1000Hz LM etc.) Die muss wohl ein Experte geschrieben haben ;)

    Es war bis Anfang der 2000er tatsächlich so daß, im vom BR_141 geschilderten Fall, eine Zwangsbremsung erfolgte.

    Das war eine der frühen PZB Versionen. Der alte Text der Vorschrift 483.0101 sagte dazu.......

    Das war bei keiner PZB Version mit der man sich befreien konnte je der Fall. In 483.0101 heisst es daher auch, dass man eine ZWB erhaelt,

    " wenn Sie

    ...

    sich unzulässig aus einer 1000 Hz - ÜF befreit

    haben und sich innerhalb einer bestimmten

    Wegstrecke eine 500 Hz-Beeinflussung anschließt"

    Eine weitere 1000Hz Beeinflussung innerhalb von 700m nach FT fuehrte und fuehrt immer nur zur Neuaktivierung der 1000Hz UF. Eine ZWB am 1000Hz ist dann einfach ein Bug!

    Nachdem in diesem Thread eher kritische, sicher berechtigte, Stimmen zu den Unzulaenglichkeiten der Lokumsetzung gab, will ich mal was sehr positives sagen. Ich war baff, dass hier, anders als bei der BR 41 und 50.35 die PZB Lampen tatsaechlich als farbige Lichtquellen, also rote, blaue Lampen hinter halbtransparenten Texturen umgesetzt sind, also mit den Call("..:SetColour") Befehlen beschaltet werden. Das ist sehr selten im TS, extra Detailliebe, und sehr schoen wie ich finde.


    Zu den fehlenden Halterungsstreben der Windleitbleche -- man kann ja im Engine .bin auch Child-Geometrien ausser der Hauptgeometrie hinzufuegen. Ich glaub so hatte SeKu die PZB in die Kuju V200 bekommen (dort Cab Geometrie, nicht Lok-Geometrie), aber es sollte mit dem gleichen Ansatz doch moeglich sein, die Streben als Child-Geometrie nachzuladen. Hat hier jemand die Faehigkeit das per Blender nachzuruesten?

    SeKu Du hattest ja schon fast mehr eingebaut als in den meisten Payware PZBs drin ist. Kompliment! Ich bin bei den Zusi-systemen ein bisschen Perfektionist und habe ueber Jahre an der PZB gearbeitet bis sie den offiziellen DB Zulassungstest bestanden hat. Es gab ja soviele widerspruechliche RILs -- schau mal hier: https://fahrweg.dbnetze.com/re…ur-Stellungnahme-data.pdf


    Was bei meiner PZB noch dazukaeme waere (verglichen mit Deiner Liste auf Seite 1):

    - Befehlsmodus inkl Ueberlagerung durch existierende UFs (die meisten Loks pruefen nur 40km/h obwohl wie wenn ueberhaupt auf 45km/h pruefen muessten :-)).

    - es koennen beliebig viele UF1000 laufen die sich echt ueberlagern (niedrigste Vpruef wird geprueft) inkl. des Dunkelblinkens des 1000Hz-LM bei Ueberlagerung innerhalb 700m

    - Restriktivwerden der UF500 macht auch alle laufenden UF1000 restriktiv

    - Stoer-ueberwachung bei Rueckwaertsfahrt und HLL-Druck unter 3bar

    - bei FSt-Wechsel bleiben alle UFs des verlassenen Fueherstands erhalten (werden gespeichert) bis im anderen Fuehrerstand das Startprogramm anspringt (5km/h) wonach sie geloescht werden

    - Entlassung aus ZWB unterhalb 30km/h mit Stillstandszwang innerhalb 15s sonst erneute ZWB

    - kann leicht als I60, I60R oder PZB90 konfiguriert werden


    Sag einfach irgendwann per DM Bescheid wie das laufen sollte wenn dann noch gewuenscht... Ich will diese ehemals kommerziellen Module jetzt einfach in Freewareloks einbauen wenn und wann moeglich...

    Finde den Fehler:



    (Fahrt im FSt2)


    Die Herren und Damen Beta-Tester sind entweder nie im FSt2 gefahren oder nie im FSt1 mit Rischa in R rueckwaerts gefahren. Beide Situation ergeben obiges Bild




    Railtraction There are 2 bugs of the same origin still in v1.1

    As shown on the picture above, the traction display is wrong both when driving with reverser [R] in cab 1 or driving with reverser in [V] in cab 2 (the latter is shown in the picture). The reason is that you use Call("GetTractiveEffort") and "VirtTractiveEffort" for the calculation of the little arrow and the blue ribbon. However, the sign of Call("GetTractiveEffort") depends on both the reverser and the driving cab. So it only looks correct when driving in cab 1 forward or backwards in cab 2.

    I fixed it temporarily for myself by intercepting "GetTractiveEffort" and "VirtTractiveEffort" and multiplying both with local multiplier = Reverser * (1 - 2 * cabcampos), and you could probably employ a similar fix.


    EDIT: according to RT these are not significant bugs, so I adjusted the text to just "bugs".

    Bummelzug konntest Du das Problem je loesen?


    Ich habe exakt das gleiche Problem und die PlayerProfiles.bin zu loeschen oder als .xml per Hand zu editieren bringt nichts; installierte Dateien verifizieren bringt nichts.


    Es ist, als ob TS nicht mehr willens ist, in den Vollbildmodus zu schalten. Nutze ich "-SafeMode" in der Steam Kommandozeile, bekomme ich ein 1024 x 768 Fenster. Sobald ich aber ohne "-SafeMode" starte, egal welche Kombination aus Vollbild, Rahmenlos, Fenster und Aufloesung ich benutze: alles wird in ein zentriertes 1024x768 Rechteck geclippt (so dass bei allen Aufloesungen groesser als 1024x768 ein Grossteil der UI fehlt)


    Hat irgendjemand dieses Problem je loesen koennen?

    Railtraction I believe the blue version of the [55] PZB light is not properly "wired" in the Cabin GeoPcDx. The transform entry exists but instead of showing a blue [55] it shows the [B40] for me when it tries to display the blue [55],


    EDIT: sorry, nevermind; I missed the post that mentions that.

    Lt. Handbuch kann die Lok wohl alle 3, aber die Angabe in der Readme zum Wechseln der Zugart stimmt scheinbar nicht. Notier ich mir für morgen und schau ebenfalls mal im input mapper rein.

    Vielen Dank! Falls auf Zugart M geschaltet werden kann, bitte mal schauen, ob es das gelbe Textbanner fuer Ueberwachung von 35 km/h gibt. (braucht man fuer 500 Hz Beeinflussungen in Zugart M) . Ich baue mir in solche Loks gerne meine PZB/LZB ein, aber bin dann sehr enttaeuscht wenn die Lokbauer wie RT und RSSLo nur Textbanner fuer 25, 45, 55, 70, 85 km/h einbauen und 35 km/h vergessen! Das Banner fuer 40km/h (Befehl) vergessen alle!
    Ich will mir die Lok nur kaufen, wenn es wenigstens das 35km/h Textbanner gibt (PZB ist mir wichtig)

    StefanDD

    RSSLO wird das hier nicht lesen, darum lieber auf Englisch direkt anschreiben.

    Hab ich gemacht. Ich verstehe das wirklich nicht -- haben die Azubis, die die Loks machen? Die haben doch schonmal gewusst, dass man auch ein 35km/h PZB-Textfeld braucht und dann einfach hier keins gemacht. Und dann Jahre "entwickelt" und "Beta-Testern" vorgelegt. Und keiner faehrt eine Schwerlastlok mal in Zugart M??? Wahrscheinlich einfach nach dem Motto: "Hebel vor, bewegt sich, passt! 20 Euro bitte!"

    Mich ärgert, dass in der unteren Zugart in der PZB bei 500Hz Kurven das Textbanner fuer 35km/h fehlt. Das wurde schonmal bei den BR 147, 187, 245, 285 korrekt mitgeliefert -- warum fehlt es hier nun wieder?