Beiträge von Prelli

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

    Ich weiß nicht, ob hier richtig bin und ich weiß nicht, ob es dafür nicht zu spät ist, aber vielleicht kann man das in einem kommenden Update -so es denn nochmal eins geben sollte- beheben?



    Edit:
    Betatestern muss sowas auffallen, zumal das ein Streckenabschnitt ist, der verhältnismäßig oft befahren wird. Beim Bau kann sowas ohne Weiteres passiern, aber ihr als Betatester müsst bitte auf sowas achten!

    Zur Ergänzung noch die Info, dass eine Strecke mit LZB ausgerüstet sein muss. Man sollte also nicht glauben, man könne z.B. auf der Seebergbahn einfach eine LZB einschalten. Die muss auf der Strecke verbaut sein.
    Und wenn sie verbaut ist, ist es leider fraglich, ob sie korrekt funktioniert.


    Verbaut ist sie unter anderem auf Hamburg-Hannover, München-Augsburg und mit einer Erweiterung auch auf Berlin-Wittenberg.


    Ob da eine LZB verlegt wurde sollte man erkennen am Kabel auf den Schwellen mittig zwischen den Schienen.

    Benenn mal folgende Datei um und gib ihr irgendeinen anderen Namen:


    C:\Program Files (x86)\Steam\SteamApps\common\RailWorks\Content\PlayerProfiles.bin


    Das setzt alle Einstellungen von dir zurück auf die Werkseinstellungen.
    Danach sollte der TS wieder starten, aber du wirst alle deine Einstellungen neu machen müssen.
    Wenn du damit zufrieden bist kannst du die alte umbenannte PlayerProfiles-Datei löschen.

    Diese Meldung habe ich ebenfalls alle Nase lang beim Start (m)eines Quickdrives, weil der arme TS 30-40 Zugverbände auf die Strecke setzen muss. Je nachdem, welche Provider da durcheinander zufällig geladen werden, brauchen diese Zugverbände mehr als 2 GB an Ram.
    Vielleicht ist das hier ähnlich?


    Ein weiterer Absturzgrund könnte das Fehlen des Provider-Products "Kuju/RailSimulator" bei Fahrzeugen mit Kuju-Kupllung oder "RSItalia/common" bei der RSItalia BR146 und BR185 sein.
    Welches Rollmaterial hast du denn benutzt?

    Cotten Eye Joe:
    So genau wirst du die Stelle nicht festnageln können.
    Denn wenn der TS abstürzt, ist nicht die Stelle maßgeblich, an der du gerade bist, sondern die, die der TS gerade zeichnet und aufbaut.
    Die nachbarkacheln der Kachel, auf der du dich befindest, wurden bereits geladen und aufgebaut. Aber die übernächsten Kacheln noch nicht. Diese werden erst aufgebaut, wenn du deine Kachel verlässt (so jedenfalls meine beobachtung). Das bedeutet, dass beim Verlassen einer Kachel immer mindestens 3 Kacheln nachgeladen werden müssen und irgendwo auf einer dieser kacheln ist der Bösewicht zu finden, sollte es wirklich an der Strecke selbst liegen und nicht an einem defekten Szenario-Objekt oder an Speichermangel.


    Was kann man nun tun, um dem auf die Schliche zu kommen?
    Nun, zunächst mal sollte man ausloten, ob es wirklich die Strecke ist. Dazu sollte man in den Welt-Editor gehen. Am besten mit einem leeren Szenario gänzlich ohne Rollmaterial, und dann dort die Stelle aufsuchen, wo man abstürzt. Falls es an der Strecke liegt, sollte der Editor jetzt auch ins Gras beißen.
    Dabei auch alle 4 jahreszeiten testen, denn es könnte ja sein, dass eine Herbst-Bodentextur einen fehler hat oder fehlt, was man dann im Frühling natürlich nicht als Fehler erkennt.
    Sollte die Strecke abstürzen, kann man durch Ausblenden der Szenerie, der Lofts, der Roads, der Tracks oder der MipMaps dem Bösewicht noch weiter auf den Zahn fühlen. man blendet diese Sachen aus, indem man den betreffenden Ordner im Conten/Routes/xxx-yyy-zzz-Verzeichnis umbenennt.


    Diese manuellen Debug-Orgien verlangen fundierte Kenntisse der Dateistrukturen des TS und auch, was in den Ordnern jeweils zu finden ist, sonst stochert man planlos wie mit einer Mistgabel im Uhrwerk herum, kann aber sehr lehrhaft sein, wenn man kein Neandertaler auf dem PC ist.
    Ein vorheriges Backup der Strecke (Ordner Content/Routes/xxx-yyy) ist dringend angeraten.

    Dann haben wir 2 ziemlich dieselben Erfahrungen gemacht. Doch war dies bei mir -wie gesagt- noch zu ATI-Zeiten. AMD hat da wohl mal kräftig drin rumgerührt und aufgeräumt, scheint mir.
    Wenn ich nur an das Treiberdilemma unter Linux zurückdenke oder den Wust mit den inoffiziellen Spezialtreibern, wie z.B. den Omega. Das war Wildwuchs und ein Einfallstor für alle möglichen Inkompatibilitäten.
    Hatte ein Notebook mit einer für damalige Verhältnisse sehr guten Grafikkarte, ATI Radeon 9600 oder so. Hat bei Games Probleme gemacht, dass ich das Ding manchmal am liebsten zum Fenster rausgeschmissen hätte, sowohl mit DirectX als auch OpenGL. Ein echter Krampf. Aber seit AMD da dran ist, ist da erheblich was gemacht worden, und das ist auch gut so.


    Aber zurück zum Thema... schön, dass der Bösewicht erkannt und gebannt wurde.
    Und die Moral von der Geschicht'?
    Traue Betaversionen nicht!

    Seit AMD das Heft in der Hand hält ist das meines Erachtens nur noch ein Glaubenskrieg.
    Kurz vorher aber als es noch ATI war, war das noch was anderes. Da hatte ich alle Nase lang bei Kollegen und Bekannten mit Problemen zu kämpfen und ich empfahl denen, sich eine nVidia zu kaufen.
    Aber Jetzt? Glaubenskrieg und Subjektivität, denke ich. Gefüttert aus den längst vergangenen Problemen unter ATI.


    Auf jeden Fall würde ich den Betatreiber ersetzen.

    Wirklich kurios.
    Vor allem diese rechteckige Form am Boden, so als hätte die Lok/der Waggon regelmäßige kleine Bohrlöcher in der Decke.


    Ich vermute, dass DirectX9c ordnungsgemäß installiert wurde und dass auch der AMD-Treiber aktuell ist und ich vermute, dass keine Extra-Tools zur Grafikmanipulation im Hintergrund laufen, oder?
    Falls doch, bitte intervenieren!


    Testweise auch mal bitte das Adaptive Bloom abschalten, meiner Meinung nach braucht man das nicht und es kostet nur Performance.

    Habe den ganzen HRQ-Ordner gelöscht und neu installiert.
    Damit sind zwar auch alle Repaints flöten gegangen, aber ich wollte da eh mal abspecken.


    Wenn du drüberinstallierst, darfst du nicht vergessen, den Cache zu löschen.

    Ich habe mehr als genug Arbeit auf dem Tisch :)

    [Loriot]Ach?! Ach was?![/Loriot]
    [Louis de Funes]Nein!!! Doch!!! Ooooh!!![/Louis de Funes]
    [MontyPython]Wir sind die Ritter, die immer "Ni" sagen![/MontyPython]
    [Prelli]Ja, ich bin wieder albern! Na und?! :P [/Prelli]

    Auch schon probiert.
    Ist ja auch egal, was ich vorwähle.... wenn ich P drücke hat sich bitte der Stromabnehmer zu heben.
    Das macht er aber nicht.


    Ich glaube, ich werde eine neuinstallation vornehmen, ich denke aber nicht, dass das daran liegen wird, bzw. Abhilfe schaffen wird. Irgendwas klemmt da bei der ES64U4er-Versionen. Die ES64U2er gehen anstandslos.

    Danke, aber weder P noch CTRL+P noch der Klick auf das Panto-Icon hebt den Stromabnehmer.
    Wie gesagt, es handelt sich um die graue Weltrekordlok.


    Die ÖBB-Variante werde ich mal versuchen.


    Edit:
    Auch die "HRQ\Taurus\RailVehicles\ES64U4\OBB"-Variante will den Panto nicht heben.
    Ich befinde mich im Quickdrive.


    Edit 2:
    CTRL+P schaltet nur die Pantokonfiguration um, genau wie Shift+P:
    Beide, vorne, hinten.
    Der Panto wird also nur mit P gehoben. Klappt aber nicht. Was mache ich verkehrt? Batterie ist eingeschaltet, Hauptschalter ist aus (lässt sich auch nicht einschalten, logisch).

    Ich bin irgendwie zu doof, den Stromabnehmer bei der ES64U4 "Weltrekordlok" zu heben.
    Ich befinde mich im Cab, drücke Shift+B zum Einschalten der Batterie.
    Dann nehme ich eine Änderung der Panto-Konfig vor, um den vorderen Stromabnehmer zu wählen, weil ich mit Kesselwagen fahren möchte. Das mache ich mit Shift+P.
    Dann lege ich den Hebel für den Stromabnehmer nach vorne "raise", aber nichts passiert.
    Der Hauptschalter ist natürlich noch aus.


    Was mache ich verkehrt? Hat jemand ne Idee?
    Es ist die derzeit aktuelle Version installiert.