Beiträge von StefanDD

Zitat von BR03_1010-2

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.

Zitat von BR03_1010-2

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.

Zitat von Jodler

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!

Zitat von Zehntaurus

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:

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!

Zitat von ES64F4

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

http://rail-sim.de/forum/wsif/…paint-Pack-S-Bahn-Dresden

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

Zitat von lol515

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.

Zitat von ice

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 !

@AbsolutesChaoz
Im Editor sehe ich, was ich glaube, dass es Link 0 des Magneten darstellt, vor dem ESig und dann 3 eine grosse Distanz in Fahrtrichtung zeigende Pfeile (zum Link 1?) Koenntest Du mir evtl. eine einfache Instruktion geben um den Magneten an diesem ESig zu reparieren, oder ist das zu kompliziert und ich muss mich durch ein Tutorial zum Magnetenverlegen arbeiten?

@Barrett - danke fuer die Erklaerung. Das eigentliche Eingangssignal loesst aber auch keine Beeinflussung aus (obwohl dort ebenfalls ein Magnet liegt). Kann man das einfach reparieren, so dass dieses ESig die Beeinflussung ausloesst?

Kann mir jemand der Streckenbau-kundigen evtl. helfen zu verstehen, wieso das Vr0 vor dem Hp0 in Cochem Gleis 2 keine 1000Hz Beeinflussung ausloest, obwohl dort ein Magnet verlegt ist? Aufmerksam bin ich durch eine Youtube Testfahrt auf der Strecke geworden

Ich habe dann die Stelle im Debugmodus der Lok abgefahren und der Magnet sendet weder ein "1000" noch "PZB1000" Signal, also bekommt die Lok keine Beeinflussung. Im Editor liegt da ein ganz normaler vR Magnet, der mit dem Vorsignal korrekt gekoppelt scheint (allerdings kann ich das nicht beurteilen). Danach kommt ein scharfer 500er und das Hp0.

Irgendwie erklaere ich wahrscheinlich nicht praezise genug, was ich vorschlagen will. Ich moechte keine Signalstoerung erzeugen -- ich moechte ein normales Hp0 inkl. entsprechender Vorsignalstellung erzeugen, indem ich den Hp0 Trigger verlege und gemaess "3.1.1.1. Einsatz zum Erzeugen vom Signalbegriff Hp0" nutze. Der einzige vorgeschlagene Unterschied zur deutlichen Erhoehung der Flexibilitaet ist, eine Wahrscheinlichkeit dafuer definieren zu koennen, dass der Trigger diese Signalstellung per SendSignalMessage auch wirklich ausloest. Dazu waere, denke ich, eine nur sehr kleine Modifikation des Triggercodes in OnConsistPass noetig.
Dazu hatte ich vorgeschlagen im linken Eingabefeld im Editor fuer die Triggeroptionen statt "0" (fuer alle consists) "0P50" eingeben zu koennen, so dass der Trigger nur mit 5-prozentiger Wahrscheinlichkeit ausloest.