Signale <kuid:83501:24503> bis <kuid:83501:24551>

  • Hallo,
    bei den Signalen <kuid:83501:24503> bis <kuid:83501:24551> (in der DLS aktuell als :6) kommt es in TRS19 zu einem Scriptfehler.
    3 von der Sorte -> function GetGameObject is obsolete in object Router.
    2 von der Sorte -> function SetSignalState is obsolete in object Signal.
    und ein mal 'inherited' not yet called within mandatory function.
    Den Inherit Fehler würde ich gefixt bekommen, da gab es hier im Forum zu einem anderen Signalpack ein Tip.
    Bei den 5 anderen Positionen weis ich keine Vorgehensweise. Hat jemand ein Tip oder kann sonst wie hilfreich wirken?
    Andere Tips z.b. mit "runterdrehen der Build Version" o.ä. haben bisher nicht geholfen.

    Es wäre schön wenn man die Signale fixen könnte, da sie auf alten Anlagen stehen, die auch in trs19 lauffähig wären. In meinem Fall hier Netzbezirk Wittfeld.
    Da die Signale mal ursprünglich hier aufgelegt wurden ("VEB TrainzDepot"), ist das ja vielleicht auch der richtige Ort für Nachfragen dieser Art.
    Gruß

  • Stimmt, hatte ich vergessen... warum sollte man für ein Eisenbahnsimulator mit deutschen Strecken auch deutsche Signale verwenden.... das war schon vor 10 Jahren problematisch...
    Hab die Unterschiede der Versionen 5 aus dem TS12 und 6 im TRS19 mal überflogen. Um alte Strecken schnell zum Laufen zu bekommen ist das umstellen auf die :5 vermutlich die einfachste Wahl. (Damit funktionierte sie ja mal.) Allerdings hat sich der Scara ja wohl was dabei gedacht als er in die :6 ca. 10 KB mehr Code rein programmiert hat...auch wenn es nicht ganz Fehlerfrei ist. Ich bin unentschlossen... und vor allem zu lage aus dem Thema raus, als das ich da was bewegen könnte. Also bleibt mir erst mal nur meine Anfrage an das Schwarmwissen hier...

  • Also... Erkenntnisse stellen sich ein...

    Wenn man im Script hlsignal.gs an passender Stelle das Andernorts besagte inherited(db); einfügt, kann man die Signale im CM ohne Fehlermeldung submitten. Bei mir werden sie erst noch "Faulty" angezeigt... macht man ein Doppelklick auf das betreffende Signal, springt es um auf "Modified" und läuft dann normal. Es produziert danach auch keine Warnings mehr wenn man "view errors & warnings" laufen lässt.
    Im Prinzip wären Sie damit also gefixt und bereit um auf die DLS hochgeladen zu werden. Das schaut dann so aus:

    public void SetProperties(Soup db) {

    inherited(db); // *fix <-----############

    name=db.GetNamedTag("name");

    defaultLimit=db.GetNamedTagAsInt("defaultLimit",0);

    nextSignalID=db.GetNamedTagAsGameObjectID("nextSignalID");



    Ob damit dan auch die korrekte Funktion gegeben ist, kann ich noch nicht sagen. Mir sind aber weitere Dinge aufgefallen:

    1. Die Scripte zum Vorsignal(widerholer) sind bei gleichem Namen etwas anders aufgebaut als die Signale, was zwar Sinn ergibt, da Vorsignale dumme Trackobjekte sind und Signale eben Signale. Es fällt jedoch auf, das auch diverse Zeilen, insbesondere zum hoch zählen einer Var (++i oder i++) unterschiedlich sind. Es macht schon ein riesen Unterschied ob ein Array an Stelle 0 oder 1 geprüft wird. Die Grundidee ein Script für alle Signale zu verwenden ist nicht schlecht... allerdings scheinen es bei der Versionspflege nicht immer alle Änderungen vom Signalscript ins vorsignalscript geschafft zu haben.


    2. Ich möchte daher eine Namensänderung des Vorsignalscripts anregen. hlvorsignal.gs z.B. und ggf müsste man das incrementelle Zählen mal genauer unter die Lupe nehmen. Ich vermute hier Fehler und inkonsistenzen. Es wäre jedenfalls fatal wenn jemand die hlsignal.gs der Vorsignale mit denen aus den Signalen überschreibt.

    3. Die Signale sind heute vorbildlich mit einem lm script für das lod, aber nur mit einem mesh ausgestattet. Schöner wäre ein invisible mesh als entferntes Mesh an dem zwar die Att Punkte für die coronas eingetragen sind, was aber ansonsten keine Rechenzeit beansprucht. Damit ließe sich der Renderaufwand für die Signale reduzieren ohne die eigentliche Funktion zu beschränken. Setzt man dann z.b. den lod Abstand auf sagen wir 400m, werden zwar auch Signale in 1000m berechnet und Coronas/Signalbilder angezeigt, aber die Mastberechnung als mini-Pin in der Landschaft entfällt eben. Zumindest könnte man das mal testen. Die Lage der Atts für das imesh bekommt man über AssetX raus.
    Ich bin leider grade nicht in der Lage meshes zu bauen. Vielleicht hat jemand von euch die Möglichkeit?


    Gruß

  • ...was ja auch schon mal ein Schritt wäre... Die Programmfehler kann ich jetzt auf die Schnelle nicht beheben. Aber man sieht, das es gute Gründe gibt, sich damit zu befassen und das :6er weiter zu entwickeln - und eben nicht auf alte Scripte zurück zu gehen,

    Aber ich wollte eigentlich nachtragen, das man sich das mit dem Erstellen der invisible Meshes für das LOD in der CAD Software sparen kann.
    Mit dem Attachment Maker von PEV Soft kann man das IM der Signale laden, das so erzeugte Att Mesh mit atts speichern und mit ins LM einbinden. Klappt 1.klassig! Das LM schaut dann so für das Vorsignal aus:



    version 1.0

    offset = 0.01;

    calcpoint = center;

    multiplier = 1.0;

    renderCutOff = 0.01;

    attachmentCutOff = 0.01;

    animationCutOff = 0.01;

    mesh("0.05"){name="attach_mesh.im";}

    mesh("1.0"){name="hl-vor.im";}



    Muss man zwar immer noch für alle Signale ein mal machen, aber das ist schneller erstellt als sowas erst nachzukonstruieren.
    Die Methode eignet sich auch für andere Highpoly Objekte auf der Map, welche Trainz ausbremsen. Ich bastel mal noch ein wenig.
    Gruß

    Einmal editiert, zuletzt von rd65 ()

    • Offizieller Beitrag

    Vielleicht kann p-dehnert ja in Bezug auf das Skript etwas dazu sagen...


    Ich stehe im Kontakt zu scara, wir haben die Erlaubnis, die Objekte zu bearbeiten.

    Unser Grundgedanke ist nun, die Originalversion "nutzbar" zu machen, also einfach eine möglichst fehlerfreie-Variante zu erzeugen und in einem zweiten Schritt aktualisierte und verbesserte Signale unter TrainzDE-KUID zu veröffentlichen, da wären dann zB. LOD-Verbesserungen möglich. Aber das ist Zukunftsmusik.

  • Nur mal so, zur Erinnerung! Die Grundversion wurde damals von @partyman67 geupdatet. Dazu gab es in einem Forum einen Thread, der die Änderungen klären sollte. Leider muß das vor 2009 gewesen sein. Ich kann den nicht mehr finden. Auf meine Fragen, folgten nur ausweichende Antworten.

    Die Originalversion (TRS2004) hatte einen vorkonfigurierten Festeintrag mit 120kmh. Schnellere Vmax Einträge waren nicht möglich. Darüberhinaus gab es einen maßlosen Performanceeinbruch bei mehreren H/V Konfigurationen.

    Nach der Änderung: Die Voreinstellung Vmax -1 (ohne Beeinflussung) + die Möglichkeit der Konfiguration bis 160kmh.

    An der schlechten H/V Konfigurationsperformance hat sich nichts geändert.

    Die nächste Änderung wurde nötig nach einem Servicepack in TRS2006 (Originalversion). Deutsche User bekamen das TRS2007 bereits mit diesem SP. Die H/V Konfiguration funktionierte nicht mehr. Das 2.Update behob diesen Fehler.

    Die wohl grösste Veränderung brachte die geänderte KI/DCC Steuerung (sogenannte "Vorrausschau") im TS2009. Nun ging scheinbar garnichts mehr. Dazu wurden 2 unterschiedliche Signalpakete entwickelt. eines bis TRS2006/2007/TC und eines abTS2009+ Leider ist mir entfallen, wer an dieser Änderung beteiligt war. Das 2.Paket läuft heutzutage noch fehlerfrei in meinen TS10/12 Versionen.

    In meiner T:ane Grundversion (SP2) gehen diese Signale nicht mehr. Ab diesem Punkt habe ich mich auf die DLS verlassen, leider..

    LG Frank

  • Also ich gucke grade in den Code... da gibts die Warning:

    ! <kuid2:83501:24548:6> : VE220: hlsignal.gs(88) : function GetGameObject is obsolete in object Router.

    für folgende Zeile:

    junc[i]=cast<Junction>Router.GetGameObject(njunc[i]);


    Dazu sagt das Wiki eindeutig:


    Router.GetGameObject(int)Much like GetGameObject(GameObjectID), this function would return any loaded object with the integer Router ID passed. As this ID format is now considered obsolete, so is this lookup function. Any scripts which use it should be updated to instead use GameObjectID and that function variant (or the async search functions on World).


    Zwei Zeilen drüber bei GameObject.GetId()steht auch warum:


    All GameObject instances with a Router are assigned a numeric integer ID. This ID was traditionally retrieved via this function. As the ID varies between runs it was never safe for long term storage, but it was suitable for short term storage and lookup. As objects can now be unloaded at any time, and these IDs then reused by totally different objects, the function has been declared obsolete.


    Das Ganze taucht in Funktionen auf, die im Fehlerfall mit Exceptions um sich werfen sollen... also die eigentlich Funktion des Signals nicht beeinträchtigt... denn: Exceptions = Böse!

    Aber... das ist nicht erst seit gestern so ... und es ist offensichtlich einwandfrei dokumentiert. Ich finde es allerdings befremdlich, das Trackobjekte wie Signale vom System "entladen werden können sollen"... und damit quasi stateless sind bzw. zum Ladezeitpunkt abhängig vom LOD erst initialisiert werden. Auch wenn Auran meine Meinung vemutlich nicht interessiert. GameObjektID wird in der Funktion auch genutzt, besser an der Stelle wäre aber vermutlich die globale async search Funktion von der da gesprochen wird. Oder eben die Situation nicht abfangen und den Part raus nehmen um quasi hinten rum auf die funktionalität/arbeitsweise der :5 zu kommen.

    Wie man aber die Nuß jetzt knackt... keine Ahnung.
    Das Problem mit Signal.SetSignalState hab ich mir noch nicht angesehen.

    • Offizieller Beitrag

    Ich glaube die stehen auf der Niddertalbahn (was auch immer HL Signale dort verloren haben?) und wurden dann wieder von anderen externen Leuten bearbeitet.

    Danke für den Hinweis, was ein Chaos. Dann müsste man vielleicht mal alle vergleichen und schauen dass man ein "across the board" update für alle auf :10 macht. Das hab ich vor ein paar Monaten schon bei diversen Signalen von CJ gemacht und die Skripte dabei auch gleich in eine library für schnellere Updates in der Zukunft gepackt.


    Unsichtbare Meshes als LOD sind eine Praxis der Vergangenheit und sollten nicht mehr eingesetzt werden. Da die Signale schon sehr alt sind vermute ich mal dass man sich bei den Materials kräftig ausgetobt und jede Menge davon verbaut hat, was auch nicht mehr der aktuellen Bauweise entspricht... Wenn man sie ab einer bestimmten Distanz ausbleden will sollte dies über mesh-table-lod-transition-distances erfolgen, diese Möglichkeit ist leider erst ab Build 4.6 verfügbar, dann also nicht mit T:ANE kompatibel.



    Greets, Mika

  • 'Nabend zusammen!

    Ich glaube die stehen auf der Niddertalbahn (was auch immer HL Signale dort verloren haben?) und wurden dann wieder von anderen externen Leuten bearbeitet.

    Ein wenig Off-topic meinerseits - man möge es mir verzeihen. Wir haben damals die HL Signale verwendet, da es keine DLS Alternative im Bereich der deutschen Lichtsignale gab.

    Schönen Abend noch! :winking_face:


    Grüße,


    Marcel

  • Meine Überlegung zum LOD Modus war: Wenn ich mir im dunkelen einen großen Güterbahnhof anschaue, habe ich wenig davon, wenn entfernte Signale nicht angezeigt werden. Daher müssen immer alle Coronas leuchten. Aber ich brauche nicht zwangsweise die gerenderten Signalmasten. Die richtige Angabe der Größe ab wann nur die Masten ausgeblendet werden ist natürlich schon wichtig - da bastel ich grade selbst ein wenig rum und nehme gerne Tips an. Mein "Schätzwert" liegt aktuell bei 0.05 was bei 1080 Pixel Bildschirmhöhe 54 Pixel sind. In einer 8K Auflösung auf einem oled wären es natürlich ein paar mehr... aber wer spielt Trainz auf 8k oled? :grinning_squinting_face: Vor Landschaft dürfte sich das optisch gering auswirken. Das ab 4.6 eine neue/andere Möglichkeit bestünde, das genau so umzusetzen mag sein - dürfte aber erst in 5-10 Jahren relevant werden. Das Mesh vom Hl H-100 hat z.b. "nur" 698 Polys, ist dafür aber aber recht detailreich. Alt heisst in dem Zusammenhang also nicht automatisch schlecht gebaut. Eher im Gegenteil!

    Ich fasse mal die bisherigen Posts so zusammen, es besteht auf jeden Fall großes Interesse an einem Fix, die Signale sind leider (noch) nicht besonders performant und wir (damit meine ich alle die interesse haben) dürfen uns an den Signalen austoben. Basti, du hast ne Mail und ich befasse mich mal damit, wie man eine scriptlibrary baut. Das ändern all der Files ist mir zu fehleranfällig.

  • Ein weiterer Funfact... war mir bis eben auch neu!
    Es scheint ja Zweifel zu geben, das die scara Signale modernisierbar sind... hier wurden die Signale von cj187 angesprochen, welche laut einem Forenbericht aus 2016 Tane- und Interlocking kompatibel sein sollen. Also habe ich mir die angeschaut und denke die ganze Zeit: "verdammt, das kennst du doch alles, das hast du eben erst gesehen....". Weiter geschaut und festgestellt, das dieses Signalscript von cj187 Signalbilder

    anzeigen _könnte_, die ein Sperrsignal aber niemals anzeigt... also kurzer Hand die Scripts nebeneinander gelegt und siehe da...

    Ich will jetzt keine unbewiesenen Behauptungen aufstellen, wer damals von wem abgeschrieben hatte... und auch nicht ausser acht lassen, das es zwischen den beiden Scripten doch auch viele Änderungen gibt, die hautpsächlich versuchen Fahrstraßentechnik in die HL Signale rein zu coden... was durch TANEs ITs _eigentlich_ obsolete, aber ggf. wichtig für die Funktion alter Strecken ohne IT ist...

    aber wenn man ein Signalsystem aus "einem Guss" bauen wollen würde... ... ... ist der Ansatz in den Scripten welcher bei beiden gleich ist, sicher nicht der schlechteste!

    Demzufolge müsste man den alten Signalssatz fixen... und einen neuen mit abgespeckten Scripten für Tane und folgende für IT Betrieb auflegen.

    Gruß

    • Offizieller Beitrag

    also wenn sich da was kompatibel machen lässt weil es eh alles auf der gleichen Basis läuft dann kann ich recht einfach dafür sorgen dass die zentrale Library-File von CJ damit geupdatet wird und man dann ein System für alles hat?

    Einer der Gründe warum z.b. keine leeren Meshes mit Attachments verwendet werden sollten ist, dass für Relektionen immer das niedrigste LOD verwendet wird. Spiegelt sich das Signal im Wasser sind dann dort nur die Coronas, aber nicht das eigentliche Signal zu sehen. Das geht mit den neuen Methoden anders.
    Ich verstehe deinen Ansatz mit dem im dunkeln erleuchteten Bahnhof, hier sollte man sich dann aber entweder entscheiden die run 600 tris einfach zu belassen oder halt doch das ganze Signal verschwinden zu lassen. Der Mittelweg ist nicht wirklich zukunftsorientiert. Im Übrigen wird eine Lösung mit .lm Dateien auch immer dafür sorgen, dass der Performancebedarf eines statischen Objekts plötzlich dem eines animierten entspricht, nur für die .lm Datei. Deshalb sind diese auch hauptsächlich da anzuwenden wo eine Animation über mehrere LODs hinweg ausgeführt werden muss, in allen anderen Fällen ist ein update auf 4.6 (auf kosten der Kompatibilität zu T:ANE) die bessere Lösung.


    Die Sperrsignale hab ich ab einer bestimmten Distanz mit der neuen Methode verschwinden lassen, ab welcher deren Coronas so klein sind dass sie ohnehin nicht wirklich sichtbar sind. Zugegebenermaßen, bei Hauptsignalen sind die größer und weiter sichtbar.



    Greets, Mika

  • Die Argumentation bezüglich Schatten und quasianimierte Version ist leider zu nachvollziehbar um sie zu übergehen.
    Ich werde widerwillig auf .im umstellen und die .lm's raus nehmen. Den Bruch zu den alten Versionen will ich dagegen nicht umsetzen. Das kann man mit einem neuen Satz Assetnummern speziell für TRS19 machen aber ich denke nicht, das man denn älteren Sims die HL Signale damit quasi unter den Füßen weg ziehen sollte - wenn es auch anders geht.

    Ich hatte eben eine unheimliche Begegnung der 3. Art.... es gibt sie tatsächlich... mir waren sie bei der Suche bisher durchgeflutscht.

    <kuid2:83501:24501:10> Hl H

    <kuid2:83501:24510:9> Hl H-60 + Zs7 + Zs8 + Ra12

    <kuid2:83501:24502:9> Hl H + Ra12

    <kuid2:83501:24519:9> Hl H/V

    <kuid2:83501:24520:9> Hl H/V + Ra12

    <kuid2:83501:24530:9> Hl L H

    <kuid2:83501:24522:9> Hl H/V-60

    <kuid2:83501:24523:9> Hl H/V-60 + Ra12

    <kuid2:83501:24500:9> Hl Vorsignal

    <kuid2:83501:24550:9> Hl Vorsignalwiederholer

    Alles Build In Signale und daher logischer Weise ohne jeden Fehler... aber ich muss mir die Scripte erst ansehen... der CM zeigt die damit zu ersetzenden Signale aus der 5: und :6 er Serie nicht alle automatisch als obsolet an. Irgendwie war der cm bei sowas früher genauer. Ich kann in TRS19 sogar grade das HL Vorsignal in der :6er und in der :9er Version gleichzeitig aufs Gleis stellen... was mal überhaupt nicht gehen dürfte. Aber wir sind ja auch erst bei SP2 :) Geht man aber davon aus, das die 10 Stück da funktionieren, beiben immer noch um die 30, die nicht gefixt wurden.
    Nachtrag: Das inherited war neben einer weiteren kleinen, aber nicht unwichtigen Änderung in der :9er und :10er schon korrigiert, die anderen 5 Fehler nicht. Das HL H hat also tatsächlich auch das aktuellste script und ich kann die "Evolutionsschritte" auch halbwegs nachvollziehen. Eine nicht ganz unwichtige Erkentnis!
    Weiterer Nachtrag: Der CM macht doch alles richtig. Es gab aber scheinbar vor den gescripteten HL Signalen eine Serie ungescriptet von scara, allerdings mit anderer KUID (<kuid:83501:24010>), das sieht man widerum nicht im Surveyor. Also ein typischer Fall von "ich hab den Überblick verloren...". Leider habe ich nur das eine Signal aus der Serie... gibts da noch andere und wenn ja wo? Es macht wohl Sinn, das ungescriptete Signal in die Obsolettabe aufzunehmen...

    4 Mal editiert, zuletzt von rd65 () aus folgendem Grund: Orthographie & Nachtrag & Nachtrag

  • Beide Ansichten zeigen sämtliche Scara-Hl Signale. Die Conf Namenserweiterung habe ich hinzugefügt, zur besseren Unterscheidung von den nichtkonfigurierbaren Signalen. Die KUID2 Erweiterung muß ebenfalls nicht original stimmen. Ich habe vor einigen Jahren Versionen hochgesetzt, um Überschreibungen zu vermeiden. Heutzutage ist das nicht mehr notwendig, da TS2010 nicht mehr auf die DLS zugreifen kann darf.


    rd65


    Die von dir gesuchten Unkonfigurierbaren sind die ersten 8 und die mit der Erweiterung :7.

    Die von Dir gezeigten :9/:10 Versionen werden In T:ane SP4 nicht angezeigt.

    MfG Frank

    3 Mal editiert, zuletzt von buderberlin () aus folgendem Grund: Ausdrucksform geändert, um Missverständnissen vorzubeugen

  • TS2010 kann immer noch auf die DLS zugreifen, vorausgesetzt Du hast ein FCT oder eine aktuelle, unter dem selben Namen registierte Version von Trainz. Habe es gerade mit dem ContentManager von TS2010 getestet. Vom der Webseite der DLS kann das anders sein, falls der Browser weder das ftp- noch das trainz-Protokoll unterstützt.


    Peter