Animationen von .bin funktionieren nur bei fehlerhaften Skript

Discord Einladung
Trete unserem Discord-Server bei (klicke hier zum Beitreten).

    Liebe Community!


    Ich versuche, mich in das Scripting im Train Sim Classic anhand des RSSLO 4010 einzuarbeiten, jedoch bin ich auf eine massive Verwirrung gestoßen. Ich habe ein komplett neues Skript aufgesetzt, sodass ich alle Funktionen neu und ggf. besser ausführen kann. Ich wollte dabei auch die Möglichkeit nutzen, das Lua-Skript in einzelnen Files aufzuteilen und die Teile durch require() zu laden, sodass alles übersichtlicher wird. Nun zum eigentlichen Problem. DIe Skriptteile sind dazu im .rar file im Anhang, sodass sie direkt in den RSSLO/OBB4010/RailVehicles/Engine/Script-Ordner kopiert werden können.


    Wenn ich im Throttle-Teil die ThrottleScript Liste public lasse (also ohne local) und am Ende nicht returne und ich im Main-Script einfach ThrottleScript.Update... benutze, bekomme ich in LogMate keine Errors und das Skript gibt meine Prints aus. Der Fahrschalter ingame bleibt jedoch auf der 0-Position und geht nicht in die in der .bin definierte Default-Position. Auch lässt er sich nicht über die Tastatur steuern.


    Mache ich jetzt die ThrottleScript-Liste lokal und returne sie am Ende, sodass ich im Main-Skript die kleingeschriebene Variable throttleScript.Update... benutze, bekomme ich im Logmate den Error weiter unten. Das macht ohnehin nach meinem Lua-Verständnis schon wenig Sinn. Das Verwunderliche ist aber, dass nun ingame die Default-Animationen funktionieren!? Also bei mStart wandert der Fahrschalter in die in der .bin definierten Default-Position und er lässt sich auch über die Tastatur steuern. Jedoch nur der Fahrschalter, alle anderen Hebel nicht.


    In keiner Dokumentation konnte ich nachvollziehen, wie die Animationen in der .bin mit dem Script zusammenhängen und ob oder was was überschreibt!? Wieso funktioniert die Animation, wenn das Skript nicht funktioniert? Aber eben auch nur für den einen Schalter? Kann mich da bitte jemand aufklären? Ich verzweifle damit gerade sehr.


    Laut meinem logischen Verständnis sollte dann ja jede Default-Animation immer funktionieren, solange das Skript nicht brute-force einen Wert direkt setzt, wenn man eine Taste drückt, und vor allem sollten sie immer funktionieren, selbst wenn das Skript zum Beispiel völlig leer ist!?

    Ok verstehe, ich versuch's dann mal, in den gleichen Ordner zu geben. Das erklärt aber trotzdem nicht, warum die Default-Animationen und auch die Rasten, die in der .bin definiert sind, funktionieren, wenn das Skript nicht funktioniert,aber nicht mehr funktionieren, wenn das Skript geht.


    Edit: Die Position macht keinen Unterschied. Wenn es gefunden wird, liegt es als Boolean-Value vor und wenn es nicht gefunden wird, dann crasht das ganze Skript. Wenn das ganze Skript crasht, dann sind die Rasten und Animationen auch weg. Irgendwie nur, wenn ich den Fehler habe, dass das throttleScript als Boolean-Value versucht wird zu indizieren, dann sind die Animationen und Rasten aus der .bin vorhanden.

    Eventuell verstehe ich Deinen Ansatz nicht, aber wenn Du das Originalskript mit "require" einbindest, "kaufst" Du das Verhalten aus dem Orginalskript mit.


    Wenn Du zB eine Zugsicherungsvsariante einbinden willst, die das Orginal nicht hat, dann ist das eine valider Ansatz, weil Du hinzufügst, nicht überschreibst.


    Für eine Veränderung vorhandenen Verhaltens, müsstest Du das zentrale Skript neu aufsetzen, sonst kämpfst Du mit dem Verhalten aus dem Orginalskript.

    Zitat von SeKu

    Eventuell verstehe ich Deinen Ansatz nicht, aber wenn Du das Originalskript mit "require" einbindest, "kaufst" Du das Verhalten aus dem Orginalskript mit.


    Wenn Du zB eine Zugsicherungsvsariante einbinden willst, die das Orginal nicht hat, dann ist das eine valider Ansatz, weil Du hinzufügst, nicht überschreibst.


    Für eine Veränderung vorhandenen Verhaltens, müsstest Du das zentrale Skript neu aufsetzen, sonst kämpfst Du mit dem Verhalten aus dem Orginalskript.

    Ich will ein komplett neues Skript schreiben. Also alles von neu auf, aber aufgeteilt, sodass es leichter maintanable ist. Auf das Aufteilen kann ich sosnt auch fürs erste verzichten, das für mich grade Wichtigste ist, warum die Animationen und Rasten aus dem .bin file da sind, wenn das Skript mir den Error gibt, dass das require einen boolean gibt, den es natpürlich nicht indizieren kann, aber die Rasten und Animationen weg sind, wenn das Skript entweder komplett crashed oder keinen error gibt.

    Also ich fürchte, Du hast da schon einen Fehler im "require" Vorgang, bei der V200 habe ich folgende Zeilen im Hauptskript:


    ##

    Ich würde erwarten, dass es eigentlich in der Animation einfach eine Bewegung des Hebels gibt. Ob die einzelnen Frames der Animation an bestimmte Positionen oder Raststellungen orientiert sind, oder in linearen Animationen auf/ab, links/rechts oder aufgeteilt auf, ab, links, rechts vorliegen, hängt vom Autor ab.


    Aber neben dem Namensraum für Objekte, den man als Entwickler frei wählen kann, innerhalb der TSC Vorgaben, gibt es reservierte Namen, die dann die Mechanik fest eingebaut von "Kuju" oder besser dem TSC bekommen.

    reverser, horn, sander guck am Besten in die Dokumentation, gibt es bei ChrisTrains.com.

    Hier würde man VirtualControls einsetzen, um das Verhalten des TSC zu korrigieren.

    So kann man zB Druckluftbremsen und Hauptluftleitung in eine Bremssimulation auslagern, um das gewünschte Verhalten zurück an den TSC zu geben und die Ausgabe der Anzeigen im Führerstand daran auszurichten.

    Umgekehrt, könntest Du so Positionen/Stellungen der Hebel auslesen und für deine Simulation nutzen.

    Ja voll, das ist mir klar. Mein Problem liegt aber etwas woanders. Wenn ich mir den Eintrag vom Fahrschalter in der 4010_A.bin anschaue, wie RSSLo ihn definiert hat, dann sehe ich da eine Animation, die verlinkt ist, und fest definierte Raststellungen. So wie ich den Teil bei ChrisTrains in der Dokumentation verstanden habe, sollte damit automatisch bei dem jeweiligen Tastendruck der Fahrschalter auf/abschalten mit der gegebenen Animation und vor allem in den definierten Rasten einrasten, ohne, dass ich das manuell nochmal im Skript einfügen müsste. Das Problem ist jetzt, wenn mein neues Skriptfile leer ist oder ohne Errors funktioniert, kann ich den Fahrschalter nicht mit der Tastatur drehen und wenn ichs per Drag-and-Drop mit der Maus mache, bleibt er einfach dort stehen, wo ich ihn loslasse, und rastet nicht in den definierten Positionen ein. Wenn das Skript abstürzt, ebenfalls. Wenn ich im Skript nur den Fehler habe, dass das require einen Boolean zurückgibt, wie oben beschrieben, dann ist der Fahrschalter beim Start der Simulation in der definierten Defaultposition, er lässt sich über die Tastatur steuern und rastet auch in den definierten Stellungen ein. Genau das verstehe ich nicht: Warum funktioniert das nur, wenn das Skript einen Fehler ausgibt, und nicht, wenn es entweder leer ist oder nur Funktionen hat, die ohne Error funktionieren!?


    Weil LUA nicht so logisch kompiliert, wie man sich das wünschen würde. Leider hast Du Fehler im Skript, die sich unter einer bestimmten Bedingung aufheben und dann das Default Verhalten zulassen, wäre mein Erklärungsversuch.


    Dein Hauptskript und dein eingebundenes Skript haben Fehler, die zwar kompilieren, aber logisch nicht funktionieren können, soweit ich es beurteilen kann.

    Das Hauptskript müsste auf den von mir beschriebenen "require" Ansatz umgestellt werden und das Nebenskript hat umständliche Funktionsnamen, die Probleme verursachen könnten, oder korrekt aus dem Hauptskript aufgerufen werden müssten.


    Und nur weil ich eine Variante kenne, heißt das nicht, dass ich alle möglichen Varianten kenne.

    Ich versuche Dein Skript anzupassen und schicke es Dir hier zurück, damit Du testen kannst.

    Danke dir fürs Umschreiben. Die Rasten und auch die Animationen und die Steuerung mit der Tastatur funktionieren jetzt auch für alle anderen Hebel, aber ich bin dennoch etwas verwirrt.


    Die erste Verwirrung ist mit dem "require", weil der einzige Unterschied zwischen deiner und meiner Version ist, dass ich die throttleScript-Variable lokal definiert habe. Das sollte doch egal sein, oder? Oder muss das require ganz am Anfang immer stehen, weil du das VirtualThrottle auskommentiert hast?


    Meine 2. Verwirrung betrifft das if(ControlExists) SetControl in Bezug auf die Animationen, definiert in der .bin. Muss ich zwingend im Skript jede Veränderung von einem ControlValue mit einem Set weiterleiten? Wenn das Skript nämlich z. B. leer ist oder alle Methoden leer sind und ich dieses If-Statement nicht habe, dann funktionieren die Animationen auch nicht mehr? Nach meinem logischen Verständnis sollten die Animationen und Rasten, die in der .bin gesetzt sind, nicht unabhängig vom Skript funktionieren und das Skript dann eben nur Verbindung schaffen zwischen der Eingabe am VirtualThrottle und der Berechnung für die Leistung durch die Stufe, z. B.?


    Das dritte betrifft die Struktur der Subfiles generell. Ich komme aus der Richtung C#, Java und etwas C++, wo ich andere Files alleine zur Definition von Klassen oder einzelnen Funktionen nutzen konnte, ohne die gesamte Anwendungsstruktur zu haben. Ist das in Lua nun anders? Offenbar brauche ich im ThrottleScript ebenfalls eine Initialise-, Update- und OnControlValueChange-Methode. Brauche ich das für jedes Subfile von meinem Main-Script im Train Sim? Kann ich nicht aus der OnControLValueChange aus dem Mainfile direkt die UpdateTargetPosition-Methode aus dem ThrottleScript-Subfile verwenden, muss ich immer den Umweg über eine eigene OnControLValueChange-Methode gehen?


    Im vierten bin ich verwirrt, wie Lua jetzt genau die Funktionen benutzt. Nach der throttleScript-Variable führst du throttle_Initialise als Initialise usw. ein. Ist das jetzt die Initialise aus dem Main-Skript oder aus dem Sub-Skript? Wenn beide gleich heißen, woher entscheidet der Compiler, welche Version und wie sind dann jetzt überhaupt die Initialise, OnControLValueChange etc. aus dem Subskript mit dem Main verbunden? Die Struktur verwirrt mich sehr gerade.


    Abschließend hast du die VirtualThrottle-String-Deklaration nur auskommentiert, weil du sie nicht brauchst, oder hat das Lua im Train Sim etweas dagegen, wenn locale Variablen im Script so heißen, wie Objekte in der .bin, die dann als Namen übergeben werden in der ControlValueChange, z. B.?

    Ich habe auch eher einen c#/c++ Grundstock im Kopf, bin aber auch hier ein Amateur und kein Profi.

    1.Verwirrung(hoffentlich)

    Du kannst schon mit lokalen Funktionen arbeiten, die habe ich in Deiner Throttle LUA Datei erhalten und nur namentlich angepasst. Du kannst sicher auch mit deinem Grundansatz weiter kommen, und den Funktionsnamen direkt aufrufen. aber ich habe Dir gezeigt, was für mich funktioniert.

    Dadurch dass ich einen Teil der TSC-"Boilerplate" in jedem Skript mitliefere, habe ich bestimmt auch Nachteile, kann aber wie Du beschrieben hast, die Systeme voneinander getrennt halten.


    2.Verwirrung:

    Ich habe schon einmal die These hier im Forum aufgestellt, dass diese zentrale LUA auch immer die Werte der Controls "durchreichen" muss und bislang hat niemand, der es besser beschreiben kann, widersprochen.


    Allgemeine und geteilte Verwirrung😉:

    Viel ist nicht wirklich LUA abhängig, sondern soweit wie ich es verstehe, der Art geschuldet, wie das Skripting im TSC funktioniert oder besser welche eingebauten Werte manipuliert werden müssen.


    Mein PZB Skript ist sehr ähnlich aufgebaut, aber inzwischen mit richtiger StateMachine und lokalen Funktionen, um auch alle überlagernde Beeinflussungen korrekt darzustellen und den ausgewählten Führerstand zu berücksichtigen. Da wird es demnächst ein Update für das V200 Paket geben.

    Aber ich habe zB meine G320b immer noch nicht fertig, weil ich nicht glücklich mit der Steuerung und insbesondere der Bremssimulation bin. Scheitert am Zeitmangel im Moment.


    Lösungsansatz für Profis und Amateure mit etwas Zeit:

    Was sehr empfehlenswert ist und ich von Spikee1975 erfahren habe: Guck Dir die Skripte von Armstrong Powerhouse an.

    Eine Empfehlung direkt von mir:

    GitHub - JachyHm/RailWorksLUAscriptExamples: Example LUA scripts for RailWorks.
    Example LUA scripts for RailWorks. Contribute to JachyHm/RailWorksLUAscriptExamples development by creating an account on GitHub.
    github.com

    ist sehr aufschlussreich.


    4. Verwirrung

    Das ist eine Art von Vererbung, soweit ich es verstehe. LUA bietet das nativ nicht und so umgeht man diese native Einschränkung, soweit mir bekannt.