Beiträge von nobsi

kleines Update:
ich habe ein Distant Terrain Patch (inkl. Sommer- und Wintertextur, und ein paar dringend erforderlichen DEM-Kacheln) für die 3CCR hochgeladen.

Man sieht natürlich an vielen Stellen, dass die Texturierung der Strecke nicht für Distant Terrain konzipiert ist, es wirkt so meines Erachtens aber trotzdem besser.
Vielleicht gibt es in Zukunft auch mal einen Distant Terrain Patch mit überarbeiteten Texturen. Aber 1000-2000 Quadratkilometer Gelände zu texturieren ist viel Arbeit,
und passende Textureinträge muss ich teilweise auch erst noch machen, weil der alte Kuju-Texturset das nicht hergibt.

p.s.:
DT Patch ist mittlerweile online

Zitat von StefanKleist

Und, wenn ich die Steamprüfung laufen lasse dann muß ich das Update für Garmisch und was sonst noch durch die Steamüberprüfung wieder geändert wird auch nochmals einspielen?

Das Garmisch-Update wahrscheinlich nicht. Die Originalstrecke ist komplett in .ap Dateien verpackt, das Update schreibt geänderte Dateien außerhalb der .ap Dateien. Die Steamüberprüfung kontrolliert nur die ap Dateien.

hmm .. Texturgenerierung ohne Geländekacheln - hab ich noch nicht gemacht, aber ich denke, die Texturgenerierung orientiert sich ohnehin an den MixMap-Kacheln und nicht an den Terrain-Kacheln (die müssten nach Speichern und Neuladen der Strecke eigentlich sowieso synchron sein [edit: ist nicht so]). Man muss dann natürlich die DistantPatches.bin aus dem Lauf mit Gelände sichern und nachher wieder reinkopieren, müsste gehen.

Die Ergebnisse kann man im Grunde alle einzeln hin und her kopieren.

Terrain/DistantPatches.bin = das Distant Terrain (nur die Silhouette)
Terrain/textures/tile*.TgPcDx = die DT-Texturen (fertige Texturen, d.h. die benutzten Environment-Texturen werden nicht benötigt)
Terrain/xxxxxxxyyyyyyy.bin = das "große" Gelände-Höhenmodell
MixMap/xxxxxxxyyyyyyy.bin = die Texturmaps für das "große" Gelände (3 Texturnummern je Texturkachel, Environment-Texturen werden zum Mischen der endgültigen Textur benötigt)

Ich hab z.B. die M-GAP Texturierung in einer eigenen leeren "Strecke" mit selber Route-Template und Route Origin gemacht und dann die MixMap in die richtige Strecke kopiert. Ist gerade im Alpenbereich halt wesentlich einfacher, wenn bei der Texturierung das Google Overlay flach liegt (keine Parallax-Fehler).

ich vermute eher, dass das RSDL Foliage Pack (wieder mal) fehlt.

edit:
ach nee, das Dreiländereck nutzt die ja nicht mehr

@NoFly
ok, das ist jetzt mal ein triftiger Grund (der einzige mir bisher bekannte), den es allerdings erst seit wenigen Tagen gibt. Die BR121 ist bisher das einzige Addon mit Provider "DTG".

nach einigem Chaos nun mal wieder ein kleines Update.
Ich hab gestern in vielen DT-Generierungen auf der 3CCR ausschließlich diese gestörten Texturen bekommen. Seltsamerweise fiel das in Game aber nicht auf, da wurde weiterhin die Fake-DT Farbe aus der Environment-Texturdatei angezeigt.
Da ich ja Verschiebungen der Kamera gegenüber dem Route Origin im Verdacht hatte, hab ich (unter anderm) auch mal die Generierungs-Szenarios neu erstellt, und damit ging es dann - erstmal. Aber das war nicht das entscheidende.

Entscheidend ist die unscheinbare Datei "Album.png" im Texturverzeichns. Das scheint eine Art Cache zu sein, der 256 4x4 Pixel große aus der "großen" Mixmap runtergerechnete Texturen enthält. Wenn man nun weitere DEM-Kacheln am Rand der Strecke importiert, kann sich die Bounding Box des gesamten Geländes verschieben, und das Verkleinerungs-Raster für die neuen DT-Texturen passt nicht mehr zum Raster der alten DT-Texturen --> an den Kanten entstehen schwarze Fehlstellen. Bei meinen gestrigen DT-Läufen auf der 3CCR sind die schwarzen Streifen mit jedem Lauf breiter geworden: ich hatte auch vor jedem Lauf wieder zusätzliche DEM-Kacheln importiert.

Die wichtigsten Punkte aus meiner Sicht:
1. DT am Route Origin generieren. Startet man an anderer Position, werden falsche bzw. zu wenig DT-Kacheln erzeugt.
2. Wann immer man weitere DEM-Kacheln importiert, vor der nächsten DT-Generierung zumindest die "album.png" löschen. Es ist sicher sinnvoll, auch die vorhandenen DT-Texturen zu löschen, da sich das Kachel-Raster möglicherweise verschoben hat, und die vorhandenen Texturen sich dadurch auf dem Gelände verschieben können.
3. Zwischen DT-Läufen für verschiedene Jahreszeiten nichts löschen

In der fertigen Strecke sind weder "album.png" noch die dds Dateien erforderlich.

Jetzt wüsste ich nur noch gerne, wieso in meiner Arbeitsversion der 3CCR (in der ich das DT erzeuge) immer noch die Fake-DT Farbe aus der Environment-Texturdatei angezeigt wird, während in der "Hauptversion" die DT-Texturen angezeigt werden....

Zitat von Safter

Du müsstest RSC dann auch RC abkürzen.

nö, RailSimulator.com haben die Abkürzung "RSC" selbst gewählt. Als sie die Handelsmarke Dovetail Games geschaffen haben, haben sie sie ganz zu Anfang auch mal als "DG" abgekürzt. Aber sie verwenden (vermutlich aus Corporate Identity Gründen) keine Abkürzung mehr.
Das Logo ist eine Kombination der Marken-Initialen (DG) mit einem stilisierten Schwalbenschwanz (=Dovetail)
Bleiben wir einfach bei RSC, die Firma heißt ja immer noch RailSimulator.com

ich weiß, dass ich da auf verlorenem Posten stehe. Daher "korrigiere" ich auch gar nicht erst, wenn jemand DTG schreibt.
Aber ich selbst schreibe auch nicht "SZADMKTSPTDL" statt "SPD" (Unterschied: Initialen der Silben oder der Wörter).

Dovetail Games
(falls dir Doofe Tail Games lieber ist, ist das deine Sache)

zu den Updates geb ich dir ja grundsätzlich recht. Das Problem ist nur: DG setzt seit einiger Zeit bei den Szenarien voll auf den Workshop.
Ein Update zu veröffentlichen, das die Workshop-Szenarien gefährdet, nagt an den Geschäftsgrundlagen. Die internen Diskussion kann ich mir lebhaft vorstellen.

und RSC (DG) hat m.E. durchaus seine Gründe dafür.

Zitat von Norbert Koch

Wenn sie den Simulator umbenennen ist Ruhe.

wie kommst du darauf?
Das Wort "Simulator" ist keine Definition per se. Argumentationen, die ausschließlich auf einem solchen (Management/Marketing-) Buzzword beruhen, sind von vorneherein wertlos. Der TS bietet weder im Bereich Optik/Szenerie noch bei der Bahntechnik Perfektion - aber einiges an Möglichkeiten. Man muss es nur nutzen - und da fängt das Problem an. Die zahlenmäßig meisten Addons liefert RSC, aber RSC bedient ganz klar die Klientel, wo das meiste Geld zu holen ist, und das sind halt nicht die Handvoll ernsthaft bahntechnisch Interessierter.
Für überdurchschnittliche Loks haben wir zum Glück Virtual Railroads und (mit unterschiedlichen Schwerpunkten) ein paar wenige andere Anbieter.
Für überdurchschnittliche Strecken? .... Prelli hat zur Selbsthilfe gegriffen. RLB bringt (vermutlich) auch was hochwertiges. Aber das zeigt auch schon das "Problem": überdurchschnittliche Strecken kommen nicht von kommerziellen Streckenbauern, die solche Strecken im Monatsrhythmus raushauen, sondern von Idealisten und Hobby-Streckenbauern, die dafür Jahre brauchen.
Für TS-Benutzer, die Strecken "verbrauchen" (installieren, mitgelieferte Szenarien und QD einmal rauf- und einmal runterfahren, abhaken), wird es also nie gute Strecken in ausreichender Anzahl geben. DIe, die zu einer intensiveren Beschäftigung mit den Möglichkeiten des TS (einschließlich Szenario-Bau) bereit sind, haben in der Hinsicht bessere Chancen. Vielversprechende Anfänge existieren bereits, einige weitere sind am Horizont erkennbar. Im Hinblick auf den Aufwand, den Streckenbau bedeutet, ist es angesichts des Alters des TS das was man erwarten kann. Nicht mehr, aber auch nicht viel weniger.

geht besser wenn man vorher mal die '8' drückt

"seit wann fahren .."? müsste die Frage nicht eher lauten "bis wann fuhren .." ?

Jemand, der Strecken baut, wird - denke ich - sowieso die Vollversion nehmen. Die Bedeutung der Free-Version ist ja vor allem, dass potentielle Benutzer von Strecken, die mit diesen Gleisen gebaut wurden, die Strecken überhaupt benutzen können, ohne von vornherein noch was bezahlen zu müssen bzw. einen Paypal Account haben zu müssen.
Und dafür ist diese Einschränkung durchaus ok.

Zitat von Supergamer11267

Ist doch auch nur MSTS-Konvertierung

nicht wirklich. Die haben zunächst mal ihr (eigenes) 3D-Modell. Das hat zunächst (fast) nichts mit MSTS. PTP oder RW zu tun.
Für den MSTS muss man dann zusätzlich noch einiges machen, um so ein 3D Modell im MSTS fahrtüchtig zu bekommen.
Für RW muss man zusätzlich was anderes machen, um das 3D Modell in RW fahrtüchtig zu bekommen.

Bei "toten" Objekten ist dieser Zusatzaufwand zwar wesentlich geringer, aber auch hier braucht man das originale 3D-Modell.

also nicht:
3D-Modell --(anpassung)-----> MSTS ------ (konvertierung) ---> RW

sondern:
3D-Modell ----(anpassung) ----> MSTS
selbes 3D-Modell --- (anpassung) ----> RW

mal ganz unabhängig von der Objektkonvertierung:
Eine Strecke dieser Größe, noch dazu mit Bahnhöfen wie Frankfurt, ist eine riesige Aufgabe, das legt auch ein erfahrener Railworks-Streckenbauer nicht mal eben in einem halben Jahr hin.
Aber wie heißt es so schön: Versuch macht kluch

Zitat von Fw.Meier

Das hätte ich mir mal erlauben sollen

hmm ... ja, und was sieht man da (außer dem, was man als Laie, der ich bin, sieht)?

ja, nur ein kleiner Bereich, den man in Uffing vom Gleis aus sieht, hat Wasser. Vom Gleis aus sieht man den ja sonst auch nicht.
Ich vermute fast, die RSC-Mitarbeiter haben Anweisung, nur das zu bauen, was man von Cab/Passview aus sieht.

@Zockerstube
vR_Addon# sind die Steam Varianten, die direkt von vR landen alle im VirtualRailroads Ordner

Die einzige Ausnahme ist der ICE1, der kam schon raus bevor Steam vR auf die Finger geklopft hat, dass sie nicht für beide Varianten dieselben Verzeichnisse benutzen dürfen.

Zitat von Zockerstube

aus der TS2012 Edition die 143 ( aber steam version- laut vR support identisch,

nur der Vollständigkeit halber:
das ist ein "funktionale" Aussage, soll heißen: die Funktionen der beiden sind identisch. Es sind aber aus TS-Sicht unterschiedliche Loks, d.h. Szenarien für die eine funktionieren nicht mit der anderen, es sei denn man tauscht mit RW-Tools.