Meines Wissens geht das nur bei Gleisinfrastruktur-Objekten (Signale, Hektometertafeln, Lf7...)
Darum sind die Hektometertafeln ja auch so, wie sie sind. Es könnten einfache Objekte sein, aber sind sie wegen der dynamischen Nummerierung nicht.
Mit dem Gleislink wirst du also leben müssen.
Im Falle von Hektometertafeln solltest du keine nachteiliegen Effekte beim Bahnbetrieb beobachten können.
Tokio - Lissabon
Dieser Thread ist immer wieder lustig!
Das hat schon seinen Grund, warum ein Ribbon immer nur 500m lang sein sollte.
Daher schnibbel ich immer manuell eine Trennung rein, wenn der TS das nicht macht. Bei RSSLO hat man das (wie du sagst) nicht gemacht, und auch wenn der TS damit klarkmmen müsste, das tut er aber nicht,... diese Erfahrung habe ich nämlich auch schon -ganz unabhängig vom hiesigen vR-Holzschwellenproblem- gemacht.
Übrigens habe ich die vR-Holz in mehreren Variationen schon erfolgreich getauscht. So z.B. auf der Konstanz-Villingen (bzw. der gesamten Schwarzwaldbahn damals). Da lagen anfänglich auch andere Gleise. Es gab keine Probleme.
Was ist denn, wenn du paar Trennungen selber machst?
Für Szenarien sollte das egal sein. Pass aber auf, dass da nicht gerade ein Gleismarker liegt, der ist dann futsch und DAS ist den Szenarien nicht egal.
Die vR-HQ-Gleise sind halt recht komplex. Vielleicht ist das der Preis, den man bezahlen muss, nämlich dass die empfindler sind als das potthässliche Billig-Geraffel, was manche so verbauen.
Nachtrag:
Ich konnte die Gleisanlage von Knoedel mit meinem Script anheben.
Will sonst noch jemand?
Angehoben werden nicht nur die Gleise, sondern auch alle Objekte mit Gleislink: Signale, Magnete, Lf7..., aber keine Oberleitung und natürlich und auch keine manuell verlegten Weichenantriebe.
Und nein, ich kann das Script nicht der Allgemeinheit zur Verfügung stellen, da es sich um ein serverseitiges Perl-Script handelt.
Das erschien mir damals als nur für einen einzigen Zweck entstandenes "One Shot"- bzw. "Fire-and-forget"-Script als einfachste Methode. Ich hätte nicht gedacht, dass ich es mehrmals benutze.
Egal... wer da Handlungsbedarf hat, kann sich ja hier oder privat bei mir melden.
Ich benötige die betreffende Tracks.bin ([loriot] Ach was!? [/loriot]) und den gewünschten Wert des Anhebens/Absenkens in Millimeter ([louis de funes] Nein! Doch! Oh!! [/louis de funes]) 
Wurde DirectX9 installiert?
Das Setup befindet sich im "Railworks\Install"-Ordner.
Unter Umständen hat die (ordnungsgemäß erstellte) Tracks.bin aber nicht mehr dieselbe Größe, wie die vor dem Gleise heben/senken.
Nämlich dann, wenn Gleise von Höhenmeter 9.991 (=5 Bytes) nach z.B. 10.027 (=6 Bytes) angehoben werden.
Zum eigentlichen Problem:
Ich musste auch mal Gleise heben (oder senken? Ich habs vergessen!).
Der Versuch, dies mit RWTools zu machen ist jedenfalls damals total in die Binsen gegangen. Warum weiß ich nicht.
Ich hab mir dann selbst ein Script geschrieben und damit ging das dann recht gut.
Aber wie immer beim Ändern der Tracks.bin und dem Rück"serz"en gilt:
Überprüfe alle Stumpfgleise, ob die Endgeometrien (Schotterendkappen und manchmal auch Prellböcke) da noch liegen, wo sie sein sollen. Bei manchen Gleisen verschieben die sich gerne. Muss man unbedigt prüfen! Lässt sich aber sehr einfach im Editor reparieren.
Für die Installation ist er aber eher unproblematisch, da er im Dümmsten Fall ein vorhandenes Asset mit einer anderen Version Überschreibt. Das bereitet aber eher selten Probleme.
Das sehe ich ganz anders.
Es passiert andauernd, dass die Utlitites.exe neuere Versionen mit alten Versionen überschreibt, weil sie keine Versionierung kennt.
Unter einem Paketmanager stelle ich mir was anderes vor.
Ich rate von der Benutzung der Utilities.exe ab, weil man sich die vermeindlich vereinfachte Installation (ich finds nicht einfacher) mit zahlreichen Problemen erkauft: Gelöschte Assets, die in Benutzung sind und Installation alter Versionen, wo vorher mal eine neuere Verison war.
Das RWP-Format ist gar nicht das Problem, sondern die total lahmar§chige Utilities.exe.
Und dann kommt noch dazu, dass man sich beim Deinstallieren viele andere Sachen zerschießt, weil es kein echtes Paketmanagement ist, das Abhängigkeiten berücksichtigt.
Ich hab dieses Programm noch nie gemocht und entsprechend selten genutzt. Auch schon als Neuling vor 1000 Jahren.
Aber letztlich ist es auch egal, denn ein RWP stört mich nicht. Mir ist es egal, weil RWP halt auch nur ein umbenanntes Archiv-Format ist, das man sehr einfach entpacken kann.
Die Dateistruktur des TS ist außerdem so einfach gestrickt, dass es sehr einfach ist, manuell ohne Utilities.exe Installationen und auch Deinstallationen durchzuführen.
Seit Anbeginn meiner TS-Zeit schleppe ich denselben Asset- und auch Content-Ordner mit mir rum. Da brauchte ich selbst bei einem PC-Wechsel nichts zu installieren (außer dem Core natürlich). Ja wie einfach ist das denn?!
Ich hab noch nie eine Steam-Überprüfung gemacht und kann nur jedem anraten, die strunzdumme, schnarchig lahmar§chige und auch zu Abstürzen neigende Utilities.exe nicht mehr zu benutzen. Steckt die Wartezeit die ihr mit der Utlities,exe vergeudet lieber in ein Studium, wie die Dateistruktur des TS aufgebaut ist. Das macht das TS-Leben unendlich leichter, schneller und einfacher.
Aber das muss natürlich jeder selbst wissen.
Also ich kenne keine leider keine Möglichkeit, die im Zugverbandseditor erstellten Zugverbände in einem Szenario nutzen zu können, indem man sie im Szenario-Editor einfach links auswählt und dann aufgleist. Diese Zugverbände sind meines Wissens ausschließlich für die Benutzung im "Schnellen Spiel" und da auch nur als Spielerzug.
Die ganzen KI-Züge, die einem im "Schnellen Spiel" entgegenkommen (sollen) oder rumstehen (sollen), müssen anders erzeugt werden.
Bei anderen Szenarien außer dem "Schnellen Spiel" sind diese Zugverbände nicht ohne Weiteres zu benutzen. Dort muss man sich die Züge jedesmal per Hand neu zusammenstellen.
Es gibt zwar auch im Szenario-Editor die Möglichkeit, vordefinierte Zugverbände aufzugleisen, aber die werden anders definiert, als die für das "Schnelle Spiel" gedachten Zugverbände aus dem Zugverbandseditor. Vielmehr müssen diese entweder mittels RWTools oder dem BluePrint-Editor erzeugt werden.
Kurz: Es gibt 2 Sorten von Zugverbänden.
Erstens die Sorte, die man sich bequem im Zugverbandseditor zusammenklicken kann.
Vorteile:
Einfach
Wysiwyg (Vorschau)
Man kann nur das verbauen, was man wirklich hat.
Nachteil:
Kann nur als Spielerzug in einem Schnellen Spiel benutzt werden.
Keine Beladungskontrolle: Wenn ein Waggon die Möglichkeit bietet, beladen oder unbeladen zu sein, wird er hier immer beladen, was sich leider überhaupt nicht in der angezeigten Tonnage widerspiegelt, was meines Erachtens ein Bug ist.
Diese Zugverbände werden alle abgespeichert in "...\RailWorks\Content\ConsistTemplates.bin"
Und Zweitens die Sorte an Zugverbänden, die man auch im Szenario-Editor aufgleisen kann und die einem auch im "Schnellen Spiel" als KI entgegenkommen können.
Vorteile:
Universeller einzusetzen und zwar sowohl als Zugverband im Szenario-Editor, als auch als KI in einem "Schnellen Spiel"
Bessere Kontrolle über das, was benutzt werden soll
Beladungskontrolle: Hier kann bei Waggons, die beladen werden können, gewählt werden.
... plus weitere Konfigurationsmöglichkeiten
Nachteile:
Kompliziert
Viel Arbeit
Keine Vorschau beim Erstellen
Diese Zugverbände befinden sich im Preload-Ordner des jeweiligen Providers unter dem jeweiligen Produkt. Und dieser Provider mit seinem Produkt sind es auch, die man dann im Szenarioeditor freischalten muss. Es kann sein, dass es Folgeabhängigkeiten gibt, z.B. bei den Kupplungen oder dem Sound. Diese Provider-Products müssen natürlich ebenfalls freigeschaltet werden, wenn man einen solchen Zugverband aufgleisen möchte.
Unbedingt das Wiki lesen, dort ist ein sehr hilfreicher Artikel von (ich glaube) nobsi zur Thematik der Zugverbandserstellung (Sorte 2)!
Ich hoffe, dass das hilfreicher ist als mein 1. Beitrag
Gute Antwort!
Ich habe viel zu kompliziert gedacht und irgendwie auch nicht richtig gelesen.
Danke
Die findest du alle in der Datei
...\RailWorks\Content\ConsistTemplates.bin
Leider wurde (wieder einmal) kein DEM-Gelände benutzt und auf Höhe 0 Meter auf einem glatten Billiardkugel-Planeten gebaut.
Selbst die norddeutsche Tiefebene ist nicht sooo platt.
Das ist doch wirklich nicht schwer, sich ein paar Geländekacheln zu importieren, oder?
Ja, ist fiktiv... ich weiß. Aber dann schnappt man sich halt ein Gelände, das einem zusagt, egal ob das nun das Gelände aus Sibirien, der Vulkaneifel oder der Wüste Gobi ist.
Seufz
Nur leider wäre der TS mit so einem Streckennetz völlig an der Grenze. Als Einzel DLC ok, aber nicht die Strecken zusammen.
Das würde der TS schon packen meiner Meinung nach.
Außer der Gleisanlage, die komplett ins Ram muss, geht ja alles über Kacheln, die beständig nachgeladen werden.
Die Gleisanlage von Münster-Bremen (ca. 850 km Gleisvolumen) ist etwa doppelt so "fett" wie die von Freiburg-Basel (ca. 420 km Gleisvolumen). Und selbst bei Münster-Bremen ist noch reichlich Platz nach oben, seit es den TS in 64 Bit gibt.
Also da mache ich mir keine Sorgen, dass der TS das nicht packen würde.
Ja, kenne ich ebenfalls sehr gut.
Ich legte mal eine kaputte nVidia GTX 6-hundertirgendwas in den Backofen. Danach lief sie ohne Störung noch für ~6 Monate.
In dem Fall war es wohl eine kalte oder sonstwie kaputte Lötstelle.
Ich denke aber nicht, dass das hier der Fall ist. Dazu beschränken sich die Störungen zu sehr auf nur die Bodentexturen.
Gehen wir doch mal sachlich nüchtern da ran.
Eine Textur ist ein zusammenhängender Speicherbereich im Grafik-Videoram.
In den Bildern ist aber ganz klar zu sehen, dass der Speicherbereich für die betreffenden Bodentexturen mit Datenmüll überschrieben wurde. Das Muster ist nun wirklich eindeutig. Jeder, der mal eine kaputte Grafikkarte oder sonstwie visuelle Störungen im Computerbild hatte, kennt die Charakteristik dieser Bitmüll-Grafik sehr gut.
Wer überhaupt nicht weiß, was gemeint ist, dem sei diese Grafik eines Speicherfehlers ans Herz gelegt:
https://www.alamy.de/pixel-mus…ehler-image244951512.html
Ich habe diese Muster schon dutzendfach gesehen. Sie haben mit der Leistung eines Systems überhaupt nichts zu tun.
Sie sind immer das resultat von entweder:
- Überhitzung (Ram verstolpert sich)
- Software: Schreiben in belegte Speicherbereiche
- Treiber: Kann fehlerhaft sein
- Kaputtes Ram/Videoram
- Kaputter Ram-Controller
- Stromschwankungen
- Starke ionisierende Strahlung (ja wirklich), starke elektromagnetische Einflüsse, Nässe/Kurzschluss
- Eventuell Inkompatibilität: fehlender Treiber, exotische/fehlerhafte Hardware-Firmware, falsche Dateninterpretation (Big Endian/Little Endian) oder falscher Datentyp (24Bit-Farbtiefe?)
- Datenträger mit den Texturen kaputt und liefert kaputten Schrott
- Archiv (ZIP, RAR,...) der Quelle kaputt oder fehlerhaft/unvollständig entpackt (sollte eigentlich abgefangen werden, aber habe ich durchaus schon gesehen)
...und paar Sachen mehr
Diese Liste reduziert sich entsprechend, wenn man berücksichtigt, dass anscheinend immer nur die Bodentexturen betroffen sind.
Aber die Leistung selbst ist irrelevant.
Haben wir das nun endlich geklärt? 
... und dennoch ist jede alte oder und billige "Gurke" in der Lage, Texturen zumindest farbtreu anzuzeigen,... verpixelt und verwaschen zwar aber ganz sicher nicht mit Speicherdump-Bitmüll wie hier.
Und wie erklärst du dir den Umstand, dass das Problem vorher nicht da war bei identischer Hardware.
Es ist jedesmal dasselbe... vorschnell wird immer das Alter oder die Güte von Hardware herangezogen. Es gibt aber auch Fehler und Probleme, die damit nichts zu tun haben und das hier ist so ein Fall, wie mir scheint.
Der Bitmüll ist aber kein Resultat zu alter Hardware sondern ein Fehler.
Wäre die Hardware nur zu alt oder sonstwie unzureichend würde es einfach nur schlecht aussehen und ruckeln, aber es würde nicht fehlerhaft aussehen wie hier.
Außerdem sagt er ja selbst, dass es bisher nicht so war.
Also bitte hört auf, diese Probleme auf lahme Hardware zu schieben! Hier ist was anderes im Busch.
Auch euer so hochgelobte Talent ist so eine Mistkrücke der den TS von der Performance her mehr als runterzieht.
Der fiel mir auch sofort ein
Allerdings hatte meine alte GTX 660 TI damit ordentlich zu kämpfen wobei der GTX 1060 das mehr oder weniger am A..vorbei geht und selbst bei Schattenwurf kaum Performance Einbrüche zeigt
Kommt halt auf die Menge an, was da im Bf, Bw, Gbf oder sonstwo so rumsteht und rumleuchtet. Der Kram muss ja nicht zwingend fahren (oder doch? 
)
Interessant...
erinnert mich an sogenannten "Bitmüll", den man sehen kann, wenn Grafikkartenspeicher kaputt ist. Allerdings kenne ich das bislang nur vom Desktop, aber es ist wohl nur logisch, wenn sich in einem 3D-Game das so manifestiert wie hier.
Das wäre also meine erste Vermutung.
Eventuell käme noch inkompatibler(?) oder zu alter(?) Treiber (MacBook?) in Frage oder natürlich thermische Probleme.
Kurios ist bloß, dass es immer die Bodentexturen sein sollen, die so rumspinnen. Warum nicht mal was anderes?
Ich würde mal testen, was passiert, wenn man den Ordner "MixMaps" deaktiviert. Eventuell stimmt ja was mit den Bodentexturen nicht. Kaputt weil Archiv kaputt war? Oder Platte kaputt?
Oder sind das keine Bodentexturen, sondern Decals?
Man muss halt testen und das Problem versuchen, einzukreisen.
Sind viele Lichtquellen in der Umgebung?
Fahrt ihr nachts?
Zu viele Lichtquellen mit aktiviertem Schattenwurf verursachen genau die von euch geschilderten Probleme.
Frage:
Wie is'n das?
KI-Loks tagsüber: Haben die das Licht an?
Meines Wissens haben die Lichter bei Lokomotiven sehr häufig den Schattenwurf aktiviert. Das kostet ordentlich Leistung, wenn da mehrere rumstehen.
