Hallo,
die gelben Linien scheinen tote Links zu sein, die zu keinem Objekt mehr gehören und nur noch als Fragmente in der Tracks.in stehen.
Also ein Fehler in der Tracks.bin, der dann die Nachrichten blockiert.
Hätte nie gedacht, dass der Hp0-Trigger_1T zur Überbrückung (U) von Gleisunterbrechungen auch mal einen wirklichen Sinn haben wird.
Gruß Schuster
Hallo Solin,
das Esig S102 ist unvorbereitet bis Du den Link 0 vom Asig P 22 vollständig passierst hast. Erst dann wird das Esig S102 vorbereitet und signalisiert sofort Hp1.
Es zeigt sich somit, dass der Link 0 vom Signal Asig P22 selbst keine Nachrichten sendet. Denn wenn sich ein Zug annähert, wird diese Information nach dem Empfang an Link 0 wieder vom Link 0 aus weiter geleitet. Da wird aber nichts gesendet. Wenn der Zug später den Link 0 am Signal Asig P22 vollständig passiert hat, schickt dieser Zug vom verbundenen Link 1+ (Link 1 in diesem Falle) aus eine Nachricht an das nächste Signal und kündigt sich an. Das funktioniert dann auch.
Ich vermute, dass der Link 0 vom Asig P22 auf dem Bahnsteigmarker liegt. Oder ein anderer Gleisdefekt zwischen dem Link 0 und dem Link 1 vom Asig P22 vorliegt.
Gruß Schuster
Hallo Sven,
er sollte das schon wissen, hab ihm schon alles mitgeteilt.
Gruß Schuster
Hallo,
ich habe schon einen Unterschied im Skript mit einem HEX-Editor gefunden, der da nicht hin gehört. Ob das so reicht muss Schienenbus nachprüfen.
Gruß Schuster
LKann mal jemand bestätigen, das wenn man die Datei im Bild entfernt, ob die Strecke dann läuft?
Bei mir läuft die Strecke nur, wenn ich diese eine Datei entferne. Entferne ich die anderen und lass ich diese eine drinnen, lädt es nicht mehr.
Es handelt sich bei der Datei um den Skript vom HV Vorsignalwiederholer zur Ansteuerung des Skript-Moduls für HV-Freeware-Vorsignale.
Ohne Skript funktionieren die Vorsignalwiederholer nicht mehr. Das soll die Lösung sein?
Testweise könntest du den Skript „DEs HV VS.out“ nach „DEs HV VS Wh.out“ zu kopieren. Dann würde der Vorsignalwiederholer wie ein normales Vorsignal funktionieren. Sollte dies keine Verbesserung bringen, könnte man die Signal.bin vom Vorsignal auf den Dateinamen des Vorsignalwiederholers kopieren, um das gleiche zu erreichen. Vielleicht gelingt es so, das Problem weiter einzugrenzen.
Gruß Schuster
Zwischen Hamburg Hbf und Harburg (QD) an km 353,6 und 346,0.
Muss mich aber korrigieren.
Tab war nicht nötig, die darauffolgenden Hauptsignale sind, sobald ich nah genug dran war, von alleine umgesprungen.
Ich weiß nicht ob euch das weiterhilft; vielleicht stimmt ja in dem Bereich eine Weiche nicht.
Das Signal war sicher unvorbereitet, da wegen einem unterbrochenem Gleis vom vorherigen Signal keine Nachricht ankam.
Alle Haupt- und Sperrsignale haben aber eine zusätzliche Automatik eingebaut bekommen, welche sie automatisch vorbereitet, wenn sich die Zugspitze näher als 200 Meter vor dem Signal befindet.
Gruß Schuster
Hallo,
täusche ich mich, oder sind bei den TSC_500 gar keine Skripte hinterlegt?
Gruß Schuster
Edit: Ich hatte mir den falschen 500 gegriffen, das war nur der Dummy.
Hallo,
Wenn man die Magneten entfernt, wird unweigerlich der Nachrichtentransport auf dem Gleis unterbrochen, da der Link vom Magneten noch im Gleis liegt. Somit bleiben die Signale auch auf Halt, da der sich annähernde Zug nicht von einem Signal zum nächsten übermittelt werden kann. Man müsste den Skript vom Magnet durch einen Skript ohne Funktionalität ersetzen. Die Funktionsaufrufe müssen natürlich drin stehen.
Bezüglich der Signale fragen diese den verbundenen Link ab, nachdem sie eine Nachricht vorn einer Weichenumstellung erhalten haben. Hier könnte man diese Abfrage des verbundenen Links deaktivieren, um zu testen, ob hier das Problem oder im Skript selbst liegt.
Gruß Schuster
Hallo,
zum neuen LogMate:
Die Idee, das Log gleich in Dateien zu schreiben ist ja nicht schlecht. Allerdings fehlt mir das Fenster zur Echtzeitbeobachtung des Logs. Ein geöffnetes Log muss ich immer wieder manuell Nachladen.
Das alte LogMate läuft auch noch unter der 32 und 64Bit Version. Wer also das Log gelegentlich in Echtzeit beobachten möchte, tut gut daran sich die alte Version aufzuheben.
Gruß Schuster
Hallo,
in dem Augenblick, wenn der Editor erscheint, wird der TSW erst richtig interessant. Der Blick geht nach vorn und wer 10 Jahre lang mit den Einschränkungen des TS leben musste, wird sich auf die neuen Möglichkeiten stürzen, die die Unreal Engine zu bieten hat. Es geht hier nicht nur um die Optik, sondern vor allem um Funktionen und Interaktionen der Objekte untereinander, die nun möglich werden. Wenn man derzeit die leblose Welt auf DTGs Strecken sieht, dann ist das weniger ein Manko der Unreal Engine sondern eher weil DTG in den Anfangsjahren vom TSW den Schwerpunkt wohl mehr auf den Innenraum der Loks legt.
Gruß Schuster
Hallo,
wenn ich bei "Frachtwechsel" vor einem Sperrsignal mit Hp0 stehe und auf Anforderung TAB drücke, bekomme ich kein Sh1, soll aber trotzdem vorbei fahren. DTG kapiert's einfach nicht....
Gruß Schuster
Hallo,
ich habe nun Sperrsignale als AddOn-Paket für die HV-Signale vom SignalTeam und die überarbeiteten KS-Signale von Kuju erstellt.
Diese Sperrsignale sind für den "anschließenden Weichenbereich", also den Weichenbereich nach einem Hauptsignal, gedacht. Sie sollten ausschließlich verwendet werden, wenn der Link 0 des Sperrsignals zwischen Hauptsignallinks liegt. Die Funktion dieser Sperrsignale ist mit den bisherigen Sperrsignalen identisch. Es wird der gleiche Skript verwendet. Im HUD und auf der 2DMap sowie 2DMapPro sind diese Sperrsignale jedoch (wie auch Vor- und Zusatzsignale) nicht sichtbar. Hintergrund ist, dass das Stopping ausgeschaltet ist. Somit werden auch keine KI-Züge von diesen Sperrsignalen beeinflusst.
Im Editor tragen diese Sperrsignale die Bezeichnung "SHw" (üblich ist "SH"). Die Anzahl der Links beträgt 1 - 4 in 3 Ausführungen (Konsole, Mast, Zwerg). Dies sollte für diesen Anwendungsfall ausreichen. Wer mehr Links benötigt kann sich diese Sperrsignale entsprechend der bekannten Anleitung selbst erstellen. Dieses AddOn funktioniert auch mit früheren Signalversionen. Ab dem jeweils nächsten Update sind diese Sperrsignale dann automatisch enthalten.
Gruß Schuster
Hallo,
ja genau. Der KI-Verkehr lässt sich davon auch beeinflussen, da KI-Züge nur Blockabschnitte kennen, die durch Signale mit "Stopping=eTrue" gebildet werden. Den KI-Zügen sind nämlich die Signale egal, wie ich früher schon schrieb.
Sie fahren ja auch schon los, bevor eine Weiche endgültig umgestellt ist. Somit hätte das Signal auch keine Chance sein Hp1 zu zeigen. Das wurde alles nie geändert.
Sperrsignale könnten mit und ohne "Stopping=eTrue" friedlich nebeneinander leben. Man muss nur die BIN-Dateien verdoppeln und das Stopping bei einem Teil auf "eFalse" ändern und natürlich die Editor-Bezeichnung anpassen.
Das könnte ich alles ins nächste Update packen und hier auch vorab, bei Bedarf, als Patch bereitstellen.
Gruß Schuster
… Er drehte sich um und ….
Hallo,
soweit ich das richtig sehe, geht es um die angezeigten Geschwindigkeiten im HUD und nicht um die Anzeige der Signale selbst. (?)
Wenn es um die Geschwindigkeitsanzeige im HUD geht, dann liegt dies an dem TS selbst, da dieser mit Sperrsignalen, die zwischen Hauptsignallinks liegen, nicht umgehen kann. Die Anzeige der Geschwindigkeit aus dem Signal-Flyout im HUD erfolgt in der Regel vom Link 0 des Signals bis zu dessen Link 1+.
Wenn aber in diesem Bereich ein Signal mit der Eigenschaft "Stopping=eTrue" in der Signal-Bin liegt, wird die im Signal-Flyout angezeigte Geschwindigkeit nicht richtig im HUD angezeigt.
Abhilfe leistet hier, die Streckgeschwindigkeit direkt im Gleis einzutragen, wo dies geht.
Als Alternative könnte man auch Sperrsignale ohne die Eigenschaft "Stopping=eTrue" zu erzeugen, aber dann werden diese Sperrsignale weder im HUD noch auf der 2D-Map angezeigt.
Gruß Schuster
Hello,
hope this will help you:
-- Switch off
Call("Child_Name:ActivateNode", "Node_Name", 0 )
-- Switch on
Call("Child_Name:ActivateNode", "Node_Name", 1 )
Gruß Schuster
Hallo,
im Anhang nun eine Erweiterung als Patch mit dem Hauptsperrsignal mit Kennlicht (HSPK) als Anbau in 3 Varianten, sowie das Zs2 mit 2L0 in 4 Varianten.
Editorliste:
ST HV +HSP K 2L0
ST HV +HSP K VS 2L0
ST HV +HSP K VS 2L0 rd
ST HV Zs2 2L0 Mast
ST HV Zs2 2L0 oben
ST HV Zs2 2L0 SB
ST HV Zs2 2L0
Es werden 2 Module überschrieben. Bitte aufpassen, wenn der Patch gegebenenfalls entfernt wird.
Gruß Schuster
Hallo Frank,
grundsätzlich könnte ich den Skript so umbauen, dass es dem Zs2 bzw Zs6 egal ist, ob es die Nachrichten vom Link 0 oder vom Link 1 erhält.
Ob das dann aber richtig funktioniert ist eine andere Frage, da ausgehend von beiden Hauptsignal-Link0, die dahinter liegen, auch immer "gleichzeitig" Nachrichten gesendet werden könnten, die sich gegenseitig überschneiden. Ich baue den Skript zum Testen einmal um.
das HSPK habe ich schon mit und ohne Vorsignal bzw. reduziertem Vorsignal erstellt und werde es die nächsten Tage mit dem Zs2/Zs6 2L0 gemeinsam hier als Patch anbieten.
Gruß Schuster
Hallo,
also die "16" sollte im Zs3 schon ordnungsgemäß angezeigt werden.
Im Skript ist das soweit eingebaut und wurde auch ausgeliefert.
Vielleicht machst Du einmal einen Screenshot von Deinem Signal mit geöffnetem Signalflyout, wo die eingetragenen Werte zu sehen sind.
Gruß Schuster
Hallo,
in Kürze wird dieses Paket auch hier auf Rail-Sim verfügbar sein.
Grundlage sind die hervorragenden Formsignale von Rosenkill vom RLB Team. Die vorhandenen Signale wurden durch Schienenbus noch erweitert und Traindriver 316 erstellte das Handbuch und kümmerte sich um die Organisation.
Ich habe wie gewohnt die Skripte geliefert, um alles funktionell und kompatibel zu den anderen Signalsystemen zu halten.
Die Mitwirkenden sind außerdem im Handbuch unter Punkt 8 aufgeführt.
Bitte dringend das Handbuch beachten. Hier sind auch die Lizenzbedingungen für den Einsatz der Signale aufgeführt.
Viel Spaß mit dem Paket.
Gruß Schuster