Ich habe den Ordner Assets\VirtualRailroads\vR_Bnrbdzf_Witt vor der Installation des neuen Patches geloescht und habe KEINE Probleme mit der Handbremse.
Beiträge von StefanDD
-
-
Leider ein Bedienfehler. Signale werden grundsätzlich nicht vor, sondern entweder direkt bei der Vorbeifahrt oder kurz danach bestätigt.
Ist so nicht richtig: die von @trainmain1 beschriebene Bestaetigung muesste funktionieren. Gerade bei allen Loks wo "vR" mitgemischt hat, kann man WT VOR dem Vorsignal ziehen und innerhalb von 4 Sekunden nach dem Signal loslassen.
-
bei allem BIS EINSCHLIEßLICH I60R ohne System 90 Update kann man jede Zwangse unter 25 km/h auslösen. Indusi löst, wie eine PZB90, eine Zwangsbetriebsbremsung aus der Überschreitung der Fahrzeug Vmax. Jedoch löst eine Indusi diese nicht mehr automatisch, was eine PZB90 jedoch tut.
der 8073 hat eine Indusi I60, sprich in Zugart O gilt: 165 Vmax und Prüfgeschwindigkeit bei 1000Hz bei 95 km/h, beim Überfahren einer zweiten Beeinflussung mit 1000 Hz muss die Prüfgeschwindigkeit bereits erreicht sein, am 500er, soweit ich weiß 65 km/h, ansonsten erfolgt eine Zwangsbremsung, die man unter 25km/h wieder auslösen kann, allerdings steht man auch da fast sicher, weil die Bremse braucht ja ein paar Sekunden zum lösen...Ein paar Anmerkungen dazu:
- Bei I54 und I60 Systemen wird ueberhaupt keine Geschwindigkeit bei Befreiung aus einer PZB Zwangsbremsung kontrolliert. Dies wurde erst mit I60R eingefuehrt, und dort ist soviel ich weiss die Geschwindigkeit, die es zu unterschreiten gilt 30km/h, nicht 25km/h.
- Bei I54 und I60 Systemen wird keine Zugart-abhaengige VMax ueberprueft. Das wurde auch erst mit I60R eingefuehrt. Selbst wenn man eine I60R simulieren wollte, muessten diese Zwangsbetriebsbremsung AUTOMATISCH bei Unterschreiten von 165/125/105 km/h wieder geloest werden.Wenn man hier also eine I60 ohne Mikroprozessortechnik (R) simulieren will, muss beides wieder raus: FT aus ZWB erst unterhalb bestimmter Geschwindigkeit sowie Ueberwachung von Vmax. Beides ist erst in der I60R drin. Im Moment ist es ansonsten ein unrealistisches Gemisch aus alter und neuer Sicherungstechnik.
-
Je nach ControlValue musst Du es evtl. paarig mit SetControlValue benutzen.
Probiere mal: Call("SetControlValue", "Regulator", 0, ReglerSoll); Call("SetControlTargetValue", "Regulator", 0, ReglerSoll) -
Ist dort vielleicht ein Fehler drinne? Ich habe die Variable ReglerSoll außerhalb der Funktionen hinterlegt.
Das geht so nicht. Die Funktion Call("*:SetControlTargetValue"... benoetigt eine Zahl, keine Zeichenkette, also waere ein erlaubter Aufruf Call("*:SetControlTargetValue", "Regulator", 0, ReglerSoll) oder Call("*:SetControlTargetValue", "Regulator", 0, value);
Auch "Call("*:GetControlValue", "<RegulatorVorwahl>", 0);" ist nicht korrekt -- wozu die '<', '>'?
Insgesamt sieht das Codefragment nicht sehr sinnvoll aus
und ich glaube, Du musst Dich wohl oder uebel durch ein paar Skriptingtutorials arbeiten, sonst muessten die Forumsmitglieder Dein Skript per Forumspostings Schritt fuer Schritt mitaufbauen, was, sagen wir mal, ein sehr zaeher Prozess waere. -
Nein, ich suche einen Befehl mit dem ich eine Verzögerung hervorrufen kann. In C++ sah das damals so aus:Ich wollte eine Art "Auf- und Abschaltung" für den Regler programmieren. Die ReglerVorwahl habe ich im Inputmapper mit den Tasten D und A belegt. Solange ReglerVorwahl größer als Regler ist sollte er den Wert Regler langsam Aufschalten, solange der Wert ReglerVorwahl kleiner als Regler ist sollte der Wert Regler langsam abgeschalten werden. Damit die Ab und Aufschaltung überhaupt eine Wirkung hat, wollte ich das auf/abschalten des Regler Wertes mit etwas Verzögerung geschehen lassen.
Dafuer gibt es bereits eine spezielle Lua Anweisung im TS, die dieses Herangleiten an einen Kontrollwert regelt. Die von @questo vorgeschlagene Update-variante ist also unter Umstaenden nicht noetig. Nimm statt Call("*:SetControlValue", "Regulator", 0, Sollwert) die Anweisung Call("*:SetControlTargetValue", "Regulator", 0, Sollwert). Diese Variante erzeugt eine langsame Annaeherung des "Regulator"-Wertes an den Sollwert.
-
Es hat sich gelohnt RSSLO direkt darauf anzusprechen. Sie haben sogar innerhalb von 48 Stunden per email nachgefragt, was genau fehlt/falsch sei, und jetzt gibt es sogar 2 Zwangsbremsungsbanner, eins fuer die SIFA und eins fuer PZB/LZB!
-
Nun die negativen Punkte:
..
-Das Cab ist das gleiche, das auch bei der BR 145 eingebaut wurde.Natürlich weiß ich, dass in der Realität bei der BR 146.0 das Cab gleich aussieht wie bei der BR 145, aber wieso macht man dann nicht eine 146.2?
Es ist ein NEGATIVER Punkt im Bewertungsthread einer 146.0, dass sie das korrekte Cab hat ??????
-
Schoen waere es wenn fuer zukuenftige Jahre jemand, der so um das Wort "Deutschland" herum in folgender Karte wohnt ;-), so ein Treffen organisieren wuerde -- einfach um die Anfahrt fuer alle irgendwie im Rahmen zu halten.
-
Kleiner Aufruf an die, denen Displays/Anzeigen und Bedien-realismus wichtig ist [gerade weil diese Fraktion kleiner ist als jene, denen es eher auf Griffstangen, Schatten, Schraubentexturen etc. ankommt]. Bitte schreibt an RSSLO und bittet hoeflich um das Hinzufuegen einer vernuenftigen Anzeige fuer Zwangsbremsungen. Im Moment gibt es bei Sifa, LZB, PZB-Zwangsbremsungen nun gar kein rotes Displayelement/MFD-Textfeld mehr, um die Zwangsbremsung anzuzeigen.
Siehe auch im obigen Video:Externer Inhalt youtu.beInhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.Ein klarer Schritt zurueck von der BR193 AC/DC, wo es wenigstens das noch gab. Im Uebrigen gibt es jetzt auch keine Zeitanzeige mehr, weder in der MFD noch auf dem GSM-R. Je mehr nach solchen Bediendetails fragen, desto hoeher die Chance, dass die in einem Update UND in zukuenftigen Loks dabei sind.
-
Mmh -- Ich habe zwar also leider den Zweck meiner Posts verfehlt, ein Feedback zu meinem Vorschlag zu bekommen, habe auf der Plus-Seite aber mehr ueber die (nicht wirklich erfragten) Signalstoerungsmoeglichkeiten Deines Triggers erfahren und erreicht, dass Du mich genau verstanden hast. Immerhin!
-
I have made a MF BR145 160 Km/h capable by using some stuff from the BR146. It have the BR146 tachometer, working AFB, right speed display. The BR 145 is 100% fine. The BR 145 ZZA have AFB cap at 140 Km/h. I really don't know why...Both, AFB and LZB are limited to the maximum engine speed (140km/h). You won't get LZB or AFB to exceed 140km/h with either the ZZA or non-ZZA versions since this limitation is done in the script. It MAY work if you also copy and rename the vR_BR146_0_EL_Engine_Script.out script to vR_BR145EL_Engine_Script.out However, DO NOT bother Maik or vR with support for this rogue BR145
-
Fantastisch, dass @SteuerwagenSchmiede ein Repaint der Schloss Wackerbarth 146.0 der S-Bahn Dresden gemacht hat - Herzlichen Dank!!!
-
Der Code sucht nur nach dem Wort "cold" irgendwo in dem Feld, also sollten " cold", "cold", "-cold". "reallycold", "super-duper-cold" und unendlich viel mehr
Varianten funktionieren -
kurzer technischer Fakt: ich bin mir sicher, dass alle Hersteller bei ihren Lokskripten auch im Code zwischen KI Lok und Spielerlok unterscheiden. Die Skripte sind also so geschrieben, dass die ganzen Systeme PZB,LZB,Sifa,komplexe "Expertenkontrolle"-Steuerung etc. nur in der Spielerlok laeuft. Also nehmen diese Systeme nicht nur kaum RAM weg, sie erzeugen auch in den KI Loks in den Szenarien kaum CPU-Last bzw. Rechenzeit, da dann nur ein ganz kleiner Bruchteil des Skriptes ueberhaupt ausgefuehrt wird (Pantographen, Lichtregelung usw.)
-
@RalfK -- huch -- ich habe niemanden konkret gemeint und das ohnehin nur scherzhaft gesagt (hatten wir beim Thema Skript mal einen Dissens? -- ich weis nichts davon)
Ich bin mir sicher, wir alle haben "reale" Probleme weitab des TS... -
Ich werde jetzt gesteinigt, aber selbiges trifft für mich bei der PZB auch zu...
Gluecklicherweise kannst Du die PZB ja ausgeschaltet lassen -- beim Thema RAM-Verbrauch spielt ihre Existenz in der Lok, oder ob sie laeuft oder nicht, keine Rolle!
-
Die Lokskripte und damit Bremsarten, PZB, LZB etc. kosten RAM-technisch gesehen so gut wie GARNICHTS, ein paar hundert KByte pro Lok vielleicht. Der RAM-Bedarf wird bestimmt durch die Feinheit (Polygonzahl) des Modells, die Aufloesung und Zahl der Texturen, die Zahl der Animationen (inklusive jedes Fuehrerstandslaempchen) die ja auch wieder Texturen brauchen, und aehnliche Dinge -- also all das, was die Lok gut aussehen laesst.
-
Abzocke und Wucher würde ich hier auch nicht sagen, aber leicht überteuert oder nicht Wert.
Allerdings ist auch diese Einschaetzung extrem subjektiv und kommt von jemandem, dem Weiterentwicklungen der Logik der Lok egal sind (Zitat: "Skriptschund"). Ich denke wer diese Loks vorallem als "bewegliche Textur" im TS einsetzen will, sieht sicher nicht so viele Unterschiede zur BR145 und keinen grossen Neuwert. Wem allerdings die Zugsicherungssysteme wichtig sind, der sieht im Handbuch ein paar Neuigkeiten, die im TS gelinde gesagt einen neuen Standard setzen!.
-
@AbsolutesChaoz Super, danke -- genau das Niveau von Anweisung was ich befolgen kann
!
