TSW Farbeinstellung für Farbenblinde?

  • Moin liebe Community,


    sagt mal weiß jemand, ob und wenn ja, wie man vielleicht die Farben für die Lichtsignale anpassen kann?
    Vielleicht irgendwelche Dateien editieren, die diese Farbcodes oder so etwas enthalten?


    Hintergrund meiner Frage:
    Aufgrund meiner Rot-Grün Schwäche fällt es leider immer noch sehr schwer an Lichtsignalen im TSW das gelbe und grüne Lichtbild farblich auseinanderzuhalten.
    An Hauptsignalen geht's noch einigermaßen, da es ja nur ein rotes oder grünes gibt. Das kann ich locker unterscheiden, aber beispielsweise beim Vorsignal ist es dann vorbei.
    Ich behelfe mich zur Zeit damit das ich einfach pauschal PZW Wachsam drücke. :ugly:
    Allerdings gerate ich oft genug in eine Zwangsbremsung, weil ich erst durch die PZB erfahre, ob ich bremsen muss da ich von weiter Entfernung die Farben halt nicht unterscheiden kann. *ohman*
    Das ist in TS besser mit den Farben.


    Ich werde wohl auch nochmal Dovetail anschreiben, ob so eine Farbblindheit-Einstellung als Feature in einem Update eingefügt werden könnte. ;(
    Vielleicht ist ja hier jemand, der das Leid mit mir teilt und schon eine Lösung parat hat. *kaffee*

  • Es gibt die möglichkeit die engine.ini zu bearbeiten


    r.Color.Max
    Erlaubt zu definieren, wo der Wert 1.0 in den Farbkanälen nach der Farbabstufung zugeordnet wird.
    Der Wert sollte um 1 liegen, kleinere Werte verdunkeln die Hervorhebungen, größere Werte verschieben mehr Farben in Richtung Weiß, Standard: 1



    r.Color.Mid
    Hier können Sie festlegen, wo der Wert 0,5 in den Farbkanälen nach der Farbabstufung zugeordnet werden soll. (Dies ähnelt einer Gammakorrektur).
    Der Wert sollte um 0,5 liegen, kleinere Werte verdunkeln die Mitteltöne, größere Werte erhellen die Mitteltöne, Standard: 0,5



    r.Color.Min
    Erlaubt zu definieren, wo der Wert 0 in den Farbkanälen nach der Farbabstufung zugeordnet wird.
    Der Wert sollte um 0 liegen, positiv: Den Dunkelwerten wird eine Grauskala hinzugefügt, negativ: Weitere Dunkelwerte werden schwarz, Standardeinstellung: 0


    die Erklärungen zu den Werten habe ich mir durch Google-Übersetzer übersetzen lassen.


    Quelle: https://digilander.libero.it/ZioYuri78/


    wie man die engine.ini bearbeitet gibt es hier: TSW engine.ini parameter

    Einmal editiert, zuletzt von Hans Dampf ()

  • Ja und bitte Vorsicht mit den Werten, denn die wirken sich auf alle Materialien aus und nicht nur auf Signale. Einzige Möglichkeit zur Zeit ist, die Texturen zu suchen und zu bearbeiten. Eventuell wird das Glowing über einen Kanal gesteuert und ließe sich so ausschalten. Auch kann man dann die Farben noch etwas mehr differenzieren. Das Glow allein wegzumachen reicht aber glaube ich aus. Mich stört das auch, weil ich kaum erkennen kann ob das nun Gelb oder Grün sein soll. Es ist einfach nur total überstrahlt bis etwa 10m vor dem Signal, dann erkennt man es einwandfrei.

  • zum Glowing hab ich folgendes gefunden ...


    r.Cache.DrawLightingSamples
    Gibt an, ob von Lightmass erzeugte Probenpunkte für indirekte Beleuchtung gezeichnet werden.
    0 ist aus (Standard), 1 ist ein



    r.Cache.LightingCacheDimension
    Abmessungen des Beleuchtungscaches. Dies sollte ein Vielfaches von r.LightingCacheMovableObjectAllocationSize sein, um möglichst wenig zu verschwenden.


    r.Cache.LightingCacheMovableObjectAllocationSize
    Auflösung des Interpolations-Probevolumens, das zum Beleuchten eines dynamischen Objekts verwendet wird.
    Werte von 1 oder 2 führen zu einer einzelnen Interpolationsabtastung pro Objekt, die bei Bewegung keine kontinuierliche Beleuchtung liefert, sodass die Interpolation im Laufe der Zeit erfolgt.
    Werte von 3 oder mehr unterstützen die notwendige Polsterung, um unter Bewegung kontinuierliche Ergebnisse zu erzielen.


    so Vorsichtig muss man nicht sein .... geht was nicht ... einfach aus der engine.ini wieder löschen. Nur eben eins nach dem anderen, sonst weiß man nicht welches nicht funktioniert.

  • zum Glowing hab ich folgendes gefunden ...

    Das hat ja mal nun überhaupt nichts damit zu tun. Das ist was ich meine. Die Leute lesen sich irgendwas zusammen und verstehen aber gar nicht, was es wirklich tut. Soweit ich das jetzt sehen konnte, wird das Glow über Emissive mit ScalarParam gesteuert. Da können wir gar nichts dran ändern. Das ist quasi programmiert.

  • Das hat ja mal nun überhaupt nichts damit zu tun. Das ist was ich meine. Die Leute lesen sich irgendwas zusammen und verstehen aber gar nicht, was es wirklich tut. Soweit ich das jetzt sehen konnte, wird das Glow über Emissive mit ScalarParam gesteuert. Da können wir gar nichts dran ändern. Das ist quasi programmiert.

    ach .... 2 Kommentare darüber sagt Du noch "ja aber Vorsicht mit den Werten" und nun stellst Du mich als Deppen hin ?


    Dann gibt doch bitte mal r.AllowStaticLighting=0 in die engine.ini ein und Fahr mal des Nachts. Kein überstrahlen in den Untergrund-Bahnhöfen mehr. Auch Tagsüber merkt man einen deutlichen Unterschied. Leider hab ich das überstrahlen der Signale noch nicht entfernen können. Aber kommt Zeit ... kommt Rat.


    meine ini-einträge wie folgt



    [SystemSettings]
    r.EyeAdaptionQuality=0
    r.MaterialQualityLevel=0
    r.ViewDistanceScale=3
    r.MotionBlurQuality=0
    r.BloomQuality=0
    r.MaxAnisotropy=16
    foliage.LODDistanceScale=3
    r.AllowStaticLighting=0

  • Zwei hätt ich noch.. ;)


    r.Fog=0
    r.SkeletalMeshLODBias=-2

    mit r.SkeletalMeshLODBias=-2 hatb ich starke FPS-Einbußen und fog find ich selber nicht schlecht. Liegt wohl daran das ich von der Küste komme. :P Schade das Du deine Profil gespeert hast. Würde gerne mal deine Hardwareinformationen sehen, falls Du die technischen Details beschrieben hast.

  • ach .... 2 Kommentare darüber sagt Du noch "ja aber Vorsicht mit den Werten" und nun stellst Du mich als Deppen hin ?

    Hab ja nicht gesagt, dass die Werte für den gesuchten Effekt richtig wären. Hab nur gesagt, dass diese Werte mit Vorsicht angewendet werden sollten, da sie sich auf alles auswirken. Hat ein bissel was davon als wenn man, statt mit der Fliegenklatsche das kleine surrende Ungetier zu entfernen, einfach Giftgas in die ganze Hütte bläst. So unter dem Motto: "Scheiss drauf was noch alles drauf geht, die Fliege wird es schon erwischen". Das gleiche gilt für r.AllowStaticLighting. Das schaltet halt mal eben alle statischen Lichter ab, was absoluter Nonsens ist. Genauso wie r.SkeletalLODBias auf -2 zu stellen, was alle LODs der Objekte mit Skeleton-Meshes (Loks, Wagen, Personen, Autos) die LOD Fähigkeiten quasi wegnimmt und natürlich zu massiven Performanceproblemen führen muss. LOD ist ja nicht zum Spass da. Gilt auch für foliage.LODDistanceScale auf 3. Verschiebt alle LOD0->LOD1 Umschaltentfernungen um Faktor 3 nach hinten und sorgt ebefalls für erhebliche Performanceeinbrüche, wenn man nicht grad die fetteste Grafikkarte im Rechner hat. ViewDistanceScale hat ähnliche Effekte, aber nur auf Objekte die überhaupt eine solche Einstellung haben, was wenige sein dürften im TSW.


    Bitte echt nochmal jeden einzelnen Parameter nachgoogeln und versuchen zu verstehen, was er eigentlich wirklich tut. Diese wilden Einstellungen führen nur dazu, dass irgendwann alles schlecht läuft. Die Optimierungen in diesem Spiel haben wirklich nicht auf User-Seite stattzufinden, sondern beim Entwickler.

  • Gerade DTG gehen unsere Probleme doch am Arsch vorbei. Hauptsache weitere Addons entwickeln, anstatt das Game zu Optimieren. Gerade Leute mit Farbenblindheit habens in Spielen oft nicht leicht, obwohl es heute möglich ist diesen zu helfen. Siehe Bad Company 2, League of Legens usw. Einen Modus für Farbenblinde zu impletieren ist heute keine große Sache mehr.


    Desweiteren mache ich keine wilden Einstellungen sondern klappere alle nach und nach ab. Auch habe ich unter jeden Parameter die dazu gehörigen Anmerkungen geschrieben. Sollte mal wirklich alles Schief gehen, gibt es immer noch die Möglichkeit, die engine.ini komplett zu löschen. Beim nächsten Start von TSW wird eine neue ini angelegt. Sollte all meine Mühe umsonst gewesen sein .... kein Ding ... dann sag ich mir ... ich habs eben Versucht.

  • Verstehe Dich da gut "Namensvetter". Was Du auf Deiner Platte machst geht keinen was an, ich verstehe zwar den Maik grundsätzlich schon, weil die Entwickler -so scheint mir- derzeit eher selber noch in einer Findungsphase zum TSW sind und das beste Gesamtpaket für alle finden wollen, aber probieren geht über studieren. Dass man sich Backups -vielleicht sogar nach jedem Schritt- machen sollte versteht sich von selbst. Wenn die Leute nur noch alles fressen was sie vorgesetzt bekommen, dann gute Nacht und das gilt nicht nur für die Simulation. Jedes Schräubchen an dem man herumdreht und was die Sache für einen besser macht ist ein Erfolgserlebnis und oft der Lohn für fleissiges Arbeit damit (sind ja nicht nur die Entwickler die sich Stund um Stund damit um die Ohren hauen). Dagegen interssiert mich das Erreichen eines Spiellevels oder die Erfüllung eines Szenarios ehrlich gesagt herzlich wenig.

  • Gerade DTG gehen unsere Probleme doch am Arsch vorbei. Hauptsache weitere Addons entwickeln, anstatt das Game zu Optimieren. Gerade Leute mit Farbenblindheit habens in Spielen oft nicht leicht, obwohl es heute möglich ist diesen zu helfen. Siehe Bad Company 2, League of Legens usw. Einen Modus für Farbenblinde zu impletieren ist heute keine große Sache mehr.

    Ganz sicher nicht, nur ist das kein Team von 2000 Mann wie vll. bei deinen genannten AAA Games. AddOns sichern nun mal die Zukunft des TSW. Ohne diese gäbe es keinen TSW. Von nüscht kommt halt auch nüscht.


    Und die Implementation von Bedienhilfen (Barrierefreiheit) ist alles andere als trivial. Allein die Unmengen an Farbschwächen die es gibt, die kann man nicht mal eben so abbilden/abhandeln. Sowas kann sich eine Firma wie DTG gar nicht leisten und andere Entwickler für den TSW schon gar nicht. Klar könnte man die Sichtbarkeit der Signale etwas optimieren, aber nicht barrierefrei gestalten. Der Modus für Farbenblinde wäre dann statt Farben mit Ziffern zu arbeiten :) Statt gelb-gelb zu sehen als Farbe, stünde dann "gelb-gelb" als Text drauf :D Auch ne Lösung, ehrlich gesagt.


    also ganz ehrlich ich habe foliage.LODDistanceScale auf 4 und r.SkeletalLODBias auf -2 stehen und ich spiele in 3440x1440 mit 60fps. Also ich merk da nichts von "erheblichen performanceeinbrüchen."

    Richtig, wir mit unseren dicken Grafikschleudern merken davon (erst mal) nichts. Ich hab mal mit Stat geprüft was da passiert. Und ja, da passiert gewaltig was. Nur 2 Züge mit 146 und 5 Dostos fluppen von ~2Mio SkelMeshTris auf über 8Mio SkelMeshTris. Die Draws steigen nur minimal, was klar ist, da sich die Materialien nicht ändern. Jetzt stell dir das mal mit 10 Zügen vor. Dann bricht auch bei unseren Karten alles zusammen. 20-40Mio Tris is ok, darüber wirds happig und zäh. Da wir nicht nur Züge rumstehen haben, sondern auch viele Personen rumlaufen, die auch Skeletons sind und nicht grad Polygon arm daherwandern, ist da ganz schnell Ende im Gelände.

  • zu Statement 7:


    r.Cache.DrawLightingSamples


    r.Cache.LightingCacheDimension


    r.Cache.LightingCacheMovableObjectAllocationSize


    haben keine Auswirkungen auf die Lichtverhälnisse oder Überstrahlungen oder wird nicht von TSW übernommen.


    zu: r.AllowStaticLighting=0


    Gibt an, ob statische Beleuchtung generiert und verwendet werden soll, z. B. Lightmaps und Shadowmaps.
    Bei Spielen, die nur dynamische Beleuchtung verwenden, sollte dies auf 0 gesetzt werden, um statische Beleuchtung zu sparen.



    Das hat große Auswirkung auf die Lichtverhälnisse. Gerade bei Nachtfahrten wird alles viel dunkler dargestellt, aber hat keine Auswirkung auf das Glühen der Signale. Einfach mal ausprobieren und bei nichtgefallen den Eintrag aus der ini wieder löschen.

  • BlueAngel

    Hat das Label TSW hinzugefügt.