Wird man aber auf kurz oder lang nicht drumherum kommen denn die Entwicklung geht immer weiter.
eben. und ich bin überzeugt, dass auch RSC das weiß. Denn davon hängt ihr komplettes Geschäft (die DLCs) ab. Deswegen denk ich: er wird kommen. Aber er darf nicht zu früh kommen. Die Kunden müssen erst ausreichend Chance haben, sich an neues Material zu gewöhnen. Denn einiges "Altmaterial" wird nicht mehr funktionieren, wenns soweit ist.
hmmm .... der soundtrack hört sich nach dem ganzen clipping-master-desaster sogar noch erstaunlich brauchbar an
(es gibt z.B. keine BR 247, auch wenn Schenker die so führt)
öhmm .. dat is jez aber irgendwie n Widerspruch.
Wenn Schenker die führt, dann gibbet die (meinetwegen nur bei Schenker).
edit:
man könnte natürlich sagen, nur UIC-Nummern ... aber dann würde man ja alles mögliche pre-UIC ausschliessen
(oder hat sogar der Nürnberger Adler ne UIC-Nummer bekommen??)
boah ey .. schon toll, um was du dir alles Gedanken machst 
... auch wenn "Normalos" wie ich das nie jemals in ganzem Umfang kritisieren oder wertschätzen können.
(kleines Problem am Rande: da werd ich mich wohl nie trauen, irgendwas von meinen Strecken jemals zu veröffentlichen)
schaut (für mich) klasse aus. Nur kein Stress, aber weiter so 
(ich liebe Altbau-Eloks)
Es gibt ja außer den Quickdrive (schnelles Spiel) Szenarien hier im Downloadbereich auch viele auf railsim-fr ( http://www.railsim-fr.com/foru…?app=downloads&showcat=30 ) - vielleicht findest du da noch was.
Der Hitachi SEC (Super Express Concept) war im TS 2012 und TS 2013 enthalten. Aktuell im TS 2014 wohl nicht mehr, und einzeln ist er nicht erhältlich. Vielleicht kommt er wieder als Workshop-Addon.
Tab gedrückt? AWS wird noch mit Q quittiert 
find ich gut ... den kann man ja wirklich auf "tausenden" Strecken gebrauchen. Und als KI im Quickdrive ist PZB eh irrelevant 
Der Grashalm steht 3 cm zu nah am Gleis. Das geht ja garnicht
Mein Tipp: es gibt da bei JustTrains so nette Reinigungs/Unkrautvernichtungswagen ...
Vielleicht hilft ja auch der fleissige Gebrauch einer Magnetschienenbremse (wegen Erhitzung).
zum Thema ostdeutsche Strecken:
- es gibt zwar passende Dampf- und E-Loks, aber praktisch keine Dieselloks (Ludmilla passt ja nun weder auf Nebenstrecken, noch auf 200m-Kurvenradien, und Rangier-Loks sind komplett Fehlanzeige)
- es gibt dank Mathias (rw0381) zwar ne Menge Reiszugwagen, aber Güterwagen muss man sich mühsam aus DB-Logo-freien Ep3 Bestand zusammensuchen
(oder hab ich was verpennt?)
jo, KI ist vorhanden, sowohl stehend als auch fahrend (fahrend nicht nur Gegenverkehr sondern auch in gleicher Fahrtrichtung), fahrend aber recht wenig (erster Eindruck).
Die First Capital 321 (getrenntes Addon, aktuell im Bundle) find ich interessanter als die 365, sowohl vom Cab als auch vom Sound her (die 365 hat keinen erkennbaren Motorsound, sondern rauscht nur so vor sich hin).
Bei beiden find ich es schade, dass die Kamera in der Passenger View nur eine sehr geringe Beweglichkeit hat.
jo, sind zwar eng, aber machbar. Dass ich doch noch 6 Punkte an den 1000 vorbeigeschrappt bin, lag nur daran, dass ich im Endbahnhof die Reduzierung von 30 auf 25 um wenige Meter verpennt hab.
jo, im Augenblick ist sowas nur lästig bzw inkompatibel. Irgendwann wird der TS sowas ganz abschießen - aber ob das in 2, 5 oder 8 Jahren der Fall ist, weiß nur - hmm - keine Ahnung.
Wenn der nämlich fehlen würde, dann würden aktivierte Mods bei einer Steam-Überprüfung beseitigt/zerstört, weil sie zu diesem Zeitpunkt ja nicht mehr im JGSME-Ordner wären.
und dann wäre der JSGME auch für RW ziemlich witzlos, weil die meisten Updates ja eher ohne große Vorankündigung kommen - da hätte man ja gar keine Chance, vorher die Mods zu deaktivieren.
Aber da kann nichts passieren.
Das mit dem ausgrauen ist auch eher für Nicht-Steam-Spiele wichtig, denn wenn mehrere Mods dieselben Dateien ändern, könnte JSGME je nach der Reihenfolge in der man die Mods wieder deaktiviert, den Originalzustand nicht wiederherstellen. Ist bei Steam aber auch keine Thema, weil man den jederzeit per Dateiüberprüfung zurücksetzen könnte.
Allerdings fasse ich auch so nen Stapel AP Sounds (oder TTB, oder 3DTrains) zusammen und steck sie nicht alle einzeln in den JSGME - das artet ja sonst in eine Klick-Orgie aus ...
Wenn du nur den Engine Ordner nimmst, fehlen die Verzeichnisse dazwischen. Die musst du in diesem Fall eben von Hand anlegen, das muss dann (z.B.) so aussehen:
Steam/Steamapps/Common/Railworks/MODS/Ludmilla/Assets/RSC/BR232Pack01/Audio/Railvehicels/Diesel/Ludmilla/Engine/xy.dav
Dabei ist MODS der Mods-Ordner von JSGME, und Ludmilla nur ein Beispiel für den Namen deines "Mods", kannst du frei wählen, unter diesem Namen wird das dann in der Mod-Liste des JSGME sichtbar.
du musst aber zumindest wissen, wohin das Soundfile soll. Diesen Pfad (unterhalb des Railworks-Verzeichnis) musst du genau so im MODS-Unterordner mit dem Namen deiner Wahl anlegen,
also z.B. ... railworks\MODS\modname-deiner-wahl\assets\....
Hm, bei mir ist er mit nem Vertex Error ausgestiegen, könntest du viel leicht die DT Daten hochladen/mir schicken?
Vielleicht warst du nicht am Route Origin. Wenn du in der aktuellen 3CCR Version gleich den Welt-Editor startest, stehst du nicht am Origin, sondern in Rorschach.
Am sichersten ist: neues Freeroam-Szenario (z.B. "DT Generierung Sommer") erstellen, dabei Route Origin als Startposition wählen, im Szenario-Editor sofort speichern. (Für Wintergenerierung vor dem Speichern nur noch die Jahreszeit ändern). Dann kannst du jederzeit das Generierungsszenario starten, da dann sofort in den Welteditor und generieren.
Ich hab als Demo mal Distant Terrain mit Sommer und Wintertexturen für die 3CCR angehängt. Das Paket überschreibt keinerlei Dateien der 3CCR, kann also problemlos wieder deinstalliert werden.
--> sorry, Anhang enthält nur Sommertexturen, sonst wärs zu groß geworden.
Als ich das Tool anwendete zeigten sich die Berge mehr oder weniger halb durchsichtig, was vermutlich erstmal die Folie war, die generiert wurde.
Gut möglich, während der Generierung wechselt der Boden vor einem gelegentlich die Farbe
---
Bei der Generierung von Frühlingstexturen für das DistantTerrain der 3CCR gabs ein Problem:
- Bild 1: Ansicht des Preview-Fensters während der Generierung
- Bild 2: so siehts dann ingame aus.
Ursache:
In der Strecke wurden in der Bauzeit Texturen verwendet, die aktuell nicht mehr vorhanden sind. Das stört normalerweise nicht, weil die Texturen beim Bau der Strecke aus dem verwendeten Texturset (in diesem Fall Kuju) in die Strecke kopiert werden (in den Mixmap-Ordner). Bei der Generierung des DT greift der TS aber wieder auf den ursprünglichen Texturset zu, und da fehlen seit irgendeinem TS-Update ein paar Texturen; Hinweise dazu auch in http://railworksamerica.com/forum/viewtopic.php?f=34&t=9583
Hier müsste man also erst mal das Kuju-Texturset flicken, bevor man DT mit sauberen Frühlingstexturen für die 3CCR erstellen kann.
edit:
Die genaue Fehlerursache ist unklar. Da in Wiederholungsversuchen auf der selben Strecke ohne Texturänderungen einige DT-Läufe komplett fehlerfrei waren, andere aber diesen Fehler hatten, kann es eigentlich nicht am Texturset der Strecke liegen. Mögliche Ursachen:
- Reste von alten DT-Läufen im Terrain-Ordner
- geringfügige Abweichungen vom Route-Origin beim DT-Lauf.
- ???
ja, korrekt.
Bei den Jahreszeiten sollte man bedenken, dass DT ja nur in großer Entfernung angezeigt wird. Frühlung- und Herbst-Variante werden sich da vermutlich nur selten sichtbar von der Sommer-Variante unterscheiden.
Ergänzung: die Überblendung auf die DT-Texturen erfolgt teilweise viel früher (näher), als ich ursprünglich gesehen habe. Das scheint von den Fog-Entfernungswerten der Strecke abzuhängen (was ja auch sehr sinnvoll ist).
Ich muss noch mal auf die Vorstellung einer "Fototapete" zurückkommen - rückblickend erscheint mir das eher irreführend, auch wenn es den optischen Eindruck beschreibt. DT ist ja keine feststehende, vertikale Kulisse wie z.B. die Wald- und Hauszeilen-Lofts, die oft zur Begrenzung der Sichtweite verwendet werden ("Schlauchlevel", z.B. auf Köln-Düsseldorf), sondern eine Möglichkeit zur Erweiterung der Sichtweite. Eine komplette, deckungsgleiche Kopie des Geländes, in stark reduzierter Auflösung, für die Anzeige in großer Entfernung. Also eine Mipmap / LoD-Variante für Gelände.
Dieses zusätzliche Gelände kostet natürlich Performance, aber bei weitem nicht soviel, wie es kosten würde, wenn der TS einfach die maximale Render-Distanz für das Standard-Gelände auf 25 oder mehr Kilometer erhöhen würde.
Man kann DT versuchsweise erzeugen, und wenn man feststellt, dass es auf der Strecke nichts wesentliches bringt, einfach die DistantPatches.bin (und, der Ordnung halber, auch die erzeugten Texturen) wieder löschen, und damit ist auch die Performance wieder wie vorher. Das könnte auch jeder Benutzer individuell machen, da es keine weiteren Abhängigkeiten zur Strecke gibt.
-----
hab mal eben DT für die 3CCR generiert (Dauer ca. 5 Minuten für einen Durchlauf).
Blick von Lindau (Start im Szenario "Von Hafen zu Hafen") grob Richtung Süden
Bild 1: original
Bild 2: mit DT
na, wen das nicht überzeugt ...
man erkennt auch schon, wo man noch etwas DEM importieren müsste (etwas rechts von der Bildmitte Bild 2)
da stellt sich eher die Frage, ob es irgendein Problem mit dem Schreibzugriff auf der Railworks-Installation (insbesondere der Szenario-Database) gibt.
Texturen:
die DT-Funktion guckt sich quasi das Gelände was gerade im World Editor zu sehen ist aus großer Höhe an. Wenn man in Standard-Jahreszeit editiert, wird automatisch ne Standard-Textur erstellt. Wenn man z.B. ein Szenario im Winter startet, daraus den Welt-Editor aufruft, und da dann die DT-Funktion werden die Texturen so wie Gelände gerade aussieht erzeugt, und automatisch mit _Wi Postfix gespeichert (im Anhang Beispiel direkt aus dem textures Verzeichnis der SBB-Route nach meiner Neugenerierung - einmal Standard, einmal im Winter - konvertiert nach jpg, tatsächlich generiert wird dds und tgpcdx)
woher weiß ...
Das gesamte Terrain liegt mehrfach "übereinander" vor.
Einmal ein "normales" Gelände in voller Auflösung:
- die DEM Kacheln in <routeid>/terrain/+xxxxxx+yyyyyy.bin
- und die zugehörigen Texturen in der Mixmap
Zum zweiten das low resolution Distant Terrain (die Vorstellung einer topografischen Landkarte niedriger Auflösung ist hier wohl besser als die einer Fototapete):
- Höhenwerte des Geländes zusammengefasst in einer einzigen Datei <routeid>/terrain/DistantPatches.bin
- Texturen in den Textur-Kacheln in <routeid>/terrain/textures - jeweil 8x8 "normale" Kacheln in einer Texturkachel zusammengefasst. (Wenn man das textures Verzeichnis mal mit 'nem Viewer betrachtet, der dds anzeigen kann (z.B.xnview), hat man die Landkarte schon vor der Nase.)
Zur Laufzeit zeigt der TS immer abhängig von der aktuellen Kamera-Position an
- Szenerie nur die ersten 1 oder 2 km
- DEM .. hmm .. irgendwas um 8 oder 10 km, weiß ich nicht genau
- danach nur noch Distant Terrain
also auf jeden Fall: DT muss nur einmal erzeugt werden - es wird das komplette Streckengelände abgebildet.
das aber evtl mehrfach für verschiedene Jahresszeiten,
und es kann beliebig oft wiederholt werden, wenn man mehr DEM importiert oder größere Gelände-Texturierungen macht (aber DT wird ja nur in großen Entfernungen angezeigt, daher wäre es unsinnig bei kleineren Texturierungen neu zu generieren)
p.s.:
das Thema ist durchaus nicht nur in den Alpen von Bedeutung.
z.B. gibts auch im Rheintal Abschnitte wo man so weit geradeaus sehen kann, dass man im TS an die Sichtbarkeitsgrenze des normalen Geländes kommt (z.B. Remagen Richtung Andernach)
Dann kann man sich das Distant Terrain also quasi als eine aus bereits bestehenden DEM-Kacheln generierte Fassade bezeichnen, ähnlich einer Fototapete .....
genau das ist es. (edit: "Fototapete" ist irreführend, siehe unten, Beitrag 11)
Das DEM-Gelände selbst (und dessen Texturen) wird nicht beeinflusst.
Im Übergangsbereich zwischen der "normalen" Geländedarstellung des TS und der Anzeige des Distant Terrains kann es durch die Überblendung natürlich optisch eine Änderung geben (z.B. wenn man im Distant Terrain noch keine Wintertexturen erzeugt hat, aber ein Szenario im Winter fährt .. und das Gelände so ist, dass man quasi seitlich die Hügel/Berge über eine große Strecke sehen kann, und man auch entsprechende Fog-Einstellungen hat).
Was mich noch etwas irritiert, ist, dass Kris sagte, die Funktion hätte ihm das Gelände überschrieben. Das kann ich mir bisher überhaupt nicht vorstellen - und ich hab schon einige Experimente mit meiner Almetalbahn, Berner Oberland, Werdenfelser Land und Gesäuse gemacht. Vielleicht betraf Kris' Beobachtung ja auch nur die Texturen in der Überblendungs-Entfernung.
thenilsman
3CCR werd ich sicher demnächst auch mal in dieser Hinsicht testen. Aber seit meinem HD-Crash hab ich außer dem Steam/RSC Kram noch nicht sehr viel wieder installiert - dauert also noch.
120
ich sehe da keine Nachteile. Das Distant Terrain wird ausschließlich in der <route-id>/terrain/DistantPatches.bin gespeichert (da stehen die Höhendaten als blobs drin) und die Texturen in <route-id>/terrain/textures - jeweils 8x8 "normale" Kacheln in einer Textur, Jahreszeiten mit den üblichen Endungen.
Ich habe in meinem "Werdenfelser Land" (Murnau-Garmisch) mehrfach DEM im Bereich Alpspitze/Zugspitze nach importiert, weil im DT noch Schnitte sichtbar waren. Gelegentlich gab es Abstürze, vermutlich weil ich gleich an Ort und Stelle des Imports die DT-Funktion gestartet habe. Nachdem ich in diesen Fällen den Editor neu am Route Origin gestartet habe, ging die Generierung aber sauber durch.
Wenn man Distant Terrain wiederholt erstellt, wird einfach (sobald man mit F2 abspeichert) die existierende DistantPatches.bin überschrieben, und die Texturen entsprechend der aktuellen Jahreszeit im Welteditor neu generiert. In der DistantPatches.bin steht das komplette Höhenmodell der gesamten Strecke - in gegenüber dem DEM-Terrain stark reduzierter Auflösung. Zur Laufzeit wird das dann als Kulisse "hinter" dem normalen Gelände gerendert (falls der Fog aus den ToD Dateien entsprechende Sichtweite zulässt).
Wie immer beim Bau ist es von Vorteil, im Fenstermodus zu arbeiten - da sieht man besser was gerade läuft.
