Shader pre-caching Update (transport Fever 2)

Willkommen in der Transport Fever Community

Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.

 

Die Registrierung und Nutzung ist selbstverständlich kostenlos.

 

Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.

Das Team der Transport-Fever Community


    Guten Morgen zusammen, also folgendes, heute Morgen hat es anscheinend ein Shader Pre Chaching Update von Transport Fever2 bei mir gegeben , siehe Bild. Dann ist folgendes passiert: siehe Bild 2 , das eine Fehlermeldung kam von Common API Native. die hab ich zwar weggeklickt, und das Spiel lief dennoch problemlos. Aber irgendwie müsste da nicht ganz was rund gelaufen ist, denn gestern lief alles noch ohne Probleme und Fehlermeldungen.


           


    Bin da bisserl ratlos, was des nun sein sollte. Danke für Eure Antworten und Hilfe.

    Problemlos ist relativ. Mir wäre kein Update bekannt, seit Änderung von Steam kann man aber nicht mehr sehen ob UG neue Builds vorbereitet. Man sieht nur noch das Endergebnis bei Release.

    Zumindest hat UG keine Änderungen bekannt gegeben und die Testing Version wurde auf Release zurückgestellt.


    Starte mal den Computer neu und schaue ob du weiterhin ein Fehler hast, welche TPF2 Version (Build) und CommonAPI2 Version hast du genau?


    Die CGame Hooks werden für eine Menge Funktionen genutzt, das zu ignorieren ist eher suboptimal... Spätestens beim Laden eines weiteren Spielstands gibt es Chaos...

    Ich habe die aktuellste local buildNr = 20241220 , Ich habe den PC nochmals neu gestartet, jetzt ist der Download bei Steam weg, und keine Meldung mehr. Steam hat aber gerade wieder neu aktualisiert. könnte das sein, das Steam da ein Problem gehabt hat. Irgendwie bisserl verhext, ich hatte ja noch nie solch eine Meldung. Aber nach PC Neustart funktioniert es wieder. Alles bisserl perplex irgendwie.

    Das komische ist, der Binärcode für Windows & Linux ist ziemlich eindeutig.

    #ifdef OS_LINUX

    const char* vtablename_uniqueptrCGame = "St23_Sp_counted_ptr_inplaceISt10unique_ptrI5CGameSt14default_deleteIS1_EESaIS4_ELN9__gnu_cxx12_Lock_policyE2EE";

    #else

    const char* vtablename_uniqueptrCGame = ".?AV?$_Ref_count_obj@V?$unique_ptr@VCGame@@U?$default_delete@VCGame@@@std@@@std@@@std@@";

    #endif


    Sprich ich wüsste nicht wie es passieren kann, das es nicht gefunden wird. (Es ist auch nicht eines der ersten Fragmente, d.h. die Funktion die Speicherposition zu finden muss auch nicht total daneben liegen)

    Es kann eigentlich nur mit ASLR zusammenhängen und das zu debuggen wird schwierig.

    Der TPF2 Prozess muss dann genau wieder an die Adresse im Speicher geladen werden, der diesen Fehler triggern könnte.


    Bedeutet:

    Code
    - Passiert das bei nochmaligen starten des Spiels ohne PC Neustart?
  Nein -> Könnte AV Software sein
  Ja ->
        - Passiert dieses nach Neustart des Rechners?
             Nein -> Könnte ein Fehler im Zusammenhang mit ASLR liegen
             Ja   -> Dann wird die Build nicht unterstützt, changelog.txt anschauen.


    Mir fällt da gerade keine Lösung bzw. Weg ein... :/ Wer dazu Ideen hat, gerne...


    Bitte sowohl CommonAPI2 als auch TPF2 Build bei Fehlermeldungen anheften. (Stdout.txt bei so etwas ist auch nicht verkehrt, wobei nur die Linux Version zurzeit das gefundene Speicherlayout anzeigt)

    Vielleicht auch einfach nur ein Bitkipper irgendwo der nach dem Neustart weg ist. Gibt immer wieder lustige Effekte wie ein Bitkipper im Passwort, wie wir es einmal hatten. Der Account war dadurch unerreichbar...