Also im Quickdrive von Gesundbrunnen -> Leipzig Hbf kann man das von Euch im VS Szenario auftretende Problem leider NICHT nachstellen. Ich bin bis zum 26-0 Hektometerstein gefahren (also schon an Ludwigsfelde vorbei), LZB-gefuehrt mit 180km/h und ohne ZWB und erst recht nicht mit PZB Leuchtmeldern aktiv waehrend der LZB Fuehrung.
@Berliner079
Koenntest Du bitte testen, ob der Quickdrive die exakt gleiche Strecke entlang fuehrt und im Szenario nicht evtl. eine "branch line" benutzt wird?
Ludmilla-Fan:
Kann man diesen Teil der Strecke auch im "Quickdrive"-Modus abfahren? Wenn ja, welchen Start-Endpunkt muss ich waehlen, um im QD dort vorbeizufahren, so dass man das Ergebnis ausserhalb des VS Szenarios testen kann (hab' ich nicht).
Kann evtl. jemand im Streckeneditor schauen, was da los ist?
Da ist irgendetwas faul - evtl. mit dem Szenario? Die Leuchtmelder zeigen sowohl PZB als auch LZB im Vordergrund. Im LZB-Betrieb sollte doch der [85] Leuchtmelder gar nicht leuchten, dafuer aber der U-Leuchtmelder? Wie sieht es im freien Spiel an der gleichen Stelle aus?
Richtige Entscheidung!
Zitat: "Habe ich erwähnt weil seine Blogeinträge mir geholfen zu verstehen wie die .dll funktioniert."
...und weil Du seinen Raildriver.cs von besagter github Seite als Basis fuer Deine eigene Erweiterung benutzt hast (inkl. 1:1-Kopie bei den enums und der Art wie man die externen dll-Funktionen zulinkt). Ich bin mir sicher, dass Du viel Arbeit in TSConductor gesteckt hast und steckst, aber trotzdem: wie die Amerikaner so schoen sagen: give credit where credit is due! Was fuer ein Zacken fiele Dir denn aus der Krone zu schreiben, "basiered auf Ideen von RDIp oder so aehnlich?"
Ich tue mich schwer mit den folgenden Formulierungen (von der TSConductor Webseite):
License Copyright © ... - All Rights Reserved
sowie der Tatsache, dass sich der Autor massiv bei frueheren quelloffenen Projekten informiert hat, diese aber fuer meinen Geschmack viel zu wenig wuerdigt. Die gesamte Mechanik der Kommunikation mit raildriver.dll wurde aber im letzten Jahr von anderen Leuten erarbeitet, inklusive Details zu internen Kontrollvariablen wie Zugposition etc. TSConductor ist ein netter aufgebohrter C# Wrapper um diese fruehren Projekte, aber es gibt fuer Leute, die lieber gemeinsam und freizuegig mit freien Tools arbeiten, auch weniger "proprietäre und geheime" Alternativen mit publiziertem Quellcode, z.B.
Rob Mitchelmore (wird immerhin in den Acknowledgements erwaehnt, ohne zu sagen, dass all das auf seinen Ideen basiert, bis hin zur Realisierung eines Servers in C#!)
Blog Eintrag zu RDIp
C# Quellcode zu RDIp und RDIp-server
wer lieber Python mag, kann zu py-raildriver greifen -- ein entsprechender Server ist in python mit 20-50 mehr Zeilen geschrieben...
PY-Raildriver mit Quellcode
Klingt fuer mich nicht nach zufaelligem Bug, sondern vergessenem Nullstellungszwang. Wenn ich Leistung aufschalten will bevor der Bremszylinderdruck wieder auf 0 bar gefallen ist, wird keine Leistung aufgeschaltet. Hat man also versehentlich nach der Befreiung aus der ZWB den Leistungsschalter schon wieder vorverlegt, passiert garnix, auch wenn dann die Bremse komplett geloest ist. Man muss nach dem vollstaendigen Loesen der Bremse den Leistungsschalter nochmal nach 0 verlegen, bevor man dan Leistung zuschalten kann.
Ich habe kein Problem damit, dass jemand Details herausstellt die ihm gefallen, selbst wenn die Mehrheit das nicht so sieht. Ein Testbericht kann doch überhaupt nicht wirklich objektiv sein -- vielleicht wollen ja manche lieber einen kritischen Videobericht, aber was ist so verwerflich daran, dass jemand enthusiastisch über Dinge ist, die er vielleicht aus der eigenen Modelliererfahrung kennt oder aus Gott weis was für Gruenden gut findet. Was ist denn falsch daran wenn ein Ex-Mitarbeiter einer Firma von deren neuem Produkt begeistert ist? Warum muss all diese Galle verspritzt werden und ihm in vermeintlicher Detektivarbeit eine unlautere Absicht bewiesen werden? Wer sich seine Meinung so schnell und scharf über den Macher eines Testvideos und seine Intentionen bilden kann ist, kann sich doch sicher genauso treffend seine eigene Meinung über die gezeigte Strecke bilden -- damit hat doch das Video seinen Zweck erfuellt, oder 
Mal was anderes -- macht die Strecke zum PZB-Fahren Spass? Ich brauche fuer die Fahrillusion nicht unbedingt HD-Vegetation oder Haus-einfahrten, sondern herausfordernde Situationen (daher mag ich auch Run8, obwohl das keine Oberleitungen hat :-).
Ja! Aber erst ab 166 km/h bekommst du eine PZB Zwangsbremsung.
Stimmt auch nicht ganz. Bei den Betriebszwangsbremsungen geht es erst ab 4km/h ueber der Vmax los -- bei O also 169km/h. Das ist in der neuen Lok korrekt simuliert: bei v > 165 km/h faengt [G] an zu blinken und ein Warnton ertoent, die Zwangsbremsung (auf unter 165, nicht bis zum Stillstand) erfolgt bei 169 km/h.
@Moe2k
waere fantastisch! Denn die RIL Regel widerspricht hier evtl., so wie formuliert, der Realitaet, aber wenn ich kein Video habe, habe ich nur die Regeln. Ich werde diese Auslegung schonmal als Option in die PZB einpflegen -- solltest Du, @flusi737 oder irgendjemand ein Video auftreiben koennen, welches entweder: Startprogramm->FT->1000Hz oder UF1000 restriktiv->FT->1000Hz zeigt (sollte ja auf das gleiche herauslaufen). Jedes Video wie https://www.youtube.com/watch?v=G2B0wM0xdRg welches die Leuchtmelder in verschiedenen Signalablaeufen (je komplizierter desto besser) zeigt, ist Gold wert. Die PZB setzt die RIL korrekt um und das ist ja im TS schon viel wert, aber Feinheiten wie diese sind leider bis zum Videobeweis auslegbar (weil schlecht formuliert). Vielen Dank schonmal!
@flusi737. Das wuerde unheimlich helfen. Denn dann stimmen die schriftlichen Regeln fuer die PZB der DB nicht, aber ich koennte die Simulation an die Realitaet anpassen. Die Anpassung waere extrem einfach -- aber wenn, dann bitte zuegig helfen!!!!
Zitat: "Und es geht auch nicht nur ums Startprogramm, es passiert bei der vR 101 immer wenn ich mich aus der Restriktiven befreie un danach eine erneute 1000er bekomme. In der realität kann ich mich 5m vor der erneuten Beeinflussung befreien und habe dann trotzdem kein 1000er + Wechselblinken." Genau -- denn ich wende die Regel 483.0113-4(9) konsequent an. Das Startprogramm ist ja nur eine 1000R von der 700m abgefahren sind. Wenn Du Recht hast, gibt es einen gravierenden Fehler in der RIL, naemlich zu sagen, dass restriktive 1000 UFs beim Befreien und verlagern in den Hintergrund ihren restriktiven Status verlieren!!! Bei erneuter 1000Hz Beeinflussung wuerden sie als normale 1000 UFs reaktiviert, und da sie zwangslaeufig aelter als 23 Sekunden sind, waere dann in der Tat die VPruef 85kn/h. Das steht nirgendwo geschrieben, entspraeche aber eben evtl. der Realitaet...
zum Thema Update(s): Die BR101 ist ein vielerlei Hinsicht neues, revolutionaeres Produkt und, anders als die Einheitsloks, viel weniger Weiterentwicklung von aelteren Loks. Ich mutmasse mal, dass ein Update wahrscheinlich ist.
Beim zulässigen Befreien aus dem Startprogramm der PZB (Vzul >30 km/h) und anschließender 1000Hz Beeinflussung (ich vermute innerhalb der insgesamt 550m des Startprogramms), fällt die PZB fälschlicherweise in den Restriktiven Modus + 1000 Hz Überwachung zurück. Bei v 45 km/h erfolgt dann auch die Zwangsbremsung. Wird der 1000 Hz Magnet mit 45km/h und mehr (z.B. 60) befahren, erfolgt die Zwangsbremsung direkt. Dies entspricht nicht dem Vorbild...
@Moe2k -- Die RIL 483, z.B. 483.0113, sagt zum Thema Befreien aus ueberlagerten UFs: "Nach einer Befreiung aus einer restriktiven oder nicht restriktiven 1000 Hz-Überwachungsfunktion ist diese nicht mehr wirksam, läuft aber über eine Wegstrecke von 1250 m seit der 1000 Hz-Beeinflussung im Hintergrund weiter. - Erfolgt in diesem Bereich eine erneute 1000 Hz-Beeinflussung, so wird die unwirksam geschaltete Überwachungsfunktion sofort wieder wirksam." Dies ist die im Moment implementierte Variante. Die im Hintergrund laufende UF ist die restriktive 1000R vom Startprogramm, und gemaess dieser Regel macht die PZB im Moment alles richtig. Allerdings zeigt sich der schlechte Schreibstil der RILs im naechsten Satz: "Dies bedeutet, dass eine Zwangsbremsung erfolgt, wenn die Geschwindigkeit beim Befahren eines 1000 Hz-GM größer ist als die mit blauem LM angezeigte Geschwindigkeit." Diese nachgestellte Interpretation der vorangegangenen Regel waere die fuer die Variante verdeckt laufende 1000 UF nach Befreiung (die ist ja nach 23s bei 85km/h in Zugart O) konsistent mit den ersten beiden allgemeinen Saetzen der Regel, widerspricht aber diesen ersten beiden Saetzen im Falle einer 1000R UF, die eben nicht 85km/h sondern 45 km/h ueberwacht.
Weil die RIL sprachlich und didaktisch so schlecht abgefasst ist, gibt es leider in den Zusi, Loksim, usw. Foren hitzige Debatten mit 100en Eintraegen ueber z.B. dieses (u.ae.) Themen und man kann auch Zusi oder Loksim nicht zum Massstab nehmen, denn die arbeiten leider auch mit dem gleichen trueben Wasser :-). Wer ein weiteres Beispiel fuer die schlechte Formulierung in den RILs braucht, schaue sich z.B. die Abschnitte zum PZB Befehl an. Dort steht: "Der blaue LM des eingestellten Überwachungsprogramms
zeigt Dauerlicht (Bild 42)." Das ist aber nur ein BEISPIEL und nicht als immer gueltige Regel zu nehmen und widerspricht Bildtafel 47. Genauso sehe ich es mit dem 3. Satz oben "Dies bedeutet, dass eine Zwangsbremsung erfolgt,..." -- ein willkuerliches Beispiel fuer die 2 allgemeinen Regeln fuer 1000UF nach FT und neue 1000Hz.
Leider gibt es auf Youtube nur wenige Mitfahrten, die auf die PZB schauen, und ich habe auch nach langem Suchen keine gefunden, die den Startvorgang UND eine rechtzeitig erfolgende 1000Hz Beeinflussung zeigen wuerde. Und an Forumpostern mit vermeintlicher "Ich bin Tf, und ich weis das"-Kompentenz gibt es leider auch auf beiden Seiten der Interpretation welche
Dennoch funktioniert die PZB einwandfrei und eine Verschlechterung des gekauften Produktes empfinde ich als Frechheit.
....Außerdem kommt ja bald Prellis Werk und dann entwickelt sich der TS wieder ein Stück weiter.
Ich glaube wir sollten die Emotionen ein bisschen herausnehmen (niemand hat etwas Freches vor). Du hast das glaube ich komplett missverstanden. Ich fasse alles nochmal so knapp wie moeglich zusammen.
- Die neue PZB kennt wie Zusi 3 oder das reale Vorbild beliebig viele gleichzeitig ablaufende UFs
- Die GPAs auf Mosel bringen das Skript aber durcheinander weil innerhalb des WT-Zeitfensters einer 1000UF (4 Sekunden) gleich 2 1000er Beeinflussungen kommen (und zwar zeitgleich).
- Ein fix auf der PZB-Seite aendert NICHTs an der existierenden Funktionalitaet (wieso sollte ich sowas machen?) -- die Aenderung faengt einzig und allein diesen Grenzfall ab und reagiert robust darauf: sprich, das Skript kommt nicht mehr durcheinander wenn mehrere UFs gleichzeitig auf ihre WT Bestaetigung warten. Das hat keinerlei Einfluss auf irgendeine normale Signalsituation im TS, ausser eben es laesst die BR101 korrekt auf die problematischen Mosel GPAs reagieren.
Das stellt doch nun wirklich keine Verschlechterung dar!? Ausserdem entscheidet natuerlich vR was an der Lok geaendert wird. Meinerseitig ist lediglich klar, dass es sich einfach beheben liesse und alle PZB-Junkies mit ueberhoehter Geschwindigkeit mit ihrer schoenen neuen BR101 ueber die Mosel GPAs fahren koennten um sich dort eine zuenftige 1000er abzuholen.
also würde man ohne Änderung am PZB script die 101 nie auf der Mosel fahren können.
Kurze Klarstellungen: man kann die Strecke benutzen -- bekommt halt aufgrund der Doppelevents nur keine korrekte 1000Hz Beeinflussung an bestimmten GPAs. Und bei realen GPAs kommen auch nie 2 1000Hz Events sondern immer nur eins (die anderen Magnete sind Ein- und Ausschaltmagnete)
Vergleiche mit Autos mal beseite: es ist doch so, dass die PZB-Fahrer nunmal auch Mosel fahren koennen wollen und ueber GPAs donnern koennen wollen und dabei beeinflusst werden wollen LOL. Um das Problem zu loesen -- es sind ja 2 kommerzielle Produkte involviert -- sollte man pragmatisch sein. Die Strecke oder selbst nur die GPA Skripte zu fixen und an den Mann zu bringen ist kompliziert (Aerosoft/DTG) und dauert Ewigkeiten. Die 6 zusaetzlichen Zeilen Code machen die PZB aber mehr robust gegenueber solchen Absonderlichkeiten wie mehrere zeitgleiche Events etc. Das ist die pragmatische Loesung. Meine Testversion erzeugt zwar immer noch 2 Beeinflussungen, aber die werden eben jetzt beide gleichzeitig durch die Ruecknahme der WT bestaetigt. So einfach. Da laufen nun eben 2 Pruefkurven die exakt die gleichen Geschwindigkeiten checken und jeder koennte damit Mosel fahren: BR111, DTG, und eben vR BR101 -- pragmatisch!
Mal sehen wie vR das handhaben will, aber ich denke fast sicher: pragmatisch!
Die zufaelligen sporadisch auftretenden "Stoerung"smeldungen simulieren Funkloecher im Zugfunknetz (GSM-R), die auch solche Stoerungsmeldungen erzeugen. Fancy, oder? 
EDIT: Oops, Matthias J. hat's schon erklaert...
und ich hoffe explizit auf kein pzb update bei der 101. Der Fehler ist letztlich ein GPA Fehler und muss dort gefixt werden
Ich verstehe das Sentiment. Aber das Problem ist doch, dass es bei der Lok ohnehin einen Skriptpatch geben wird. DTG und alte vR-Loks mit den einfacheren PZBs kommen ja aber eben mit den fehlerhaften GPAs zurecht und wenn man jetzt die Strecke fixen wollte, wuerde das entweder alles Monate dauern und am Ende wahrscheinlich eher noch abgetan als zu geringfuegig fuer die Steamuser-massen, um einen Patch und den Testaufwand fuer Aerosoft/DTG zu rechtfertigen...
Servus,
also die Fehler mit den Scheibenwischern und Fenstern sind vR bekannt. Ich habe auch auf den Fehler mit der elektrischen Bremse hingewiesen und das ist auch bekannt und wird untersucht.
Schön zu hören, dass etwas bei den GPAs gemacht wird. Mir war klar, dass es irgendwas zwischen Lok und GPA sein muss, da die GPAs bei wirklich jedem Triebfahrzeug im TS funktionieren. Egal ob signal- oder streckenabhängig. Nur die 101 will sich nicht beeinflussen lassen. Ich bin gespannt, wann es das erste Update gibt und ob man die GPAs in den Griff bekommt. Wäre auf jeden Fall klasse, ich will da z.B. nicht mehr drauf verzichten.
Viele Grüße
Fabischo
Wie oben erklaert wird sie ja beeinflusst -- eben halt nur doppelt durch einen Bug in den Signalskripten der GPAs. Alle Loks mit Mager-PZB stoert das aber eben nicht, aber die BR101 hat als erste Lok im TS eben parallel laufende (beliebig viele) 1000 UFs in der PZB, nur da macht's eben im Moment mit dem 1000-er "Doppelfeuer" halt Bumm!
Die PZB darauf einzustellen ist viel einfacher als die Streckenfehler zu reparieren, obwohl dort in den Skripten der eigentliche Bug liegt.
Auch die Beeinflussungen bei Zs3v KZ 8/9? GPAs erkennt man meist an den drei kurz nacheinander folgenden Magneten.
Abgesehen von dem Heckmeck mit der elektrischen Bremse sind es wirklich nur die 1000 Hz-Beeinflussungen an signalabhängigen GPA. Alles andere funktioniert.
OK - ich habe mir die Sachen angeschaut und die GPAs der Mosel Strecke (Trier-Koblenz) haben einen Bug. Getestet z.B. mit dem GPA EhGP103 (Streckenkilometer 107.4 kurz nach der Eisenbahnbruecke nach Pfalzel Richtung Quint). Der GPA dort feuert ZWEI 1000Hz-Beeinflussungen auf einmal ("1000" und "PZB1000"). Die alte vR PZB erlaubte immer nur maximal eine 1000UF (DTG Loks koennen auch keine Ueberlagerungen). Daher war das kein Problem bei diesen Loks -- genauso gut haetten die Signalskripte auch 3-mal feuern koennen.
Die neue BR101 PZB kann aber multiple 1000 UF gleichzeitig laufen lassen, die sich auch vollstaendig wie in der Realitaet ueberlagern. Allerdings gibt es in der Realitaet keine 2 scharfen 1000Hz an der gleichen Stelle. Genau das aber erzeugen die Mosel GPAs. Bevor die erste 1000Hz Beeinflussung bestaetigt ist, kommt zeitgleich! die zweite. Das ist nicht nur Unsinn sondern auch schlecht fuer Skripte.
FAZIT: Die neue PZB ist im Moment zu realistisch fuer die GPAs auf der Moselstrecke . Weil sie aber nicht nur realistisch sondern auch gutmuetig gegenueber den Sonderbarkeiten existierender TS Strecken/Signale sein sollte, wird das sicherlich in einem Update behoben...
@NessaRevane Die ''Kaltstartoption'' scheint wohl leider (noch) nicht zu funktionieren...
Hast Du eine siebenstellige Zugnummer vor "cold" benutzt? Ich kann es im Moment nicht selber probieren...
