Beiträge von nobsi

Discord Einladung
Trete unserem Discord-Server bei (klicke hier zum Beitreten).


    Als Drittanbieter würde ich mir jetzt überlegen, ob sich die neue Entwicklung von Strecken jetzt noch lohnt.


    wieso? ernsthafte Anbieter (und zumindest kommerzielle Anbieter sollten "ernsthaft" sein) bauen sauber (sollten sie zumindest, sowieso). Für sauber gebauten Content sehe ich gute Chancen für eine Migration. Davon abgesehen bleibt der "alte" TS ja erhalten (ist zumindest Absicht). Nur dieses chaotische kreuz- und quer gedönse, wie es in fast allen älteren Freeware-Projekten der Fall ist, wird auf dem neuen TS nicht funktionieren - aber weiterhin auf dem alten, so gut oder auch schlecht wie sowieso schon.
    Ich hab vor über einem Jahr schon gesagt, kein Grund für mich, mit dem Bauen aufzuhören, und da hat sich nichts dran geändert. Im Gegenteil.


    Zitat

    Mir persönlich wäre es lieber gewesen, wenn es noch für einge Jahre Updates des alten Programms gegeben hätte (TS2015, TS2016..),


    keine Bange .. einen TS2015 (der "alten" Art) gibt es sicher noch.

    für mich siehts ein klein wenig anders aus:
    - ob es LZB gibt, ist mir wurscht. Die schalt ich sowieso aus (bzw. nicht ein), weil es langweilig ist, nur Däumchendrehend vor dem Bildschirm zu sitzen (Realismus hin oder her - gewisse Aspekte der Realität, z.B. Verantwortung, kann man nunmal im TS nicht darstellen).
    - wenn es nur eine SFS ist, ist sie für mich uninteressant, weil für mich SFS nun mal uninteressant sind. Wenn#s auch noch was außer SFS gibt, sehn wir weiter ;)

    wie gesagt:
    alter Content -> alter TS
    neuer Content (aber auch alter "sauberer" Content) -> neuer TS


    Content mit Asset-Strukturen wie die RSItalia BR 146 / BR 185 wird es sicher nicht in den neuen TS schaffen.


    ---
    ist alles nur meine Meinung aus Software-Entwickler Sicht. Ich hab keine funktionierende Glaskugel.

    ... das man die Auswahl hat den alten TS zu behalten oder den neuen TS zu benutzen,


    nö, warum? "optionales Update" heißt nicht zwangsläufig "entweder - oder".
    Ich sehe nach wie vor das angepeilte Ziel darin, den alten TS so lange wie möglich weiter laufen zu lassen, um alten Content, der gewisse Anforderungen nicht erfüllt, nicht sofort abzuschießen. Parallel eine neue Generation zu starten, mit der Möglichkeit, einen Teil des alten Contents zu migrieren. Was der neue sicher nicht sein wird: eine 64bit-Lösung für die alten "Dickschiff"-Freeware-Strecken wie Northern Europe, Hamburg-Bremen, oder Ferrovia Italia Francia. Die werden höchstwahrscheinlich nicht migrierbar sein.


    Ich freue mich jedenfalls, dass das, was vor einem oder zwei Jahren reine Spekulation war (Thema "wo bleibt der 64bit-TS"), jetzt greifbarer wird.
    Bis jetzt sehe ich auch noch nichts, was meinen damaligen Spekulationen widerspricht. Allerdings habe ich, wenn ich so das Stichwort "Unreal Engine" sehe, einen Verdacht über eine zukünftige Ausrichtung des TS, die mir nicht so ganz gefällt - obwohl ich ja eher Landschaftsgucker als Eisenbahner bin ....

    Wie komme ich auf 32 bit?
    TS ist 32 bit und eben mal x86 Programme daraus zu machen würde ich jetzt nicht als trivial bezeichnen...


    ist es nicht, und das will man ja auch nicht. Sie wollen ja eben auf ne andere Engine gehen. Und es steht ja auch deutlich da, dass man ein "optionales Upgrade" anpeilt, d.h. der neue ersetzt nicht den alten, sondern soll parallel existieren (wie lange auch immer - maximal sicher solange 32bit auf Windows noch läuft). Und die ganze Content-Restrukturierung, die seit der Einführung des TS2013 läuft (getrennte Assets, Paketstruktur usw), haben sie ja nicht nur gemacht, um RWTools zu ärgern ;)

    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.

    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)

    hab ich im Seebergbahn-QD nicht vorgesehen, weil man im "mittleren" Bahnhof (Seeberg) die Richtung wechseln müsste. Das könnte man zwar auch im QD (auf der Seebergbahn sogar mit Umsetzen), hab ich aber damals rausgenommen, weil ich fürchtete, dass die meisten Nutzer da ohne Szenarioanweisungen etwas ratlos wären.

    das braucht gar nicht "behoben" werden. Ist ja nur die Info, dass du Assets außerhalb deines eigenen Asset-Ordners verwendest. Und die werden vom Blueprint Editor nicht exportiert - würde auch gar nicht gehen, da du ja die Source-Dateien der fremden Assets gar nicht hast.
    Anders ausgedrückt: der Blueprint Editor sorgt beim Erzeugen deiner Trackrules nicht dafür, dass auch die Holzländer-Gleise installiert werden.


    In der Strecke müssen halt die fremden Assets ebenfalls eingeschaltet werden (im Objektfilter), und alles ist gut.

    Tipp für diejenigen, die sich ein paar KI-Consists erstellen wollen (geht nur mit Blueprint-Editor oder RWTools):


    Berlin-Wittenberg Route-ID (muss in Valid Drive Routes eingetragen werden):
    f8b64803-ddb6-47bd-9ee8-69e3ceba1bf3


    In den in B-W mitgelieferten QD-Szenarien verwendete Consist Types:
    - passenger regional
    - freight wood
    - freight oil
    - freight paper (dieser kommt nur einmal vor)


    Im TTB Szenariopaket sind zwar viele Consists enthalten, die sind aber alle nicht als KI für Strecke markiert (was im Grunde auch gut ist, wär sonst ein heilloses KI-Durcheinander auf der Strecke).


    (btw. ich bin in M-Gap über ein Gebiet gestolpert, wo ich für DT unbedingt noch mehr Gelände importieren muss)


    Das war ein Irrtum.
    Da ist nicht zuwenig, sondern zuviel DEM-Gelände. In der Originalstrecke ist ein überflüssiger, 3 km breiter, ca. 25 km langer Streifen DEM enthalten, der über Geltendorf bis zum Lech geht. Ohne DT würde das nicht weiter auffallen, aber mit DT siehts dann so aus (Blick von Weilheim Richtung Norden).


    Ein treffendes Beispiel dafür, dass die Menge der DEM Terrainkacheln für die DT-Generierung möglichst "konvex" sein sollte.

    Ich habe mal nachgefragt, ob nach München verlängert wird.


    Wenn sie Ingolstadt-München irgendwann auf dem Plan haben, wird das sicher eine getrennte Strecke. Macht keinen SInn, so umfangreiche Abschnitte zusammen zu kleben. Das schafft nur a) Kompatibilitätsprobleme mit bereits existierenden SZenarien der ersten Ausbaustufe, und b) Supportprobleme, weil dann zwei drittel der Kunden das Monster nicht ans Laufen bekommen.


    apropos SFS:
    da kommen die Lärmschutzwände ja auch dem TS sehr zugute. Wenn man tatsächlich 300 fahren will, muss der TS ja im ungünstigsten Fall alle 12 Sekunden 8 Kacheln laden. Bei einer "schönen" (detailreich gestalteten) Strecke klappt das einfach nicht mehr, da hilft auch eine SSD nicht.


    Dann habe ich die div. Erweiterungen die sich im Laufe der Zeit angesammelt haben installiert und da macht mir eins die Strecke an dieser Stelle kaputt.


    Es gab da verschiedene "PZB"-Patches. Mindestens eins davon war - vorsichtig ausgedrückt - problematisch. Vielleicht da mal genauer hingucken / Zwischensicherungen machen.

    ahso .. schwarzer Nebel ... (ja stimmt, auf einem deiner Bilder wars gut zu sehen)
    dann fehlt vermutlich eine der Fog Einstellungen in den ToD Dateien (bzw. steht auf 0/0/0), oder es ist eine Wetterdatei mit einer solchen EInstellung benutzt (da sind ja auch Fog-Einstellungen, die die aus den ToD übersteuern können)

    Ja, genau das ist mir auch noch schleierhaft.


    "Offiziell" wird anstelle der normalen Terrain-Texturen die "DistantTerrainColor" aus dem Terrain Texture Blueprint benutzt, sobald der kleinste Mip-Level der Texturen erreicht ist. Das ist normalerweise (ohne DT) bei etwa 1,5 km Entfernung der Fall (das Ganze kann dann noch durch die Fog-Einstellungen in den ToD- bzw Wetter-Dateien verschleiert werden). Die DT-Generierung erzeugt neben dem eigentlichen DT auch Texturen mit "kleinerem" Mip-Level (im Verzeichnis terrain/textures). Wenn die vorhanden sind, sollte der TS eigentlich automatisch anstelle der DistantTerrainColor aus dem Terrain Texture Blueprint die DT-Texturen anzeigen.


    Aber irgendwie scheint das nicht immer zu funktionieren. Ich zitier mich mal selbst:

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


    Das 3CCR-DT habe ich in meiner "TS-Entwicklungs-Installation" erzeugt, und dann in die TS-Hauptinstallation kopiert. In der Entwicklungsversion zeigt der TS immer noch die DistantTerrainColor an, in der Hauptinstallation aber die DT-Texturen. Warum? Bei M-GaP zeigt der TS bei mir in beiden Versionen die DistantTerrainColor (anstelle der DT-Texturen) an. Warum? Immerhin weiß ich von einigen Benutzern und Screenshots hier im Forum, dass da auf verschiedenen anderen Systemen durchaus die DT-Texturen angezeigt werden.


    Leider habe ich den entscheidenden Knopf im TS, mit dem man sicher umschalten kann, noch nicht gefunden.
    (Hinweise, die zur Ergreifung des Täters führen, sind willkommen)


    (btw. ich bin in M-Gap über ein Gebiet gestolpert, wo ich für DT unbedingt noch mehr Gelände importieren muss)