Distant Terrain im TS ab TS2014

  • Servus


    Weiß jemand wo ich die cfg finde von TS2014, um die Graphik einstellungen manuell zu ändern ggf. zu verbessern ?



    mfg

  • Da gibts keine cfg. ausser den globalen Hauptseite Einstellungen.
    Was hier diskuiert wird, ist die Abhängigkeit der Eintragungen in den TOD- Dateien in den Properties der Strecken und den Wetterdefinitionen und -Einstellungen in den Szenarien, sowie wie die Geländetexturen darauf reagieren.
    Da musst Du Dich schon tief in die Dateien des TS reingraben.
    StS

    Keine Hilfe und Auskunft per PN, da meist von allgemeinem Interesse. Diese Fragen bitte im Forum stellen.

  • Einige Einstellungen des TS kann man in der datei "Content/PlayerProfiles.bin" ändern. Diese muss man mittels SERZ zu einer XML mache, kann diese dann editieren und mit SERZ wieder zurück zu einer BIN machen.


    Ich möchte aber davor warnen, darin manuell rumzumurksen, denn 1. kann man die wichtigsten Sachen auch direkt im TS selbst machen und 2. wird eine vermurkste PlayerProfiles den TS hindern, zu starten. Also bitte ein Backup machen.



    Edit:

    Die Aufgaben greifen wohl auf das streckeneigene Wetter zurück, welches ich ebenfalls angepasst habe. Aber das (von Spooner überarbeitete) QuickDrive nutzt wieder irgendein anderes Wetter, weil da noch alles beim alten ist.

    Falls du QucikDrive-Aufgaben meinst, die greifen eigentlich immer auf die Wetterdateien in "Kuju/RailSimulatorCore/Weather" zurück, egal welche Strecke das ist und egal wer das Quickdrive gemacht hat.
    Sollte Spooner es wirklich geschafft haben, seinem Quickdrive ein anderes Wetter unterzujubeln, wüsste ich gerne, wie er das gemacht hat. Ich habe mir bisher nämlich auch nur helfen können, indem ich die Wetterdateien in "Kuju/RailSimulatorCore/Weather" nach meinen Bedürfnissen anpasste.
    So habe ich beispielsweise "Regen", was ja normalerweise monotonen Dauerregen macht, in Regenschauern mit Sonne zwischendurch geändert.


    Schönes Bild, übrigens. Gefällt mir!

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

    2 Mal editiert, zuletzt von Prelli ()

  • Und genau dann wird es eben komisch, Prelli. Ich denke ja auch, dass Railworks wohl die Wetterdateien von dem Pfad "Assets\Kuju\RailSimulatorCore\Weather" nutzt. Im Freien Spiel tut es das jedenfalls, da entstand das Bild gestern bei bewölktem Himmel. Nehme ich die Einstellung im QuickDrive, dann habe ich aber nicht das geänderte Wetter, sondern wieder die schwarzen Berge am Sommerabend. Nur bei der Einstellung klar ist es so wie auf dem Bild gestern. Es hat also definitiv mit den Fog-Einstellungen im Wetter zu tun, Time of day kann ich da ändern wie ich will, es bleibt gleich. Nur warum werden für das QuickDrive anscheinend irgendwelche anderen Werte genommen?


    Öffne ich so eine QD Northbound (in diesem Fall, es geht ja Richtung München, also Norden), dann steht da in der .xml das Wetter unter dem Pfad "Assets\Kuju\RailSimulatorCore\Weather\RW_Clear" eingetragen. Also der gleiche Pfad, der auch für den "Freies-Spiel-Modus" verwendet wird. Nur ist im Freien Spiel der Nebel weg, und im QD ist er da. Cache ist auch geleert - also bleibt für mich nur noch die Vermutung, dass das QuickDrive doch noch auf andere Einstellungen zurückgreift. :(

  • "Freies Spiel" ist eine andere Baustelle, da kann man ja als Wetter eintragen, was man will, wie bei einem Standardszenario auch.
    Der Eintrag im QD hingegen dürfte nur ein Dummy oder auch Blindeintrag sein, denn das QD wird ja erst beim Start in Abhängigkeit der eingestellten Parameter mit Zugverbänden, Jahreszeit, Tageszeit und eben auch Wetter gefüttert.


    Wie gesagt... das sind meine bisherigen Erfahrungen dazu, und wenn jemand weiß, wie man einem QD andere Wetterdaten unterjubelen kann, OHNE die Kuju-RailSimulatorCore-Wetterdateien selbst abzuändern, der möge bitte laut "Hier!" brüllen :)

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

  • Die Core-Dateien habe ich ja eben abgeändert. :D Zumindest RW_Clean, RW_Cloudy und RW_Overcast (also ohne Rain, Snow etc.). Und Hazy hab ich auch testweise geändert. Diese Änderungen greifen in Aufgaben und im Freien Spiel, nicht aber im QuickDrive. Und wenn das angeblich die selben Dateien verwendet, dann weiß ich da nicht weiter. :)

  • Der Effekt kommt aus einem TOD und das ist im QD nicht das der Strecke, egal welches Wetter man benutzt. Ich nehme an dass es das aus dem RailSimulatorCore/TimeOfDay/ ist dass da Verwendung findet. Wetter ist nur für Wolkendarstellung, Tageszeitfestlegung und Niederschlag zuständig. Die Evirementdarstellung kommt aus dem TOD dass für die Session eingestellt ist. Das sind 2 Baustellen die man da angehen muss.

  • Warum habe ich dann im QuickDrive den selben Himmel, wie im Freien Spiel und wenn ich ein Scenario spiele? Das kann nicht sein. TimeofDay wird meines Erachtens also wirklich aus Assets/RSC/MunichGarmisch verwendet. Aber nochmal: Ich kann da bei ToD einfügen, was ich will: Original Kuju, AP, 3CCR, Berlin-Wittenberg oder sonst etwas. Der Himmel wird geändert, der blöde blau-schwarze Dunst bleibt erhalten.


    Gehe ich in die Wetter .bin (unter Kuju/RSCore) dann sieht man da zahlreiche Einträge, was den Fog betrifft. Habe die Werte von Clean also genommen und alle Nebeleinstellungen damit überschrieben. Da gibt es auch einen Eintrag mit "Overwrite" , also dass das Wetter die ToD anscheinend überschreiben sollen. Das kann auf eTrue oder eFalse stehen. Ich habe es auf eTrue gestellt und schon ist der Nebel da weg, weil auch bei bewölktem oder bedecktem Wetter die Einstellungen vom klaren Wetter verwendet werden, also dann ist der Nebel weg. Hier ein Beispiel, unter dem der Nebel weg ist:


    <FogOverride d:type="cDeltaString">eTrue</FogOverride>
    <FogColour>
    <cHcColour>
    <Red d:type="sFloat32" d:alt_encoding="000000409493E33F" d:precision="string">0.611765</Red>
    <Green d:type="sFloat32" d:alt_encoding="00000020D4D3E33F" d:precision="string">0.619608</Green>
    <Blue d:type="sFloat32" d:alt_encoding="000000405453E33F" d:precision="string">0.603922</Blue>
    <Alpha d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</Alpha>
    </cHcColour>
    </FogColour>
    <FogStart d:type="sFloat32" d:alt_encoding="000000000000F03F" d:precision="string">1</FogStart>
    <FogEnd d:type="sFloat32" d:alt_encoding="000000000094C140" d:precision="string">9000</FogEnd>


    Folglich ist es für mich zumindest nur denkbar, dass es an einer Wetter.bin liegt, die im QuickDrive genutzt wird, die ich aber noch nicht bearbeitet habe, weil ich anscheinend nicht die richtige finde. Ich nutze ja das Pack von AP, das ja dafür bekannt ist, die ToD zu "verbessern" und da ist als Merkmal auch beschrieben, dass bei klarem Wetter eben dieser Dunst verschwindet. Und ich habe auch lieber nackige Berge als so ne schwarze Wand da. Ich werde jetzt sämtliche .bin in dem Ordner mit der Fog-Einstellung ersetzen und dann schauen, was das doofe QD da hernimmt. :thumbup:


    Edit: Ich Dummerle. 18 Uhr zählt für das QuickDrive also bereits zu "Night" , na dann. Jetzt hab ich es jedenfalls. Die schuldigen .bin für den Nebel waren:


    - RW_Cloudy
    - RW_Overcast
    - RW_Night_Cloudy
    - RW_Night_Overcast


    Für mich steht eines fest: Nebelwerte in den ToD-Dateien werden also oft durch das eingestellte Wetter überschrieben. Es ist jedoch lächerlich, wenn ich die Berge nur dann optisch gut sehe, wenn ich bei klarem Wetter fahre. Bei bewölktem Wetter oder auch ganz bedeckt ist in RW dieser Dunst vorprogrammiert. Das finde ich wirklich lächerlich. Denn das ist kein Grund, diesem Nebel so eine schwarze Farbe zu verpassen, denn auch bei bedecktem trockenem Wetter sehe ich die Berge am Horizont - und zwar nicht schwarz oder blau.


    Die einzige Frage also, die jetzt noch zu klären wäre ist die, warum manche anscheinend bereits solche umgeänderten Core-Dateien haben. Höchstwahrscheinlich bereits irgendwo mit heruntergeladen. Jetzt sehe ich jedenfalls die Berge und die schöne Arbeit von nobsi. Schwarze Berge ade. ;)

  • Der Effekt kommt aus einem TOD und das ist im QD nicht das der Strecke, egal welches Wetter man benutzt.

    Beim Quickdraive wird das ToD der Strecke benutzt. Alles andere wäre ja auch unsinnig, weil darin ja auch Sonnen- und Mondauf- und -untergangszeiten stehen, sowie der Azimut und ein paar andere Dinge, die nicht für jede Strecke gleich sind.


    Von daher kann ich die hier geschilderte Problematik noch nicht ganz nachvollziehen und verstehen, denn es wird meines Wissens bei einem Quickdrive immer das ToD der Strecke genommen und immer das Wetter aus Kuju/RailSimulatorCore.


    Deswegen habe ich auch auf München-Augsburg morgens um 6 einen kaffeebraunen Himmel und aufm Dreuselsee morgens um 6 einen schönen Sonnenaufgang, gleiches Wetter vorausgesetzt. Das wäre nicht so, wenn das QD immer dasselbe ToD bemühte.

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

  • müsste man eigentlich kontrollieren können, wenn man in das gespawnte QD guckt:
    - QD starten, abbrechen, TS beenden
    - im Szenario-Ordner der Strecke das neueste Szenario suchen, das sollte das aus dem QD gespawnte Standardszenario sein
    - in diesem Szenario in den SzenarioProperties das "generated" Flag (ziemlich am Ende der Datei) auf false setzen, damit das Szenario nicht beim nächsten TS-Start gelöscht wird; evtl den Szenarionamen sinnvoll ändern
    - ... (testen was man testen will)

  • Hallo zusammen,


    habe mit Erfolg die Änderung -nach der Anleitung von Markus- durchgeführt. Nun habe ich aber ein Problem im Winter. Die Berge bleiben in der Ferne weiterhin grün, sehr sehr realistisch für die Region dort muss ich sagen. :Ironie:


    Im Anhang findet ihr ein Bild aus Murnau, mit dem Blick auf die Berge bei Garmisch.


    Könnt ihr mir da bitte weiterhelfen?

  • Leonid:
    Mir scheint, dass für den Winter (noch) kein Distant Terrain angelegt wurde. kann das sein?

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

  • Winter-DT habe ich generiert (im Original gab es die auch schon) - das Problem liegt eine Stufe davor:
    die Texturierung der Strecke ist (wie auch bei der 3CCR) nicht wirklich DT-gerecht.


    Ich habe zwar damit angefangen, die Texturierung zu überarbeiten, aber das ist viel Arbeit.


    edit:
    hatte gerade unterwegs 2 Ideen:


    1. (für mich als DT-Ersteller): statt die gesamte Texturierung zu überarbeiten, könnte ich erst mal einfach im Texturset zusätzliche Wintertexturen eintragen, und damit generieren. Ist bei weitem weniger Arbeit.


    2. man könnte mal testen, was passiert, wenn man tatsächlich keine DT-Wintertextur erzeugt. Wenn der TS dann wieder auf die DT-Farbe zurückgreift, wäre das vielleicht besser als grüne/fleckige Berge. Zum Test mal die DT-Wintertexturen (*_Wi.TgPcDx) aus terrain/textures entfernen.


    edit 2:
    eigentlich sehen die Texturen im Nahbereich durchaus nach Winter aus, aber im DT-Bereich herrscht Chaos (siehe Screenshot, aus Originalstrecke)
    Allerdings sind die Gelände-Wintertexturen teilweise "dick verschneit", teilweise lassen sie die Bodenfarbe durchschimmern. Vielleicht kommt es bei letzteren beim Downsampling für die DT-Texturen zur Entartung der Wintertexturen. Die Benutzung anderer Wintertexturen für die DT-Generierung ist also auf jeden Fall einen Versuch wert.

  • Hallo nobsi,


    ich probiere mal die Variante 2 aus. Mal sehen, wie es aus der Ferne aussehen wird.


    Vielleicht kannst du ja mal an der Variante 1 arbeiten und irgendwann das Ergebnis hier schreiben.

    Viele Grüße aus Köln,
    Leonid

    ___________________________________________
    Wir haben eines gemeinsam, wir fahren Railworks.

  • Habe jetzt herausgefunden wieso bei mir immer die schwarzen Artefakte aufgetaucht sind. Bei meiner Strecke war der Route Origin (durch nachträgliche Änderung) nicht auf der Kachel +000000-000001 sondern auf -000001+000000. Auf einer neu erstellten Strecke mit dem importierten Gelände und MixMaps Dateien, funktioniert alles reibungslos.

    Ganz liebe Grüße an alle meine Fans im Forum!
    ------------------------------------------------------
    Quality-Pöbel since 2011

  • puuh .. gut dass das geklärt ist - hat die ewige Grübelei und Probiererei ein Ende.
    Danke für die Info.


    --


    @Leonid @Markus Schöbel auch die versuchsweise Neutexturierung hat damals nichts gebracht. Irgendwo hat der TS da was vergraben, was stört. Aber da ich auf der Strecke erhebliche Schwierigkeiten hatte, nachträglich die Lofts zu bearbeiten, hab ich von der Idee, mit wenig Aufwand eine "neuzeitliche" Variante von Murnau-Oberammergau anzuschließen, ohnehin Abstand genommen und mich wieder auf meine eigene Version konzentriert. Da klappt das auch mit dem DT.

  • Hallo @marxkevin1996,


    der Effekt entsteht, wenn man sich beim Erstellen des DT nicht exakt am Route Origin (Kachel-Koordinate 0,0) befindet.


    Versuche zunächst folgendes:
    Lege ein neues "Freie Fahrt" Szenario am Route Origin der Strecke an.
    Nach Laden des Szenarios nicht "bewegen", sondern nur DT-Generierung starten.


    Falls das wieder nicht hilft, ist vielleicht die der Route Origin der Strecke verschoben worden. Das wird manchmal gemacht, damit man beim Anlegen eines neuen Szenarios im Editor an einem "passenderen" Ort erscheint.
    In diesem Fall kannst du folgendes machen:
    - Klone die Strecke mit dem TS (nicht mit RWTools). Dabei werden wieder die Einstellungen der originalen Route Template übernommen.
    - erzeuge das DT in diesem Klon
    - das fertige DT (die "DistantPatches.bin" und den textures Ordner im Terrain Ordner) kannst du in die originale Strecke zurückkopieren.