Beiträge von rd65

Danke euch beiden! schau ich mir an.

Ich nutze seit Jahren ein SABERTOOTH 990FX R2.0 ... also AM3+ mit einem FX-8350, 32 GB Ram und eine Gtx1080ti. Heute keine empfehlenswerte Config mehr aber nicht lahm. Die Samsung NVMe ist via Adapterkarte im PCIE slot angeflanscht.

Es gab mal unter http://trainzworld.de/infusion…ownloads/trainzscript.zip (link hier im Forum gefunden aber tot und auch per wayback nicht zu bekommen) eine Extension für Notepad++ für Scripthighlighting wohl in verschiedenen Versionen. Hat jemand diese Erweiterung in aktueller Version und kann sie mir geben oder kennt jemand ein funktionierenden Download link? Oder gehört das auch zum verlorenen Wissen um Trainz?

Das Problem mit C damals waren 1. fehlende Schreibrechte weil sich Trainz verhalten hat wie unter win95, aber auf einem ausgewachsenem NT mit zusätzlich eingeschränkten Rechten lief und 2. das man unter Trainz schnell mal eine Mio Dateien zusammen bekam - was für ein C Laufwerk und einem 32 Bit System nicht unbedingt förderlich war.
Mit deutlich höheren IOPS auf SSDs und der AppData Installation und 64 Bit sollte das heute alles keine Probleme mehr machen. Aber ich hab meine Appdata auch auf eine nvme ausgelagert weil die trotz "nur" pci-e 2.0 min. 4 mal schneller ist als die schnellste SSD. Bei mir zumindest.. und das merkt man doch recht deutlich im Spiel.

Oh sorry for this missleading.

This Loco is known as BR211 or DR E11
https://the-train.de/downloads/entry/5221-dr-e11-035set/ * link points to wrong Sim.
as i remember, they are made by hei51 (forum Member)

hm ja nicht ganz... so wie in einem bmp format rle oder plane bitmaps in 8, 16 oder 24/32 bit gespeichert werden können, so gibts in TGA diese Variationen auch.. und noch einige mehr. Tga ist aber wie bmp ein Grafikformat wie jedes andere auch aber es gibt da eben sonderformate wie grayscale bitmaps, welche Trainz eben nicht verarbeiten kann. jpg nutzt loosy compression und ist für sowas absolut ungeeignet zumal es wie rle erst dekomprimiert werden muss. Die Grafikverarbeitung in Trainz ist zu Lasten von Speicher auf maximale Geschwindigkeit ausgelegt. (und das ist gut so!)
Dann gibts noch einen zweiten wichtigeren Aspekt. In älteren Trainz versionen hat die Engine Dinge einfach nicht gemacht wenn es zu Problemen kam. Die Engine in TRS19 wird inzwischen so abgefangen, das alles was nicht klappt zu einem Fehler gemeldet wird. Ein Beispiel dazu:
Ein Att Point welcher in der config existiert aber im Mesh nicht, wurde früher einfach ignoriert. Heute meldet das System, das es den Att Punkt nicht findet und verweigert das Laden des Assets. Das Asset wurde nie verändert aber nach 15 Jahren fällt der Engine auf... uh... da gibts was womit ich nicht klar komme also streike ich! Ich bin mir nicht sicher aber sowas wäre auch in Verbindung mit den Grafiken hier möglich. Die brauchen bei Auran im laufe der letzten Versionen nur die "komplizierte" Laderoutine für TGA Grayscalebitmaps abgeschaltet zu haben... und Zack... plöppt das Problem auf. Aber es liegt eben nicht an TGA selbst... man könnte das ganze auch mit rle im BMP Format durchexezieren... wenn man schnell Speicherkompatible Bilder verarbeiten will, muss man eben auf Sonderformate und Compression verzichten. Tatsächlich ist das TGA Grayscale Format hier das effizienteste Grafikformat gewesen... weswegen das Grafikprogramm es vermutlich so gespeichert hat... nur eben nicht das am schnellsten verarbeitbare, wenn man es zusammen mit einem 32 Bit TGA verdengeln will - was Trainz jedoch macht um die Löcher ins Blech zu stanzen. Das eigentliche Problem an der ganzen Geschichte ist, das BMP kein Alphachannel kennt. TGA kennt Alphachannels, aber dafür müsste sich Auran mal aufraffen und das komplette Set für TGA import unterstützen. Und so lange das nicht der Fall ist, "basteln" wir uns eben diese Grafiken mit 2 Dateien ... die aber halt im Aufbau gleich sein müssen. Siehe dort

(es wäre sogar möglich das inzwischen TGA mit alpha in Trainz funktioniert - ich habs länger nicht probiert. In TRS04, PTB2 und TRS09 ging es meines Wissens nicht.)

Das Problem an den Lochrasterdateien ist, das sie ein falsches Bildfarbformat haben. Ich meine Greyscale statt Truecolor gesehen zu haben was aber mit der alphakanal-Logik von Trainz irgendwie nicht (mehr?) geht. Mit Peters Bescheibung werden sie korrekt umformatiert. Das Problem, das der CM Fehler sehr verspätet anzeigt, hatte er auch schon in der SP1 version. Besonders bei Abhängigkeiten ist das mühsam.

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!

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.

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 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

Sorry.. das ist die richtige:
http://www.albert-gieseler.de/…ten0/lokdatendet305.shtml

Waren KPEV Maschinen nicht grün mit schwarzer Rauchkammer? Für mich ist das eher die DRG Fassung mit KPEV Schild. Deine da heisst übrigends Saar 8412

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. Vielleicht laufen die aber jetzt besonders gut mit dem IT aus Tane/TRS19 zusammen.. wer weisss... und will es testen

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 .

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.

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...

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ß

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? 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.

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.

...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ß