Beiträge von Maik Goltz

Die Probleme können vielschichtig sein. Nur weil eine Aufgabe funktioniert und alle anderen nicht, heist das dennoch nicht, dass es an den Aufgaben oder Fahrzeugen liegt. Das kann auch ein defektes Asset in der Strecke sein. Es gibt viele Probleme im TS die sich nicht regelmäßig reproduzieren lassen und so den Anschein erwecken es würde nicht mit fest verbauten Assets zu tun haben. Aber auch diverse Fahrzeuge machen gern Probleme wenn sie als KI fahren. Ich hab gesamt sicher schon wochenlang nach Fehlern in meinen Scripten gesucht, die letztlich gar nicht da waren, sondern von anderen Fahrzeugen verursacht wurden. Der LogMate ist da keine sonderlich tolle Hilfe, da er bei vielen Fehlern nicht genau sagt was und wo. Das gleiche Problem kannst du da auch grad haben. Ein sich aufhängendes LUA Script (zB eine Endlosschleife) verursacht auch so einen Absturz. Ist aber sehr schwer zu finden so ein Verursacher. Da braucht man viel Zeit und Geduld. Die findet man natürlich nicht zwischen Kindern und Strandausflügen. Ich wette der Fehler ist an der Strecke zu suchen. Das hatten wir ja alles schon zur Genüge.

Wenn du etwas zeitverzögert laufen lassen willst dann brauchts du entsprechende run-up und run-down Konstrukte mit Sollvorgaben und Ist-Werten. Der Hebel legt die Sollvorgabe fest und startet den Run. Dort wird dann geschaut ob Soll < oder > oder = Ist-Wert ist und etsprechend addiert oder subtrahiert (mit time/irgendwas für eine gleichbleibende lineare Bewegung oder auch mit anderen Spielerkens wie beschleunigter Bewegung über Pow() oder mit einem lerp mit 4 Werten). Wenn Soll == Ist wird der Run unterbrochen. Die Hebelstellung wird zwischengespeichert und gegengeprüft. Erst wenn der Hebel nicht mehr mit dem gespeicherten Wert übereinstimmt wird der Sollwert wieder vorgegeben und der Run gestartet. Das funktioniert ziemlich zuverlässig. Wichtig ist dass der Run unterbrochen wird wenn die Sollvorgabe etwa erreicht ist (wenn soll < ist + 0.001 dann ist = soll und run stop).

Zitat von eisenbahnfan110

Ich lass einfach mal die Ktze aus dem Sack: Ich wollte bei der vR 103 die automatischen Lüfter ab Fharstufe 1 aktivieren

Wozu? Die Lüftersteuerung ist vorbildgerecht umgesetzt.

Zitat von Taurus0815

Mach das doch über die Sound Blueprints. Die out ist nicht zu knacken und aus.

Geht nicht wirklich, sei denn man will die Soundkulisse zerstören.

Hast du denn schon irgendwelche Programmiererfahrungen? Die wären durchaus angebracht, sonst verstehts du das auch nicht was ich dir sagen will. LUA an sich ist super einfach. Das bisschen Syntax ist an einem Tag erlernt, aber das zaubert noch nix hervor. Es ist einfacher ausserhalb des TS damit was zu programmieren als für den TS. Der hat halt seine Eigenarten und man hat nur wenige Dinge an die man sich "anheften" kann. Du musst viele der Unzulänglichkeiten (zB fehlende Events) umschiffen. Das wird um so schwerer je komplizierter die Systeme sind die man umsetzen möchte. Vor allem Vorgänge die von Werten des TS abhängen sind manchmal schwer in den Griff zu bekommen weil die gelieferten Daten teils wirr und unberechenbar sind. Das muss man ausgleichen sonst bekommt man falsche Ergebnisse. Dein obiges Beispiel aber ist fehlende Erfahrung in der Programmierung. Du fragst den Hebel ab ob er dem Wert der Bremse entspricht. Tut er es nicht würde man jetzt eben den Wert des Hebels auf die Bremse schreiben. Du aber schreibst time/2 auf die Bremse und so wird "Fbv" niemals "Fuehrerbremsventil" sein, die Bedingung also nie wahr. Oder war dein Ziel eine Zeitsteuerung? Das geht dann aber völlig anders.

Ja, da sieht man dass du noch nichts verstanden hast. Das ist doch was ich dir mit meinem Scriptschnipsel aufzeigen wollte. Dauerfeuer unterbinden durch das zwischenspeichern und prüfen der Werte. Du musst da noch viel Grundkenntnisarbeit bei dir leisten bevor du sowas wie ein enkoppeltes FBrV coden kannst. Ausserdem solltest du dir mal VirtualBrake anschauen statt einen eigenen Controller für den enkoppelten Hebel zu erfinden. Und was bitte soll math.abs(time) ? Weist du überhaupt was math.abs macht?

Du hast keinen "Source" Ordner in deinem Railworks Verzeichnis. Den benötigst du aber. Lege diesen einfach an und der BPE2 sollte starten. Ausserdem den BPE unbedingt als Admin starten.

Zitat von siebziger

...X Box Controller ..... Der ist ja hier leider mega-out, obwohl ich nicht glaube, dass die Verreiß-Kollegen den auch wirklich mal getestet haben

Das Problem beim X-Box Controller ist, dass man diesen nicht konfigurieren kann. Der greift einfach hintenrum auf die F4 Kontrollen drauf (aber mit Fehlern). Das ist schlecht da das Event OnControlValueChange dabei nicht ausgelöst wird und man die Eingaben am Controller so nicht im Script auswerten kann, ohne ein riesen TamTam zu coden, das dann auch noch höchst inperformant ist. Von daher ist das verreißen des Controllers schon ok. Denn der ist nur halbherzig und fehlerbehaftet implementiert worden. Bei den Fahrzeugen die nichts weiter können ausser fahren ist das soweit ok. für erweiterte Dinge ist das extrem schlecht. Leider ist der X-Box Comtroller bei DTG das Maß der Dinge.

Die App ist nett aber irgendwie auch nichts besseres als ein wireless keyboard. Echte Tasten sind sowieso besser bei solcher Bedienung als welche bei denen man kein haptisches Feedback bekommt wie bei einem Tablet. Wenn auf der Couch dann mit X-Box Controller (und den entsprechenden Einschränkungen). Alles andere ist zu kompliziert und unübersichtlich für die Couch.

Wo hast du die BR111 denn gekauft? Bei Steam oder bei vR? Die beiden unterscheiden sich (nicht nur im Pfad).

Die Dumps sind mit MS VS zu öffnen und bringen dir auch dann null Information. Dort steht lediglich immer das selbe drin. Nämlich eine Speicherzugriffsverletzung in einem Adressbereich der sich aber stets ändert. Letztlich ist das nichts weiter als die verschlimmbesserte Version von SBHH.

Die einzig funktionierende Antivieren-Internetsecurity-Antitrojan-Antimalware-AntioNSA-AntiAntiContra-Software befindet sich in dem rundlichen Behältnis, welches die meisten auf dem Hals tragen (heutzutage zumeist, im Mittelalter ein bisschen weniger). Dieser auch Kopf genannte Rundkörper hat Inhalt (zumeist reichlich) und dieser Inhalt ist die perfekte Laufzeitumgebung für Anti-Alles-Software. Der Rest ist nur Geldmacherei und Panikmache.

Naja, ich wollte dir nur aufzeigen wie man aktiv mögliches Dauerfeuer unterbindet und kein fertiges Rezept auf den Tisch legen. Sowohl beim Controller SifaWeg als auch bei der SifaReset Tastenabfrage is das unterbinden wichtig. Wozu eine Taste in jedem Frame auswerten und bei jeden Wert wenn ich doch nur 1 oder 0 und auch nur je einmal benötige. Das sind essentielle Dinge die man verstehen muss, sonst schreibt man Scripte die nicht gut funktionieren werden und die Spielperformance im Zweifel beeinträchtigen.

Naja, ne sonderbar gute Lösung ist das auch nicht. Zumal da ein Fehler drin ist. So könnte das aussehen. Hab ich nur mal eben "hingeschmiert". Das soll dir nur den richtigen Ansatz zeigen.

function Initialise()


    local wegstreckeIst = 0;
    local sifaState = 0;
    local sifaZwb = 0;
    local sifaMemory = 900;
    local sifaTasterState = 0;

    Call("BeginUpdate");
end


function Update(time)


    local simSpeed = Call("GetSpeed");

    --- Wegstrecke ---
    wegstreckeIst = wegstreckeIst + (math.abs(simSpeed) * time);

    -- SIFA --
    if(sifaState == 0 and (sifaMemory + 900) < wegstreckeIst and sifaZwb == 0) then
        sifaState = 1;
        Call("SetControlValue", "SifaWeg", 0, sifaState);
     elseif(sifaState == 1 and (sifaMemory + 975) < wegstreckeIst and sifaZwb == 0) then 
         sifaState = 2;
         Call("SetControlValue", "SifaWeg", 0, sifaState);
      elseif(sifaState == 2 and (sifaMemory + 1050) < wegstreckeIst and sifaZwb == 0) then
          sifaState == 3;
          sifaZwb = 1;
          Call("SetControlValue", "TrainBrakeControl", 0, 0.7);
    end


end


function OnControlValueChange(name,index,value)
    if(name == "SifaReset") then
        if(value == 1 and sifaTasterState == 0) then
            sifaTasterState = 1;
            if(sifaState ~= 0) then
                sifaState = 0;
                Call("SetControlValue", "SifaWeg", 0, sifaState);
            end
            sifaMemory = wegstreckeIst;
            if(sifaZwb == 1) then
                Call("SetControlValue", "TrainBrakeControl", 0, 0);
                sifaZwb = 0;
            end
         elseif(value == 0 and sifaTasterState == 1) then
             sifaTasterState = 0;
        end
    end
end

weg = weg + (m/s * deltaTime)

Aber bei dem Konstrukt da oben musst vorsichtig sein. Denn so produziert das nutzloses Dauerfeuer. Du musst Wegmessung zwischenspeichern und gegenprüfen um den Vorgang nur auszulösen wenn nötig. Performance im Script ist bei kleineren Scripts zwar egal, aber man kommt ganz schnell an die Grenze und muss dann anfangen zu optimieren. Vor allem Dauerfeuer auf Calls und unnötig viele Calls müssen vermieden werden. Jeder Call verursacht eine messbare Scriptlaufzeitverlängerung.

also dann:
-- variable inizialisieren
local weg = 0;
local wegmessung = 0;

-- im Update(time)
local simSpeed = Call("GestSpeed"); -- will man ja vll mehrfach verwenden

weg = weg + (math.abs(simSpeed) * time);

if(weg > 900 and wegmessung ~= 1) then
wegmessung = 1;
Call("SetControlValue", "Wegmessung", 0, wegmessung);
-- hier dann vll weg zurücksetzen (würde ich aber nicht machen sondern eine weitere var zum zwischenspeichern von wegpunkten)
weg = 0;
end

....

Oltankwagen mit offenliegenden Scripts? Ich glaub du verwechselst da was. TrainBrakeAmount ist ein AudioProxyTriggerValue und wird im AudioProxy Blueprint abgefragt und nicht in einem Script. Diese speziellen AudioTrigger kann man auch gar nicht per Script auswerten. ControlValues sind auch nur ControlValues, also Controller die im Fahrzeug zu dem das Script gehört auch eingebaut sind. Wenn BrakePipePressurePSI nicht verbaut ist, kann man es auch nicht abfragen oder auswerten. Bei einem deutschen Fahrzeug ist das auch eher BrakePipePressureBAR. Da musst du noch viel ergründen wenn du Ergebnisse möchstest. Das ist aber auch alles keine Magie. Das kann man lernen und ergründen. Gibt halt keine Anleitungen. Man muss alles selbst rausfinden.

Aus dem Wagen heraus das abzufragen ist kaum möglich. Ausserdem muss erst mal ein HS definiert sein. Den Startup Parameter dafür zu nutzen ist vergeben Müh. Also erst mal einen HS erfinden und programmieren. Dann muss die Lok diese Info über ConsistMessage an die Wagen senden (natürlich nur wenn es nötig ist). Dies werten das dann aus und machen irgendwas in ihrem eigenen Script damit. In Wagen geht auch nicht alles was in Loks geht. Man kann auch nicht auf Werte anderer Fahrzeuge einfach zugreifen. Das muss immer durch den Consist gejagt werden. Mit anderen Zügen kommunizieren ist zB. mehr oder minder unmöglich im TS. Viel Spass...

Nein, gibt es nicht für den TS. Scripte im TS bestehen zu 95% aus Ideen und der dazu entsprechend erstellten Logik. Rezeptbücher sucht man da vergebens.

Nein, das wäre 08/15 und funktioniert nicht immer. Entweder beide Animationen als eine IA Datei exportieren, dann bewegen sich beide zusammen. Oder die stets besser Variante ist das Scripting, was aber meist ziemlichen Overhead für so einfache Dinge darstellt.

Zitat von StS

Damit bleibt das Betriebsgeheimnis gewahrt.

Das klingt so vorwurfsvoll. Ist es nicht erlaubt die Arbeit geschützt, oder sagen wir besser unveränderbar zu wissen?

Zitat von HORCHman

Tja, die Freeware-Szene wird wohl schon spürbar stark (bei den Kommerziellen wahrgenommen)... Ein Schelm, wer böses dabei denkt

Nicht nur die Freewareszene. Auch ich sitze hier und stürtze ab. Tja, müssen wir mit leben. Dauert eben alles noch viel länger als bisher. Oder alternativ die Funktionsvielfalt derbst zurückschrauben. Das wird langsam unwirtschaftlich alles. Tagelanger Ausfall wegen Updatefehlern. Instabiler Programmablauf. Fehlende Dokumentationen. Und noch ne Menge anderer Unstimmigkeiten.

Das .ap Format dient nur der schnelleren Validierung über Steam. Ob das wirklich besser ist als die kleinen Dateien zu prüfen, lassen wir mal dahingestellt. Denn es geht wohl schneller eine 2kb Datei zu laden als eine 1,7gb .ap Datei. Da hat man es sich nur einfach gemacht.

Den Unreal Engine Coder haben sie bisher noch gar nicht gefunden, denn die Stellenausschreibung ist noch da. Wird auch nicht so sonderlich einfach sein für DTG einen zu finden der das alles kann was die wollen. Da braucht man eher 3-4 UE Coder bzw grundsätzlich 4 Leute. Das wird aber zu teuer (ist anzunehmen).

Dass die Herren da drüben nicht so genau aufpassen mit dem Updates zeigte sich ja beim letzten. Wieso ist auf einmal die Einstellung der ContactWireNode anders bei den OL Masten? Wieso ist das Icon weg. Wieso stürtzt der TS neuerdings viel öfter im Editor ab (um nicht zu sagen ständig)? Wer hat das entschieden, warum wurde es nicht mitgeteilt, wieso ist das Universum so groß und was kommt dahinter? Alles offene Fragen... Mit Zukunftsfähigkeit hat das wenig zu tun. Wenn die Zukunft so kaputt auschaut na dann prost.