Beiträge von StefanDD

Ich glaube/hoffe nicht, dass vR so mimosenhaft ist. Hier hat jedenfalls niemand genoergelt?! Es gibt einen unschoenen Bug, der spielendleicht zu beheben ist. Ich habe ihn durch Eigenarbeit auf dem Silbertablett praesentiert, und genau erklaert wo welche Aenderung im Skriptcode noetig ist.

Wenn Dir die PZB mit diesem Problem reicht oder gefaellt, warum postest Du dann hier? Willst Du mich und andere ueberzeugen, dass der Kaiser Kleider anhat, uns also dieses Problem auch gefallen oder nicht stoeren soll?

Ich glaube nicht an das Ende von EL. EL ist fuer mich das Herz des vR Marktes. Ich glaube, dass die vR Mitarbeiter auch mit Kritik umgehen koennen und keine unaufrichtigen Lobhudeleien hoeren wollen, sondern Lob dort, wo sie fuer vieles zu loben sind, und Kritik dort, wo man noch nachbessern kann.

Steinchen:
wir haben nicht das Jahr 2013! Die PZB ist nicht als Beta deklariert. Behauptungen dass der TS nicht fuer komplizierte Zugsicherungssysteme ausgelegt, sind zu allgemein und treffen auf die PZB nicht zu! Jeder hier akzeptiert die Einschraenkungen gegenueber der original-PZB Hard- und Software. Ich habe sich noch niemanden ueber den Mangel an mehrfachen, sich ueberlagernden Ueberwachungsfunktionen der PZB beschweren hoeren. Allerdings ist der Bug hier nicht dem TS, oder der Machbarkeit, sondern einem Fluechtigkeitsfehler anzulasten!

D.h. wenn ich in meinem Szenario einen Fehler mache und dafuer eine ZWB kassiere, moechte ich nicht auch noch eine weitere sinnlose kassieren -- vorallem dann, wenn man fuer viele hochwertige Addons ziemlich viel Geld bezahlt hat! Dieses Problem ist innerhalb von wenigen Minuten zu beheben. Alles was in Zusi oder Loksim gemacht werden kann, kann im TS auch gemacht werden. Software bleibt Software! Auch Zusi und Loksim bieten m.W.n. keine mehrfachen UeF wie die originale PZB an. Die mehrfachen Verweise sowohl auf den vermeintlichen Betastatus (stimmt einfach nicht fuer 243, 156, 110, 140, 112) als auch die TS-Limitationen haben mit dem Thema hier nichts zu tun - also bitte beim Thema bleiben!

Egal was fuer Resultate andere hier bekommen, hoffe ich sehr, dass Herr Goltz das hier zufaellig liest -- falls er sich den Code kurz anschaut, wird er sofort sehen, dass hier ein Bug vorliegt.

Ich bin kein vR Basher und bemuehe mich sehr, alles respektvoll darzulegen, denn ich hoffe natuerlich, dass ich die naechsten Loks ohne aufwendige Bytecodeanalysen und Eigenbaufixes einfach voller Freude fahren kann. Es waere natuerlich immer noch wuenschenswert, wenn irgendeinmal ein assets\virtualrailrods\sharedlib oder so gebaut werden koennte, so dass man mit EINEM Update alle PZB-Loks und LZB-Loks reparieren koennte. Ich bin immer noch der Meinung, dass man das modular hinbekommen koennte...

@Steinchen

- Dem kann ich nicht zustimmen. Zumindest bei meinen gekauften vR PRodukten wird mit vorbildgerechter PZB geworben. Die PZB war vielleicht 2012 in Beta. Die LZB ist sicherlich immer noch im Betastatus aufgrund von TS Limitierungen. Fuer die PZB gibt es keinen Grund warum sie nicht korrekt programmiert werden koennte (in dem begrenzten Umfang der von Anfang an kommuniziert wurde, also ohne multiple UeF) und keine TS Limitation. Der Bug hier ist ein reiner und kleiner Fehler, nicht mehr und nicht weniger.

- Ausserdem ist die gute PZB von vR fuer viele ein Alleinstellungsmerkmal und Kaufgrund -- ich kaufe vR und nicht GBE Loks WEGEN der Aufruestung und der PZB!

- Selbst wenn dem so waere (PZB in Beta), verstehe ich den Zweck des Beitrages nicht? Gerade dann waere doch dieser Bugreport besonders wichtig???

Danke fuer den Hinweis. Trotzdem ist es besser, wenn ein paar erfahrene! Leute das erst verifizieren koennen. Man muss das so testen, dass man in freier Fahrt (aus dem Startprogramm raus) auf ein rotes Hauptsignal zufaehrt und am Vorsignal nicht mit Wachsam bestaetigt. Nach der noetigen Befreiung kriegt man am 500er eine erneute ZWB, mit dem Hinweis vom Hilfesystem, dass man sich unerlaubt aus einer restriktiven Ueberwachung befreit haette.

Kannst Du das bestaetigen?

Disclaimer:
0. Zunaechst mal habe ich NULL Hoffnung, dass vR diese Bugs in den alten Produkten repariert. Sie wissen z.B. mittlerweile sehr wohl wie man die Startprogrammbefreiung korrekt einbaut, haben diese Bugs aber in BR111 und BR143 belassen (bei der BR111 kann man den Bug durch den Kauf der ORoten mit Quelltext selber fixen). Ich habe den Bug, den ich hier beschreibe bei mir in der 132/232 und der 112 gefixt (durch Wrapperskripte, die die Funktion OnControlValueChange abfangen) und werde nach und nach Wrapperskripte fuer alle anderen Loks erstellen. Allerdings kann ich die nicht anbieten, da VR solche Sachen unterdrueckt. Ich habe seinerzeit die mit der ORoten BR111 publizierten Luaskripte verbessert, aber der Eintrag wurde einfach gesperrt. Das ist vielleicht nachvollziehbar, da kommerzielle Produkte eben aufwendig getestet werden muessen, und ein Fehler der in der 120, 103, E03, 243, 156, 112 etc. ueberall vorhanden ist, wuerde einen enormen Testaufwand erzeugen. Und Support von Fremdaenderungen ist nervig bzw. Suizid, weil man ja die Qualitaet der Aenderung ueberhaupt nicht kennt!
1. Der Bug ist ein Fehler in der PZBFREI-Logik seit der BR111 (dort nicht), also in allen Produkten wie z.B. BR232 bis zur aktuellen BR112! (Getestet mit 232, 243, 112)
2. Ich bitte, dass jemand den Bug wenigstens bei der BR112 nachvollzieht und an den VR Support meldet (ich habe keine Supportmoeglichkeit auf der VR Webseite gefunden). So kann er hoffentlich wenigstens in den aktuellen Loks UND ALLEN ZUKUENFTIGEN gefixt werden.

Bugbeschreibung:
Die VR Loks nach der BR111, die aber alle auf dem PZB Code der BR111 aufsetzen, haben einen Programmierfehler in der PZB-FREI Logik, durch den man bei einer Befreiung aus einer Zwangsbremsung nach verpasster Wachsambetaetigung am 1000Hz aus der Sicht des Skriptcodes auch gleichzeitig eine Befreiung aus einer restriktiven Ueberwachungskurve erzeugt. Dadurch bekommt man am naechsten scharfen 500Hz Magnet IMMER eine Zwangsbremsung.

Technisches [fuer Herrn Golz/vR]:

Die PZBFrei-Logik innerhalb OnControlValueChange funktioniert ungefaehr so:

Bei der BR111:
Falls Taste Frei gedrueckt
___Falls TasteFreibereitsgedrueckt=FALSE und ZWBaktiv=TRUE und weitere Bedingungen
______behandle Variante Frei aus ZWB
______ZWBaktiv=FALSE
______TasteFreibereitsgedrueckt=TRUE <--- verhindert dass die anderen beiden Falls-Bloecke abgearbeitet werden
___Falls TasteFreibereitsgedrueckt=FALSE und ZWBaktiv=FALSE und weitere Bedingungen:
______behandle Variante Frei aus 1000Hz
______Markiere Befreiung als unzulaessig falls kommender scharfer 500Hz
______TasteFreibereitsgedrueckt=TRUE
___Falls TasteFreibereitsgedrueckt=FALSE und ZWBaktiv=FALSE und weitere Bedingungen:
______behandle Variante Frei aus restriktive Ueberwachung
___fertig
fertig

BR232, BR243, BR112, und hoechstwahrscheinlich 120, 103, E03, 110, 140, 156, 243:
Hier ist folgendes passiert (weiss ich als Softwareentwickler aus Erfahrung zu 99% Gewissheit). Bei den Entwicklungen nach BR111 schaute Herr Golz auf diese komplexen if-Schleifen und sah die gleiche Bedingung TasteFreibereitsgedrueckt=FALSE in allen Falls-Zweigen. Wenn die Bedingungen in den Schleifen sich wechselseitig ausschliessen, gewinnt man an Performance wenn man die Abfrage rauszieht. Wenn man nach einer langen Zeit auf seinen eigenen Code schaut, passiert genau sowas!

Falls Taste Frei gedrueckt
___Falls TasteFreibereitsgedrueckt=FALSE <- Abfrage wurde herausgezogen. Damit fehlt aber die "Barriere" zwischen den kommenden Falls-Zweigen
______Falls ZWBaktiv=TRUE und weitere Bedingungen
_________behandle Variante Frei aus ZWB
_________TasteFreibereitsgedrueckt=TRUE <--- verhindert NICHT MEHR dass die anderen beiden Falls-Bloecke abgearbeitet werden!
_________ZWBaktiv=FALSE <--- dadurch wird der einer der naechsten Zweige (meistens Befreiung aus restriktiver Ue.) AUCH aufgerufen
______Falls ZWBaktiv=FALSE und weitere Bedingungen:
_________behandle Variante Frei aus 1000Hz
_________Markiere Befreiung als unzulaessig falls kommender scharfer 500Hz
_________TasteFreibereitsgedrueckt=TRUE
______Falls ZWBaktiv=FALSE und weitere Bedingungen:
_________behandle Variante Frei aus restriktive Ueberwachung
______fertig
___fertig
fertig

Waehrend ich auf die Moderatorenentscheidung fuer meinen Eintrag im vR-Supportforum warte, nochmal kurz eine zu diesem Thread passende Zusammenfassung meiner Verbesserungen der vR BR111 PZB Funktionalitaet, sowie danach eine eigene Fachfrage.

Meine Verbesserungen (bug fixes) der BR111 PZB, Stand 29.Mai (unveroeffentlicht):

1. Das Startprogramm laeuft nun korrekt im Hintergrund als parallele virtuelle 1000Hz Pruefkurve. Man kann sich also daraus (z.B. vor einem realen 1000Hz Magneten) befreien. Der Befreiungsbug ist damit gefixt. Das aber noch im Hintergrund weiterlaufende Startprogramm ueberwacht aber dennoch ob innerhalb von 550m ein scharfer 500Hz Magnet liegt --> unerlaubte Befreiung --> ZWB. Das Skript ist jetzt intelligent genug, um die FREI-Taste dem Startprogramm oder dann einer evtl. innerhalb dieser 550m folgenden 1000Hz Beeinflussung zuzuordnen.

2. Wie in der PZB90 1.6 Dokumentation beschrieben und anders als in der originalen BR111 faellt die PZB auch immer wieder erneut in das Startprogramm wenn angehalten wird UND der Wender aus der V-Position verschoben wird, allerdings nur wenn keine aktuelle Prueffunktion laeuft (z.B. innerhalb der 1250m eines aktiven 1000Hz Magneten) -- dies entspricht dem realen Bugfix in der PZB90 2.0 -- man kann also das Startprogramm per Richtungswender nicht ausnutzen, um sich aus einer echten Beeinflussung zu "stehlen".

3. Ein weiterer Bug in der originalen BR111 PZB ist, dass Schleichfahrt nur bei laufender 1000Hz-Beeinflussung detektiert wird -- wird die Lok nach einem 1000Hz aber vor einem 500Hz Magneten plaziert und befindet sich nach Anfahrt nur in der 500-er Pruefung, wurde das Fallen < 10km/h fuer > 15s nicht korrekt erkannt und nicht in den restriktiven Modus umgeschaltet. Dieser Bug ist auch gefixt.

Fachfrage:

In der vR PZB sowie in den neuen DTG-Loks "erbt" eine innerhalb der 550m des Startprogrammes folgende 1000Hz Beeinflussung den restriktiven Modus des Startprogrammes -- wenn man sich also nicht aus dem Startprogramm befreit und innerhalb von 550m eine 1000-er Beeinflussung hat, ist diese auch restriktiv. Dieses Verhalten zeigen auch die HRQ Loks.
Allerdings sind die verschiedenen Loks inkonsistent wenn es darum geht ob dieser restriktive Modus mehr als einmal uebertragen wird (Startprogramm -> 1000 -> 500).
Startet man kurz vor einem 1000er und befreit sich nicht und faehrt dann ueber einen folgenden 500er, unterscheiden sich die Loks:
vr BR111, 120, 243: 1000er ist restriktiv (<45kmh), 500er Ueberwachung ist auch restriktiv (<25 kmh).
HRQ, DTG: 1000er ist restriktiv (<45kmh), 500er Ueberwachung ist nicht mehr restriktiv.

Wer hat recht? Ueber wieviele Beeinflussungen uebetraegt sich der restriktive Modus der "fiktiven" 1000er Beeinflussung des Startprogrammes? Ich konnte dazu in der Literatur nichts finden.

@LokWurm/MarvWe:

Habt Ihr den VR Support kontaktiert und oder anderweitig Hilfe erhalten?

Ist das Problem mit der AFB unter Bremsen noch aktuell oder geloest/hat jemand weitere Informationen?

Die Antwort hilft mir bei der Entscheidung ob das neue 120EL IR Paket einen Kauf wert ist oder nicht.

Zitat von Cotten Eye Joe

Versuche ich gerade die 146.0, jedoch sind die verwendeten Skripte.out wohl fehlerhaft. Bekomme da die Sifa nicht aktiviert. Bin noch an der Fehlersuche, vermutlich jedoch wird sich das nicht ändern lassen. Man kann diese *.out Dateien zwar ausdrucken (Druck in Datei - dabei werden die dann eigentlich lesbar), jedoch sind die verschlüsselt immer.

Gibt es im TS eine Lok mit MFA (Modulares Führerraumanzeigegerät), wo alles funktioniert?

Grüße

Die sind nicht verschluesselt -- ich koennte Dir da schon evtl. weiterhelfen. Bitte mal per Private Nachricht mitteilen, wonach ich in den Skripten schauen soll. Ich bearbeite die .out Dateien regelmaessig auf Lua Assembler Niveau.

OK - Patch ist hochgeladen in den Downloadbereich

http://rail-sim.de/forum/wsif/…FA-Sound-FIX/#description

Zitat von Madison

Ansonsten würde ich es begrüßen wenn du die angepassten Dateien zwecks Umschaltung der Zugart der Allgemeinheit zur Verfügung stellst

Das geht im Moment am ehesten per PM. Ich hatte im Januar die BR101 angekuendigt, und aber eher Bedenken/Gegenwind geerntet. Rechtlich bewegt man sich mit geaenderten Skripten in einer Grauzone -- sie gehoeren nicht wirklich direkt zum Spiel sondern "laufen" im Spiel und sind evtl. nicht genauso von der DTG Eula tangiert wie der eigentliche binaere Spielcode (.exe .dlls etc). Trotzdem musste ich die Skripte natuerlich disassemblieren, aendern und erweitern und dann wieder assemblieren. Letzlich aendert z.B. das inoffizielle Raildriver Interface auch alle .out Dateien ueber genau die gleiche Kette (disass. + modif. + assembl.)
Ich hatte im Januar gehofft eine Debatte anzustossen und einen Sachkundigen im Forum dazu zu hoeren (ala M Goltz) -- leider kamen aber nur viele wenige nuetzliche oder fundierte Reaktionen. Sicherheit haette ich natuerlich komplett nur mit DTG Erlaubnis, aber meine Jan. email ist bis heute unbeantwortet.

Da bleibt also nur das Testen zu "Forschungszwecken" -- eine breite Weitergabe braucht etwas mehr Sicherheit.

Zitat von Cotten Eye Joe

Habe ich, 146.2 ist jedoch davon unberührt im Bezug Sifa nicht funktionstüchtig. Was bleibt, meiner Meinung nach, für jede Lok einen eigenen InputMapper erstellen.

OK - jetzt verstehe ich den Bezug zu Deinen Patches -- Dein Inputmapper repariert im Moment eine der Sifas zu ungunsten der anderen. Ich hoffe, Du kannst das Problem loesen -- in der Tat koennen soviel ich weiss individuelle Loks ihren eigenen persoehnlichen Inputmapper haben.

Ich verstehe nicht, was diese Patches mit dem aktuellen Thema genau zu tun haben? Wir reden eigentlich nicht aneinander vorbei -- aber es gibt eine offensichtliche Kentnisdifferenz in puncto Funktionsweise der Lua Skripte

Kann bitte jemand mit einer UNVERAENDERTEN Koeln-Koblenz Installation meinen Patch testen? Also Sifa vor und nach Installation der Dateien aus Post #1?

Cotten Eye Joe

Die .out Skripte sind schon in Ordnung -- der Controlvalue heisst bei der BR146.0 "Sifa" und daher auch der Eintrag "<ControlName d:type="cDeltaString">Sifa</ControlName>" im Engine.bin
In den Skripten wird der dann mit SetControlValue("*:Sifa",,,) gesetzt oder gelesen!

Ich kenne mich nicht mit Inputmappern aus, aber bitte entferne mal Safters Patch und teste nochmal.

Meine Modifikation funktioniert auf mehreren meiner Computer mit der unveraenderten Vanilla CologneKoblenzAssets.ap.

Zitat von Cotten Eye Joe

Nö, bei mir nicht - deswegen ja meine Frage dazu. Soweit ich mitbekommen habe, hat auch niemand bisher diese Sifa anbekommen.

Kann nicht sein -- siehe hier: http://rail-sim.de/forum/index…-ist-stumm-wie-ein-Fisch/
Ist die Expertensteuerung an?

Bei mir kann ich Sifa und PZB jeweils problemlos anschalten mit Shift/Ctrl + Numpad Enter. Ich habe die Strecke erst kuerzlich gekauft und sie beinhaltet daher evtl. das letzte Update?!

AHH - hast Du evtl. Safters Inputmapper installiert? http://rail-sim.de/railsimnew/…r-146-2-aus-koeln-koblenz
Dann waere es die VR Tastenkombination Shift 6 oder 7 glaube ich

Zitat von Cotten Eye Joe

Nochmal: Wie bekomme ich bei der DB BR 146.0 die Sifa angeschaltet?

Shift + Numpad Enter schaltet die Sifa ein (graue Nachrichtenbox erscheint und sagt: SIFA Enabled oder so)

Zitat von Matthias J.

Das ändert aber trotzdem nichts an der Tatsache! Wenn man die Scripte einfach so wild miteinander verknüpfen dürfte, hatte die BR189 schon längst EL Qualität

Die Skripte verknuepft man nicht -- man muss schon (Lua-Assembler) programmieren koennen. Aber dennoch, aufgrund genau der Tatsache, fahre ICH die BR101 mit umschaltbarer Zugart und Du nicht (-- was ich persoenlich schade finde).

@Moderator: Ich meinte mit entpacken natuerlich den Inhalt der angehaengten .7z Datei, nicht der CologneKoblenzAssets.ap Datei. Ich werde ein .rwp schnueren!

Matthias J: Die Skripte sind nicht verschluesselt http://rail-sim.de/forum/index…altbarer-Zugart/?pageNo=2
Allerdings musste ich die Skripte auf der Bytecodeebene editieren und ergaenzen, und danach wieder assemblieren.

Gerne -- ich muss noch rausfinden, wie genau ich das mache.

Bei den meisten meiner Fixes tappe ich noch im Dunkeln, wass das Verbreiten von getweakten Luaskripten anbelangt. Ansonsten haette ich die sehr gerne mit der Community von Rail-sim.de geteilt!!!

Hatte DTG im Januar! um Erlaubnis gefragt -- bisher keine Reaktion. Ich habe auch noch folgende andere Fixes fuer DTG Loks:

- MA HH MG BR101 -- Zugart schaltbar zwischen O M U
- ER20 -- Zugart schaltbar zwischen O M U
- MA HH MG BR294 -- -- Zugart schaltbar zwischen O M U
- BR189 -- wirkungslose (nicht hydraulische) AFB Bremse gefixt, Schubkraftanzeige korrigiert

Hallo,

Typischer DTG copy&paste Fehler -- husch husch, muss morgen fertig sein. Da wurde u.a. vergessen, in der Soundproxydatei der 146.2 einen 2. Alarm fuer die 146.0 einzurichten und "Vigil Alarm" in "Sifa Alarm" umzubenennen . Oh, und der SIFA-Taster-Sound war auch vergessen worden und damit stumm...

Naja, einfach die angehaengten Dateien in Railworksverzeichnis entpacken/kopieren, dann sollte die SIFA der 146.0 ertoenen wie gewuenscht.

EDIT: Cache loeschen (Clear cache), um die Aenderungen zu aktivieren.

StefanDD