Trs19: fehlerhafte HL- und Sperrsignale

1. offizieller Beitrag

    Guten Abend,


    Ich habe feststellen müssen das Signale von "Cj187" z.Bsp. Die Sperrsignale, oder die HL Signale von "scara" im CM Skriptfehler aufweisen, und somit nicht nutzbar sind. Auffallend ist, dass die "BUILD IN" Objekte nicht fehlerhaft sind.


    Sind Updates der Objekte in Arbeit?


    Die Meldung selbst werde ich morgen früh hier anhängen , wenn ich von der Arbeit heim gekommen bin.


    Hinweis: ich nutze die Release Version von TRS2019.


    Grüße.

    Denken, ist manchmal so, als würde

    man Wissen auskotzen!!

    Zitat von Br234304

    Auffallend ist, dass die "BUILD IN" Objekte nicht fehlerhaft sind.

    BuildIn Objekte werden durch N3v immer als "fehlerfrei" markiert. Unabhängig ob "Fehler" (bzw. seit der 19er Version als solche eingestuft) vorhanden sind oder nicht. Die Objekte laufen dann, weil die Fehlerprüfung durch das Programm selbst ausgehebelt wird.

    Hallo interling,


    Dies hatte ich bereits vermutet. Danke für die Bestätigung.


    Nur, ist diese Information für eine Fehlerbehebung nicht sehr hilfreich.

    Bzw. Beantwortet sie nicht meine Frage.


    Dennoch danke.


    Gruß.

    Denken, ist manchmal so, als würde

    man Wissen auskotzen!!

    Einmal editiert, zuletzt von Br234304 ()

    • Offizieller Beitrag

    Ich hatte bisher noch nicht das letzte Update der HL Signale (vom 10.10.2018) installiert. Soweit ich das im Moment überschaue, funktionieren die HL Signale mit <kuid2:83501:######:5> im aktuellen Trs19 zunächst fehlerfrei. Jedoch muss das Update auf KUID mit Endziffer 6 auch einen Grund gehabt haben und der hat vermutlich mit den Interlocking Towers zutun. Inwieweit nun Trs19 + IT(EIT) + HL Signale mit Endziffer 5 völlig fehlerfrei funktionieren, kann ich aktuell nicht sagen.


    cheers

    Christian


    Durch eine fehlerhafte Serverkonfiguration sind leider die Anhänge in diesem Beitrag verloren gegangen. Weitere Informationen siehe hier.
    Due a server misconfiguration, the attachment(s) of this post became lost. For further information see here.

    4.5 bei alle die Fehler auf 4.4 die Build Nummer setzen, und es geht wieder alles.


    Gruss Blacktiger und schöne Festtage.


    Durch eine fehlerhafte Serverkonfiguration sind leider die Anhänge in diesem Beitrag verloren gegangen. Weitere Informationen siehe hier.
    Due a server misconfiguration, the attachment(s) of this post became lost. For further information see here.

    Den Scriptfehler habe ich Christopher (CJ187) bereits gemeldet und auch eine Möglichkeit diesen zu beheben. Bei den neuesten Builtin-Versionen der Signale wurde anscheinend diese Korrektur durchgeführt.


    Für alle, die nicht auf ein Update warten wollen, hier die Korrekturen:

    Es betrifft die Formsignale ab <kuid2:404575:101530:1> Form-Hauptsignal 8m Hp0/Hp2 .

    Zur Korrrektur habe ich in der Scriptdatei hlsignal.gs etwa hinter Zeile 1654 einen inherited-Befehl eingefügt:

    Code
    public void SetProperties(Soup db) {
inherited(db); // neu eingefügt

    Die Licht-Sperrsignale ab <kuid2:404575:1870305007:11> |CJ| Licht-Sperrsignal SEL (links) 2.25m sind ebenso betroffen.

    Dort erfolgt die Korrektur in der Datei sperrsignal.gs etwa hinter Zeile 799. Es wird die selbe Änderung wie bei den Formsignalen benötigt.


    Die Korrektur für die Signale von Scara ist ähnlich. Wie im obigen Fehlerbild ersichtlich muss die Datei hlsignal.gs einige Zeilen vor Zeile 877 korrigiert werden (dort sollte ebenfalls die Funktion SetProperties beginnen). Bei den neuesten Builtin-Versionen wurde diese Korrektur bereits vorgenommen.


    Peter

    Einmal editiert, zuletzt von p-dehnert ()

    Guten Morgen - sind die Signale nach dem Update mit den ILT verwendbar oder weshalb wurden die Scripte verwendet ? Gruß Thomas