Beiträge von StefanDD

mmh. mal schauen wie sich das weiterentwickelt....

na dann hat @MasterDune es in der Hand ob Ihr mit vernuenftiger PZB fahren koennt oder nicht

Zitat von tom87

...Railtraction sollte sich mal die Mühe machen und sich die Erlaubnis einholen das Ding zu überarbeiten....

Ich habe mir die Skripte von RT mal grob angeschaut (im Bytecode) und kann sagen, dass das RT BR648 eine Weiterentwicklung des RT BR218 Skriptes ist. Man haette also ohne Probleme die Aenderungen mit 3 Zugarten zur BR218 rueckportieren koennen und koennte das immer noch. Man macht es aber leider nicht, wahrscheinlich eben weil die Kaeufer ja schon bezahlt haben und der Aufwandsanreiz fehlt

P.S. Ich fahre die RT BR218 mit meiner eigenen vollstaendigen PZB, und ich wuerde den Patch dazu auch veroeffentlichen, wenn ich die Erlaubnis von RT dazu haette (oder jemand dafuer von RT die Erlaubnis einholt). Ich wuesste aber garnicht, wen man da ansprechen sollte und die Wahrscheinlichkeit, dass die dem zustimmen wuerden ist sehr gering.

Ich denke, wenn Maik privat oder vR offiziell postulieren, dass was nicht "geht" oder "machbar" ist, sollte man natürlich dahinter in Klammern setzen: "(mit ökonomisch vertretbarem Aufwand)". Eine noch realistischere Bremsensimulation, oder z.B. slip/Rutschverhalten von Raedern etc., ist prinzipiell immer machbar. "Geht nicht" soll dann einfach heissen: "wuerde ewig dauern, massiven Aufwand zeitigen, und koenntet ihr nicht bezahlen :P", nur halt in verknappter Form.

Ich persönlich freue mich über input von usern wie flusi737, die enthusiastisch sind, und das sogar mit Taten (Videomaterial) untermauern, aber es geht nicht nur um das Wasser, mit dem natuerlich alle kochen -- und da ist vR ganz vorne mit dabei -- sondern um einfach auch technische Limits. DTG hat leider keine ge-jittete Lua engine verbaut, sondern Lua 5.02 und die volle Lokphysik gehört eigentlich in den C++ Code, aber davon verstehen die leider selber nichts (weil halt nur zugekauft). vR und Co. betreiben schon extreme Handstände und verlagern einiges der Physik in die Luaskripte, aber das frisst Frames und ist aufwändig.

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

• Unauthorized copying of this files, via any medium is strictly prohibited
• Proprietary and confidential
• Written by ...., April 2016

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 :-).

Zitat von lol515

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.

Zitat von Moe2k

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

Zitat von oebb 4010

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.

Zitat von Matze L

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)

@oebb 4010, @BlackHawk,

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...