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

  • Da TS2010 die belegten KUIDs meiner 221461 nicht erkennt, speichere ich ohne Benutzername mit -2:xxx , um ältere Einträge nicht zu zerstören. Reicht das als Erklärung oder muß alles was ich schreibe in der Luft zerissen werden. Ich habe immer nur alles unter dieser einen KUID registriert.

    Ich habe es seit der Neuinstallation auch nicht mehr probiert. Brauche ich nicht, dafür habe ich T:ane.

    3 Mal editiert, zuletzt von buderberlin ()

  • frohes Neues!

    Hab mir die alten ungescripteten Signale nun besorgt.
    Hm.. ok.. ich prüfe die Listen grade noch mal gegen meine. Danke dafür. Die Signalnamen für die ungescripteten anzupassen und sie nicht obsolet zu setzen ist vermutlich der bessere Weg. Es spricht auch nichts dagegen sie zu nutzen... ausser das sie halt wegen dem englischen/australischen Signalsystem meist Murks anzeigen. :grinning_squinting_face: Vielleicht laufen die aber jetzt besonders gut mit dem IT aus Tane/TRS19 zusammen.. wer weisss... und will es testen :grinning_squinting_face:

    Problem was ich nun sehe: Beim TRS19 meckert der CM bei allen Assets die nicht min. 3.5 sind. Was aber nicht die Funktion behindert. Der 10er würde sich aber schlicht weigern die Assets zu laden, welche 3.5 und neuer sind. Man hat also nicht mal die Chance die Assets zu laden und die Version selbst runter zu drehen. Wenn man jedoch die Signale über die DLS updaten wollte, müsste man daher vermutlich min. 3.5 setzen, da die updates sonst vermutlich abgelehnt würden - wobei das Auran eh schon schwierig zu erklären sein wird, weil irgend ein Spassvogel auf der DLS die TRS19 Build in auf 4.5 gesetzt hat. Technisch arbeiten die Signale aber mit Know How aus dem TRS2004 bzw. TRS2006. Jetzt ist die Frage... unterwirft man sich Aurans Versionspolitik (4.5)... oder geht auf das was technisch Sache ist (2.4 oder 2.6) ... oder geht ein wie auch immer gearteten Kompromiss (z.b. 3.5) ein.... Ein Fix ist meiner Meinung da auch noch mal anders zu bewerten als neu erstellter Kontent.

    Ich gehe z.Z. von einer Version für die DLS mit Version 3.5 oder 4.5 aus, eine fürs Forum welche man vermutlich auch auf die 2.4 oder 2.6 setzen könnte und eine "Weiterentwicklung" für TRS19 ab 4.6, die Mika dann bauen darf :grinning_squinting_face: .


    Inzwischen laufen die Signale als :12 und obsoleten buildins bei mir über ne Scriptlib und es gibt nur noch 2 Scripte die man editieren muss. Jetzt schau ich mir mal die eigentlichen Bugs an... das kann bischen dauern.

    Einmal editiert, zuletzt von rd65 ()

  • OT:

    NEIN, es würde auch in TS2010 gehen. Nur will ich das nicht. Deswegen habe ich die Zugangsdaten entfernt. Während im TRS2007 der Startbereich der Speicherung unter der eigenen KUID auswählbar war, gibt es das bei TS2010 nicht. Nach jeder Neuinstallation fängt der Speicherbereich wieder bei, ich glaube, :100001 an. Damit würde ich meine gesamte Speicherung der vergangenen fast 16 Jahre zerschiessen. Lieber speichere ich, ohne Benutzername mit -2:xx, wichtige Dinge kan ich später in meine KUID wandeln. Die letzte Neuinstallation von TS2010 wurde erst kürzlich fällig, als ich die Dualbootkonfiguration von Win7 und Win10 zugunsten von Win10 beendet hatte.

  • Ich will hier mal erklären was ich damit meine, wenn ich sage, das die Vorsignale Probleme machen. (wie ich inzwischen gemerkt habe aber nicht nur die)
    Zu sehen ist hier:
    Ein Gleis links, es steht eine Lok im Gleis. Ein Gleis rechts, es steht _keine_ Lok im Gleis. Die Weiche steht ins freie Gleis.
    Das Signal A bekommt so keine Meldung über ein Zug auf Strecke und bleibt auf rot (HP0). Soweit korrekt. Das nächste Hauptsignal (auch ohne Zuganforderung) ist D, zwischen A und D steht ein Vorsignal B und ein Vorsignalwiderholer C.

    Hier zeigt also ein Vorsignal B/C auf ein rot (hp0) zeigendes Hauptsignal D einfach mal ohne Zuganforderung ein Vr1 "Fahrt erwarten"
    Da komme ich schon in Wallung!
    Jetzt stelle ich hinter D eine Lok aufs Gleis und die Weiche so das meine Lok links Fahrt bekommen müsste.
    Was denkt ihr was passiert?
    Richtig... A zeigt Fahrt frei... D zeigt Halt weil da ja ne Lok im Gleis steht... und was machen die Vorsignale? Nix! Vr1 !! Auf ein HP0 hin weisend!
    In dem verwendeten HL H/V ist aber auch eine Vorsignalfunktion verbaut (die allerdings nicht über das Vorsignalscript gesteuert wird).
    Tatsächlich müsste also zumindest bei letzterer Variante am Signal A Hl 12a, also "Geschwindigkeit 40 km/h ermäßigen, Halt erwarten" angezeigt werden.
    Ich weiss nicht ob ich das korrigieren kann aber sowas ärgert mich ungemein! Für mein Geschmack ist zudem auch die Corona viel zu dunkel und zu wenig brilliant. D ist auf dem Bild nur ca. 300m weg und kaum noch "relevant". Aber das nur nebenbei. Ihr könnt das ja mal mit einem Signalsystem eurer Wahl nachbauen und schauen wie die so reagieren. Sollte ich mit meiner Analyse falsch liegen, bitte ich um Info. Ich kenne zwar diverse Litertur dazu, bin aber halt eben kein TF.

    Für ein lediglich rot und grün zeigendes Signalsystem wo die Vorsignale immer auf grün stehen... braucht man eigentlich keine Signale mit Scripts...! Siehe alte Signale von Scara. *seufz

    Einmal editiert, zuletzt von rd65 ()

  • Deine Erklärung ist mir nicht klar. Ich baue nur mit Scaras. Wen ich ein konfigurierbares Vorsignal und Wiederholer vor ein Hp0 stelle, zeigen beide ohne Konfiguration grün. In dem Moment, wo ich den Bezug zum Hauptsignal konfiguriere, springen die Vorsignale auf gelb. (bei Hp0)

    Kommt ein Zug, geht alles auf grün. Ist das Haupsignal so konfiguriert das eine Vmax Drosselung zu erwarten ist, blinken die Vorsignale, die H/V Signale verhalten sich dabei genauso. Ich denke, das ist so richtig. Richtig wissen, tue ichs auch nicht.

    Aber es sieht gut aus.:)

    Grüsse Frank


    PS: Du weißt aber, daß die originalen Scaras eine "Durchbrennfunktion" des Hauptrots haben. Das hat mich immer gestört. Da ich nicht wußte, wie ich das abstellen könnte, habe ich die Coronazuordnung in der Config.txt vom Hilfsrot, aufs Hauptrot gelegt. Hilsrot+Hauptrot haben scheinbar unterschiedliche Intensität.

    2 Mal editiert, zuletzt von buderberlin ()

    • Offizieller Beitrag

    Ohne gerade genau zu wissen, ob es für das beschriebene Problem mit den Vorsignalen trifft: beachtet bitte, dass scriptgesteuerte Signale und Weichen im 19er Survyeor nicht das Richtige anzeigen. Erst im Driver Modus funktioniert es richtig. Und dort funktionieren bei mir die Vorsignale ohne Probleme.


    Mein Problem bei den HL Signalen ist eher das, dass das Rangiersignal nach Beendigung einer Fahrstrasse nicht wieder ausgeht.


    Edit @buderberlin : die Funktion mit dem Ersatzrot habe ich bei meinen HL Scripten herausgenommen.


    cheers

    Christian

  • Mein Problem bei den HL Signalen ist eher das, dass das Rangiersignal nach Beendigung einer Fahrstrasse nicht wieder ausgeht.

    Das ist beim TS10 auch so. Stört mich auch. Die "weißen Punkte" gehen bei mir überhaupt nicht aus. Ich meide diese Signale mit diesem Zusatz. Ich beziehe mich in meinen Posts nur auf die Funktionalität im TS10. In T:ane SP4 zeigen auch die :5 er Scaras an Einmündungen beide gleichzeitig grün, wenn 2 Züge herannahen. Das Einmündungsproblem hatte ich schon beschrieben. Bis jetzt habe ich keine Lösung.

    Gruß Frank


    Edit: ChWerwick: Meine Scaras im TS10 sind nicht von der DLS. Das war ein separates Reparaturpaket für TS2009. Nur die T:ane Abhängigkeiten waren alle von der DLS.

    Einmal editiert, zuletzt von buderberlin ()

  • Das Ersatzrot ist eine Zufallsfunktion bei 2 auf 1000 zuletzt aber wohl auf 2 auf 10000 geändert. Math.Rand(0,10000)>9998)
    Da alles immer die gleichen coronas verwendet, kann es nur sein das ggf. die coronaconfig unter effects unterschiedlich ist. Die

    object-size z.b.
    Grundsätzlich haben die Signale eine Ersatzrot-Funktion, daher werde ich die nicht raus nehmen. Nur sollte das natürlich nicht zu oft auftauchen, das ist auch richtig. Ich denke, ich habe auch schon einige kleinere Fehler gefunden was Gültigkeit von Vars angeht und ein paar incement Fehler und nochn bissel Kleinkram. Da wird auch noch ein Handler aufgerufen der überflüssig ist usw., usw.
    Das surveyor und driver unterschiedliche Signalbilder zaubert hatte ich vergessen, ja.. muss ich noch mal gucken, grade ist die Scriptlib Baustelle.
    Ich hab mir inzwischen diverse Signale angeschaut, u.a. auch build ins (<kuid2:404575:101534:4> <kuid2:404575:101542 4>) die ähnlich funktionieren. Da ist der gs Code überigends doppelt so groß wie in den HL Signalen... die steuern auch anims usw... aber... und das ist ausschlaggebend: Es ist über lange Strecken der gleiche Code Ansatz. Also gleiche Var und Funktionsnamen usw. Ich wusel mich grade da durch...

    Bei Signalen gibts grundsätzlich eine max. Geschwindigkeit von 160km/h, darüber darf nur mit LZB gefahren werden. Trainz kennt aber nun mal keine LZB so weit ich weiss. Andere Signale setzen die 160km fest als Vmax ein. Wenn ich das auch mache, kann man keine Schnellfahrstrecken für ICE/TGV/usw. mit den Sigs bauen. Bei Formsignalen find ich das akzeptabel aber wie weit hält man sich da bei Lichtsignalen ans Vorbild? Ich wäre eher geneigt die 160 km/h einzutragen. Was meint ihr?

  • Ich denke auch, daß 160kmh angemessen reicht. @Scara hatte diese DR-Signale wahrscheinlich bewusst auf 120kmh begrenzt, da bei der DR nirgends schneller gefahren wurde. Nur gab es in TRS2004 viele DB-Signale die funktionierten und keine Vmax Festlegung hatten. - Schliesslich geht es hier und heute um DEN deutschen Signalsatz, der funktionieren sollte.


    Edit: Ich habe eine Testmap direkt in T:ane SP4 neu erstellt. Dabei kam es mir darauf an, alle möglichen Signalkonfigurationen testen zu können. Die Scaras in Version :5 funktionieren, auf den ersten Blick, einwandfrei. Es entsteht der Eindruck, daß die scheinbaren Signalfehler, nur in Maps auftreten, die extern eingespielt wurden......!?

    Einmal editiert, zuletzt von buderberlin ()

  • Ich will - wenn ich die Signale soweit habe - die Sigs zunächst zur Überprüfung erst an ein paar Leute hier verteilen die testen können bevor ich die ans Board zum Download frei gebe. Diese sollten in der Lage sein, die Sigs ggf auch wieder zu entfernen falls Probleme auftreten. Vielleicht wäre so eine Teststrecke auch ein guter Ansatz um zukünftig eine gemeinsame Plattform zum testen zu haben. Irgendwie ist das blöd wenn man etwas zum Testen nachbauen will/soll aber nicht mal seine Testergebnisse zeigen kann ausser mit einem Foto. (siehe oben) Ich hatte mal überlegt, selbst sowas den Signalen beizulegen aber das rutscht auf meiner Todo Liste irgendwie nicht nach oben... Es muss ja kene große Anlage sein, es reicht wenn man Funktionalität anschaulich macht. Eigentlich reicht eine 8, 4 Weichen die aus der 8 eine 0 machen und ein paar Rangiergleise/kleiner GBf, ein, zwei Stumpfgleise und zwei bis drei Loks druf... und los... So ne typische Starterset I & II Anlage halt. War zumindest mein Gedanke dazu. Ich werde die Vmax auf 160 setzen.

  • Ich habe eine Strecke im Aufbau, wo ich gerade ein Signalsystem für suche. Da meine Weichen im Bahnhof für 40km/h, 60km/h, 100km/h sind, und ich auch fast alle Variationen an Signalen benötige und sowieso jeden Tag teste, würd ich mich zum Testen anbieten. Streckengeschwindigkeit liegt bei 140km/h.

  • Wenn ich mich recht erinnere, ist die Analyse der Skripte von KlausM eine wahre Sisyphos-Arbeit. Sie sind in viele Dateien aufgeteilt, die sich verschachtelt gegenseitig einbinden. Ausserdem haben alle eigenen Bezeichner zufällige Namen erhalten, dadurch ist es nicht leicht den Zweck zu ermitteln.


    Peter

  • Hallo,
    also zunächst reaktionen auf Posts oben:
    Ich bin froh wenn Leute mit gucken und Ideen/Infos beitragen denn ich bin auch nur Laie.
    Das mit -1 oder 160km/h ... laut Vorbild gelten Form und Lichtsignale nur bis 160km/h, darüber MUSS ZWINGEND mit Linienzugbeeinflussung (LZB) gearbeitet werden. Dies ist ein Mittelleiter auf der Schiene, welcher Strom führt und so Impulse in die Lok induziert. Das LZB wird vom Stellwerk aus quasi "stetig" gesteuert und wenn der TF sich im LZB aufgeschaltet hat, übernimmt das LZB (das Stellwerk) die komplette Geschwindigkeitssteuerung der Lok auch über 160 km/h hinaus. Nachfolger des LZB ist das ETCS. Wichtig dabei, das LZB System nutzt als Rückfallsicherheit das PZB. Mit anderen Worten, bei LZB Betrieb kann auch ein PZB Magnet den Zug bremsen. Ich vermute jetzt einfach mal, das es da auch auf den Magneten ankommt... 500er dürften überfahren werden, 1000er und ganz sicher 2000er nicht... irgendwie so. Das bedeutet aber eigenlich, das man die MaxSpeed der Signale tatsächlich auf -1 setzen müsste und nicht auf 160km/h. Sonst wäre eine Geschwindigkeit von über 160km/h nicht möglich. Die Begrenzung müsste aber vom LZB kommen und nicht über diese Signale. Ich überlege noch was ich da mache.

    Zu anderen/alten Signalen, tatsächlich sind die Lichtsperrsignale aus der Liste

    schon mit einem Library Script ausgestattet. Diese ist <kuid:404575:1870306> |CJ| Licht-Sperrsignal Library
    Diese sind in TRS19 zum Teil Buildin, zum Teil DLSware. Ich schaue mir also auch an was andere da so machen. Jetzt gibts aber ein grundsätzliches Problem.

    Man kann das so aufteilen: Signale welche bis vor Tane SP2 eingesetzt wurden, konnten sich - egal wie groß die Strecke war - darauf verlassen, "geladen" zu werden. Das gilt für alle alten Strecken wenn sie in neuere Sims geladen werden aber eben NICHT mehr! Nach Tane SP2 lädt der Sim nur was er meint zu brauchen... und demzufolge kann es einem Signal passieren "entladen" oder nicht geladen zu werden wenn der Focus weit genug weg ist. Das hat verschiedene Erkentnisse zur Folge die sich leider gegenseitig ausschließen können. Da deutsche Signale quasi miteinander über die Funktion Postmessage miteinander reden und versuchen das interne Signalsystem zu umgehen, ergeben sich hier große Probleme. Nicht geladene Signale reden natürlich nicht...

    1. Man kann alte Signale (preTaneSP2) für alte Sims und der Nutzung auf alten Strecken fit machen. Diese werden in neueren Sims nicht so laufen wie erwartet.
    2. Man kann versuchen alte Signale (preTaneSP2) für (TaneSP2post) und Interlocking fit zu machen, was ein heiden Aufwand ist und der Nachladetechnik aus Tane entgegen arbeitet, die Signale sind dann aber auch kaum mehr komaptibel zu machen mit alten Sims - und vor allem nicht performant.
    3. Man wird für (TaneSP2post) und auf diesem neu erstellte Strecken neue Signalsteuerungen entwickeln müssen, die dann auch IT kompatibel sind. Diese sind aber in alten Sims und in neuen Sims auf alten Strecken nur schlecht bis garnicht einsetzbar.

    Grundsätzlich gilt dabei, Signale die sich stärker auf die interne (englische/australische) Signalbearbeitung verlassen und möglichst wenig Such- (Junction/Signal) und Messagevorgänge nutzen sind kompatibler mit neueren Sims. Eigentlich müsste man das Thema Signale ab TaneSP2post komplett neu denken. Denn die Verscriptung wurde damals nötig weil es eben das Interlocking bis vor Tane nicht gab. Ungescriptete Signale wären vermutlich das Beste, was man in TaneSP2post einsetzten kann! Genau aus dem Grund ist das Signalpaket im Augenblick auch zusätzlich mit den alten ungescripteten HL-Signalen ausgestattet. Ich sehe derzeit keine andere Möglichkeit, das uns von Auran aufgezwungene Dilema anders zu lösen. Selbst wenn man alte Sims nicht supporten will aber alte Strecken nicht verwerfen möchte, muss man sich damit rum schlagen. Das grundsätzliche Problem haben aber auch andere Strecken mit gespripteten Signalen aus anderen Ländern. Das Problem bleibt auch wenn man im TRS19 neue Strekcen baut aber alte Signale verwendet.
    Da stellt sich aber die Frage, ob es überhaupt genügend Contentersteller gibt, die extra für Tane und Nachfolger neuen Content wie Strecken bauen UND die das Problem auf dem Schirm haben. Das was ich z.Z. sehe ist, das zwar die Buildnummern hoch gezogen werden (4.5 u.ä.) aber die 15 Jahre alten Scripte in den Assets im TRS19 versagen... das kanns nicht sein!

    Ein Problem bezüglich IT was ich dabei noch sehe ist: Interlocking ist quasi auch nur eine große Scriptsammlung... und man kann damit rechnen, das auch deren Scripte irgendwann Probleme machen. Mir gefällt die Idee besser, ein offenenes System zu haben in dem man verlässliche Umgebungen über Versionen hinweg hat - das war bis Tane der Fall, genau das wurde aber "aus technischen Gründen" nun eingeschränkt. Ich muss gestehen, das ich mir über die Tragweite der Tane Änderungen nicht klar war, als ich Ende des Jahres beschloss, mich nach langer Abstinenz mal wieder mit Trainz zu beschäftigen.

    Das bedeutet aber auch, das man die Signale wie ich sie jetzt parat mache eigentlich nur in preTaneSP2 Umgebungen wirklich testen kann. Für ab Tane müsste man sich eigentlich komplett neu mit Signalen/IT beschäftigen und hoffen, das man als Contentbauer damit nicht aufs falsche Pferd setzt - oder eben damit leben das es eigentlich doch nur eine Spielzeugsoftware mit eingeschränkter vorbildtreue ist und man besser nach Hamburg fährt wenn eine ordentliche Signalsteuerung im Modell sehen will!

    Einmal editiert, zuletzt von rd65 () aus folgendem Grund: präzisierung

  • Bald verfügbar, derzeit nicht gelistet

    Das LZB wird vom Stellwerk aus quasi "stetig" gesteuert und wenn der TF sich im LZB aufgeschaltet hat, übernimmt das LZB (das Stellwerk) die komplette Geschwindigkeitssteuerung der Lok auch über 160 km/h hinaus.

    Moin,


    aufgrund meines Berufes, möchte ich hier etwas Licht ins dunkle bringen. Die LZB hat mit dem Stellwerk des Fahrdienstleiter (Fdl) eher weniger zu tun. Es ist ein reines Zugüberwachungssystem, was Überwachung und Sicherheit von Zugfahrten in Form der Geschwindigkeit und der Stellung von Signalen. Es überwacht die Handlungen des Triebfahrzeugführers auf ganzer Linie, und nicht wie bei der PZP, nur Punktuell!

    Es bekommt lediglich Informationen vom Stellwerk über die Halt- bzw Fahrt Stellung von Signalen, mehr aber auch nicht. Erst wenn die LZB ausfällt, kommt der Fahrdienstleiter mit ins Boot, in Form von Ersatzmaßnahmen, wie etwa das erteilen eines Befehl mit Geschwindigkeitsangaben.


    Ich vermute jetzt einfach mal, das es da auch auf den Magneten ankommt... 500er dürften überfahren werden, 1000er und ganz sicher 2000er nicht... irgendwie so

    Zu den PZB gibt es folgendes zu sagen. Die sind zur Überwachung bzgl. Geschwindigkeit und der daraus resultierenden Handlung des Tf da.


    Der 1000er Herzmagnet ist am Vorsignalen platziert. Überfährt der TF diesen, ertönt ein Signal im Führerstand und der TF muss quittieren, das er das Vorsignal ( Langsamfahrt, Halt erwarten) wahr genommen hat. Der 500er Magnet liegt etwas 250m vor dem Hauptsignal und Überwacht die Geschwindigkeit, dass heißt, es herrscht eine sogenannte Geschwindigkeitskurve vom Vorsignal bis zum Hauptsignal, die errechnet wurde, damit der Zug rechtzeitig bis zum Hauptsignal die Geschwindigkeit reduziert hat oder der Zug zum Halten gebracht sein muss. Somit muss der TF am 500er seine Geschwindigkeit bis zu einem bestimmten Punkt bereits gedrosselt haben, sollte dies nicht der Fall sein, bekommt er schon jetzt eine Zwangsbremsung.

    Nun kommt der aller wichtigste PZP Magnet, der 2000er.Dieser ist direkt am Hauptsignal verbaut und dient 1. Der sofortigen Zwangsbremsung bei überfahren eines Halt zeigendem Hauptsignal, 2. zur Überwachung der Geschwindigkeit bei Langsamfahrt.


    Schöne Grüße Stefan24

    2 Mal editiert, zuletzt von Stefan24 ()