Beiträge von Cirno

Hab ich als edit schon drüber gepackt. Letzten Endes reicht der Sweet.fx eintrag zumindest mir aus. Dieser reagiert auch auf die Änderungen der SweetFX_settings.txt und ist somit mmn auch die wichtigere.

Zitat von SÜWEX

Gibt es eine möglich den Kontrast zu reduzieren? Das ist mir mit dem Fix zu viel des guten und nicht mehr schön dezent wie vorher.

Tatsächlich nutzt es die selben Settings wie im alten Patch, ich habe nur syntaxfehler bezüglich der neuen ReShade Version gefixt. Ich kann aber mal schauen, sieht für mich nach zu heftigem HDR aus. Ich schau mal, ob ich was dran verbessern kann.

EDIT: Versuch mal in Zeile 293 der SweetFX_settings.txt (In Railworks/SweetFX) mit dem Wert zu spielen:
#define Gamma 1.100 //[0.000 to 2.000]

Nebenbei immer wieder mit Shift+F3 den Shader neu laden.
Der Eintrag in Zeile 308 könnte auch interessant sein, der steuert die Sättigung. Damit kann man auch den shader dezenter gestalten.

Zitat von dengstdu

Hallo @Rin Satsuki muss ich nach dem Starten oben wie in Deinem letzten Bild im 1. Post alle 4 Einträge haben, oder reicht nur 1 mal SweetFx und 1 mal Depth jeweils?

@SÜWEX Klar ist das möglich. Einfach alles nach beliegen in der entsprechenden Datei anpassen. Steht glaube sogar in der Datei für was welcher Wert da ist.

Die beiden SweetFX Einträge machen für mich den eindruck, als würden sie das selbe tun. Ich hab nur einen aktiv (den Sweet.FX), da sonst der effekt zu stark ist.

Da hat wohl wer durch 0 geteilt

Diese Datei ist nur eine Programmbibliothek. Kann man sich vorstellen wie ein Vermittler. Damit der Vermittler aber arbeiten kann, muss das Programm diesen richtig ansprechen. Dafür muss z.B. TSConductor noch nen Update raushauen.

Hab den Fix als Zitat mal mit in den OP genommen, damit andere es besser finden.

Das ist der Fehler, den ich noch nicht gefixt hatte, da er bei mir nicht aufgetreten ist. Tatsächlich ist es nur eine fehlende Zeile in der Main.h

#if (USE_LIFTGAMMAGAIN == 1)
  #include "SweetFX\Shaders\LiftGammaGain.h"
  #undef USE_SHARED //Diese Zeile hat gefehlt
  #define USE_SHARED 1
#endif

Update mit v3 der .rar kommt in 2 Minuten, muss noch durch Virustotal.

Zitat von Gustloff

Ob es für diese alte Hardware jemals einen passenden x64 Treiber geben wird, wage ich zu bezweifeln.

Gibts schon. /plugins/Raildriver64.dll. Muss nur reingepatcht werden.

Da hat irgendwas dann nicht funktioniert. Schick mir mal die d3d9.log aus dem RailWorks Stammverzeichnis als PN.

Wenn ein Fehler so dargestellt wird, bricht das laden des Shaders automatisch ab. Heißt momentan sind die Shader bei dir inaktiv.

_____________
EDIT:
Fehler war meinerseits, rar war in falscher Ordnerstruktur gepackt. Bitte die neue ReShade 64-bit Update v2.rar runterladen und nochmal den inhalt in den Railworks Ordner schieben.

Zitat von HappyNiki

Aye aye aye. Das erste Mal den TS 19 in 64 Bit gestartet und dachte: hey, ich stelle mir eben einen neuen Zug zusammen und fahr mal QuickDrive. Tja.... schon den ersten Systemfehler gefunden?
Als ich in den Zugeditor wollte, schmiss er mir beim Laden meines Rollmaterials das Ding hier raus:

Das schaut vielversprechend aus.

Einmal das hier machen https://www.chip.de/downloads/msvcp100.dll_143095150.html
Dir fehlt ne benötigte Programmbibliothek.

ReShade Ketchup gibts hier ReShade / SweetFX 64bit tauglich machen
Dies ist noch nicht ausgiebig getestet und mal schnell gepatcht, bei fehlerhaften Darstellungen bitte nicht bös sein.

UPDATE: SweetFX wird entfernt, ReShade betreibt nun alles Standalone. Bitte folgenden Post beachten: ReShade 64bit tauglich machen, Beitrag 104

Hab ReShade/SweetFX wieder ans laufen bekommen. Lag an einer veralteten Shaderconfig und einer 32bit variante der d3d9.dll. Soll ich nen Update hier hochladen für die 64 bit?

Zitat von Mittelschwabenbahn

@Der Aristokrat Macht aber Spaß!

Und pusht die Beitragszahl ( ͡° ͜ʖ ͡°)

1. Steam neustarten und eventuell fehlende Updates nachladen
2. Steamüberprüfung
3. Nochmal Steam neustarten
4. ???
5. Profit

Heute als Ersatz für nen Dosto einen IC Park mit 3 Wagen im 101er Sandwitch zusammen gebaut. Da ist dann wirklich nur noch fliegen schöner, aber Beinfreiheit wird wohl bei der komprimierung von 5 Dosto auf 3 IC Wagen die selbe sein . Wer das spektakel live sehen möchte, 2443 Köln-Dresden.

Hab inzwischen einen Workaround gefunden. Logmate nebenbei laufen lassen und jedesmal, wenn die laggs einsetzen, den Log clearen (ohne Logmate kommen die Lags auch und man kann sie nicht loswerden). Sobald ich dann den Wagenpark in Immendingen angehängt hab, tritt der Fehler nicht mehr auf und man kann das Szenario ohne Probleme beenden, sogar mit aktiven scripts bei < 3.1GB virtual / < 2.8GB Physischem RAM. Wirklich eine Begründung FÜR den Fehler bzw. woher er stammt und wie man ihn vorbeugt, weis ich leider weiterhin nicht. Ich gehe davon aus, das der Dispatcher die ganze Zeit davon ausgeht, das die Wagen, die "an den Zug gehören", von Anfang an am Zug sein sollen, aber halt nicht sind.

So. Habs jetzt mal ohne Szenarioscript und nur mit KI-optimierten Rollmaterial gestartet. Der Fehler tritt sofort mit Szenariobegin auf (mittlerweile immer). Screenshot mit Logmate und Process Hacker anbei. Virtual RAM mit eingeblendet.

Ich nutze zum anzeigen der RAM-Auslastung den ProcessHacker mit anzeige des virtuell adressierten Speichers, nicht nur dem physischem RAM.

Ihr stellt euch die Wetterwechsel zu krass vor. Es sind nur kleinere Änderungen wie die draw distance vom Nebel oder Niederschlagsintensität. Der Scriptteil, der das Gleiten simulieren soll, ist komplett entfernt und weiterhin bleibt der Fehler. Ist mittlerweile sogar einmal 10s nach Szenariobeginn aufgetreten, obwohl die RAM Last dort noch bei <3GB war.

Werd ich heute abend mal so versuchen. Ich gehe zwar weniger davon aus, das es der RAM ist, da der Dump ja erst bei 4GB VirtualRAM kommt (bzw 3,98x Gb bei mir), aber es ist immerhin TS.

Hab wegen der Ramauslastung bereits die Detailstufe heruntergesetzt, der Fehler tritt mal bei 3.1 GB, mal bei 3.4 GB auf, immer unterschiedlich. Dabei meine ich den virtuell addressierten Arbeitsspeicherbereich. Der physische RAM bewegt sich bei 2.8-3.1 Gb. Einen Dump wegen "vollem" RAM hatte ich seit umstellen der detailstufe nicht mehr, sonst kratz ich zu nah an den 4GB Virtual RAM.
Wenn ich im Editor die "Vorschau" nutze, läuft übrigens alles normal ab.

Die Weatheraktionen aktivieren Scriptevents bezüglich Wetter und Bremsverhalten (simulierter Radschlupf). Allerdings triggert der fehler zufällig und nicht in Verbund mit den Scriptevents.
Das neue Wetter braucht im übrigen kaum RAM, da es nur ein ExtendedWeatherBlueprint ist und somit nur das Streckenwetter beeinflusst, aber nicht ersetzt. Die einzige hinzugefügte Textur ist eine Schneeflocke mit wenigen kb größe.