[vR] BR 103 Sammelthema für mögliche Fehler

Aha. Gut zu wissen! Das Szenario habe ich übrigens von eurer Homepage.
Ist aber nicht so wild. Ich musste mal herzhaft lachen.

Bei der Touristik 103, geht die Lokbremse nur zwischen -100 und +10 % (nur diese beiden Werte) zu regeln. Ansonsten muss ich die Lokbremse festhalten um +100% zu erreichen.
Könnte man sich diese Sache mal anschauen.

Die Lokbremse funktioniert nicht so wie die Zugbremse. Gibt ne Stellung für Lösen, ne Stellung für Halten und ne Stellung für stärker bremsen.

Danke an vR Das leidige Problem mit dem Tritt hat sich mit dem Update auf V4 jetzt erledigt.

Ja, danke vR. Jetzt macht der TS endlich wieder Spaß.

Ja wir jammern da auf hohem Niveau. Aber wie das so ist wenn man einmal weiß wo der Murks ist dann schaut man da immer wieder hin und ärgert sich
Aber das hat sich ja jetzt erledigt.

Wie die kleine Stelle im Mund, die endlich abheilen würde, wenn man aufhören könnte ständig mit der Zunge daran rumzufummeln.

Hallo,

ich habe ein Problem mit der orientroten 103 (kurze Version) und der Aufgabe "vR BR103 IC119 Münster nach Insbruck".
Gestern habe ich diese 98-minütige Aufgabe angefangen und bis Langen am Arlberg gefahren. Dort habe ich gespeichert, um heute fortzufahren.

Leider fährt die Lok keinen Meter mehr
Ein Neustart und neuladen des Spielstandes brachte nichts.
Aufgerüstet habe ich die Lok nach dem laden per Anleitung und im zweiten Versuche per "Schnellaufrüsten", alle Bremsen sind gelöst, die Türen geschlossen, es tut sich nichts.

Hat jemand einen Rat?

Die 103 ist eine mit komplizierten Scripten ausgerüstete Lokomotive.
Es ist bekannt, dass Lokomotiven mit vielen Scripten Probleme bereiten beim Speichern und Laden von Szenarien.
meines Wissens liegt dies daran, weil der TS den Stand des Scripts mit all seinen Variablen nicht mitspeichert, was dazu führt, dass beim Laden das Script mit ungültigen Werten gefüttert wird.
Das führt dann zu einem Script, das nicht mehr funktioniert, was zu einer nicht mehr funktionierenden Lok führt.

Meines Wissens kann man das unter optimalen Umständen umgehen, indem man vor dem Speichern die Lok komplett abrüstet, so dass beim Laden die Scripte mit den passenden Werten für eine abgerüstete Lokomotive gefüttert werden.

Jedenfalls ist das meine Erinnerung zu dieser Problematik.

Ich habe ganz gute Erfahrungen gemacht mit der 103, wenn man:
- Im Stand abspeichert
- Genug Zeit zum aufrüsten hat
- Aus Zeitgründen die automatische Aufrüstung wählt
- Bei Bedarf Sifa, PZB und LZB aktivieren
- Dann die elektrische Bremse lösen
- Jetzt sollte das gute Stück fahren

Meinen Vorrednern möchte ich noch Folgendes hinzufügen:

Falls Du an dem Bahnhof Fahrgäste ein- und aussteigen lassen sollst, ist das Zeitfenster teilweise sehr eng. Deswegen solltest Du zuerst abrüsten, dann speichern. Erst nach dem Laden des Speicherstandes die Fahrgäste einsteigen lassen, dann kannst Du währenddessen aufrüsten und sparst somit kostbare Zeit.

Abrüsten ist nach meiner Erfahrung nicht notwendig aber vielleicht generiere ich mir dadurch das Problem mit der elektrischen Bremse? Muss ich mal ausprobieren. Aber selbst, wenn es so ist, die elektrische Bremse ist schneller gelöst als die Lok abgerüstet, von der Zeit her also besser. Einfach halten und sofort, wenn der Zug steht speichern.

Norbert dreht mal wieder seine Hosen auf 180 rücklinks und will uns irgendwas mitteilen

Zitat von Norbert Koch

Das Abspeichern der Sifa geht ja

Stimmt nicht. Die Sifa ist genauso aufgebaut wie deie PZB und LZB im Einschaltvorgang. Die ist nach dem laden aus.

Wenn du mir sagst wie ich die ~200 Variablen in Controller codiere (mit vertretbarem Aufwand) dann kan nich den Zustand auch speichern. So geht es nicht wie es jetzt im TS ist. Dass es bei den Loks von RSC funktioniert liegt an der Tatsache dass die System dort sehr vereinfach gebaut sind. Dort ist der Zustand der PZB zB nur als Ein oder Aus definiert, das reicht mir für meine Abläufe im Script aber nicht, da muss mehr geprüft werden als nur Ein oder Aus. OnSave() und OnResume(), die ja seit 23014 dabei sind und auch wirklich funktionieren könnten, taugen nichts, weil man weder die Daten mit LUA vernünftig serialisieren kann um die abzuspeichern, noch kann man unterscheiden in welchem Szenario gerade gespeichert wird. Wenn ich also mir die 200 Zeilen Gaga-Code ans Bein bind um die Daten zu serialisieren (was vorher bedingt, dass alle Daten in eine LUA Table überführt werden was ein neucoden der Scripte mit sich bringt), hat man immer noch das Problem dass der Zustande auch beim nächsten laden einer anderen Aufgabe so geladen wird und das ist dann ja nun mal falsch. Man kann icht aufgabenbezogen die Daten speichern, Punkt Ende aus.

Das ist übrigens ebenfalls ein Grund warum die 120 nicht kommt. Der Scriptaufbau erfolgte dort von Beginn an ausgerichtet auf Serialisierungsmöglichkeiten und ist mehr oder weniger komplett OOP (sofern man das in LUA so bezeichnen mag, denn OOP kennt LUA nicht wirklich). Durch die fehlenden Debugmöglichkeiten im TS und der fehlenden Zeilennummernausgabe bei Logikfehlern komme ich da keinen Schritt mehr weiter. Ich weis einfach nicht wo ich den bekackten Fehlern suchen soll wenn man mir keinen Anhaltspunkt aus dem Interpreter liefert. Somit hätten wir die 120 dann auch gleich abgehandelt. Auch hier wird wohl ein kompletter Neubeginn nicht ausbleiben. Ich hätte doch lieber C++ als "Script"-Sprache gesehen, auch wenn man deutlich mehr lernen muss dafür. Aber ohne die Werte-Unterstützung des TS selbst bringt die beste Hochsprache nix. Wenn ich nicht auslesen kann was ich brauche habe ich einfach keinen Wert.

Vielen Dank für Eure Hilfe!

Der Vorschlag von @Safter führte mich letzten Endes zum Ziel!
Die anderen Ratschläge sind auch hilfreich, vielen Dank dafür.

Mal eben was anderes: Wie verlinke ich Namen von Mitglieder vernünftig, also ohne dieses @-Symbol??

Hallo Maik,
Du sag mal, was macht denn so der LZB-Code?
Ich habe da gerade einen wirklich blöden Fall. Ich erstelle gerade ein Szenario samt realem KI-Fahrplan. Nun kommt es an einer Stelle zu einer Verzögerung, da der ME vor mir etwas Verspätung hat. D.h. ich laufe auf. Da an der Stelle gerade 200km/h ist, die LZB aber nicht das Hp0 erkennt, sondern nur die 100m davor beginnende 160km/h-Begrenzung, habe ich keine Chance zum stehen zu kommen. Will heißen, Nadel läuft runter auf 160, und danach - bäm- , knallt sie auf einmal auf 30 km/h -> Zwagsbremsung. Wenn ich mit 190km/h das Vr0 sehe, habe ich ebenfalls keine Chance binnen 1km auf 0 abzubremsen.

Ich weiß ja, dass - nach unserer Erörterung in dem anderen Thread - Du an der LZB sitzt, sich das ganze aber als recht schwierig herausgestellt hat. Aber könntest Du nicht 'ne optimierte "Zwischenversion" rausbringen, welche die Hp0 "richtig" erkennt?

Grüße

Keine Antwort ist ja (bekanntlich) auch eine. Schade...
Dann halt nur 200km/h, wenn vor einem die Strecke leer ist.

Sorry, hatte das nicht gesehen. Hier gehen seit dem Forenumbau allerlei wichtige Themen einfach unter. Man sieht sie einfach nicht mehr vorne.

Die LZB hat bisher Null Fortschritte gemacht. Es ist einfach keine Zeit dafür da. Wenn bis SO noch ein paar Stunden Zeit und Lust über sind, schaue ich mir das nochmal an. Aber ich weis schon dass es bedeutet die LZB nochmal neu zu coden. Und das ist so schnell einfach nicht zu machen und bringt gerade nicht so wirklich die Vorteile für uns.

Nimm Dir gern bis Mittwoch Zeit