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
Man könnte nach *.dds suchen und dann nach Größe sortieren. Alles was ne Dateigröße von 5,33MB hat ist korrekt.
Alles abweichende sollte man sich anschauen:
- 4MB = evtl. keine Mipmaps
- Alles andere was abweicht, auf die Bildgröße gucken: Power of Two abweichende Werte bringen auch den Absturz (war zumindestens bei meinem Bhf so)
- größer als 5,33MB ist wahrscheinlich ne 4k Textur
Edit: Also ich habe bei mir auf Anhieb 3 Kandidaten gefunden, bei dem P352 Peterbilt Truck von SD70M hat die normalmap keine mipmaps. Und Mavericks UIC haben ne Größe von 2048x1280 und die SD80Mac von SD70M kannste auh mal testen (mit Auflösung ändern)
Kannst die ja mal testen und Rückmeldung geben.
Die Z-Wagen betrifft es auch
Evtl kannst dir ja mal den Peterbilt runterladen und testen ob ich richtig liege, bei mir gehts nämlich.
Es wäre nett wenn Du mal mit CommonAPI 20190421CrashDebug testen könntest. Technisch gesehen sollte die letzte geöffnete Datei die fehlerhafte Textur sein:
Common API <- Dev Version von heute herunterladen
@eis_os mit der neuen CommonAPI 20190421 und crash debug an habe ich beim Laden des problematischen Speicherstands das folgende:
crash_dump.zip
Die letzten Zeilen:
No resources are missing!
--------------------------------------------------------------
CrashDebug assert hook:
vehicle_cargo_util::MakeVehicleCargoInfo: TransportVehicle 000001FA6D4D0CF0
Last seen opened file: mods/joefried_industriepark_1/res/models/model/bridge/rail/jfviadukt/jfviastein21/jfstein21res.mdl
--------------------------------------------------------------
Normal assert follows:
c:\build\transport_fever\gog\transport_fever_release\src\game\transport\vehicle_cargo_util.cpp:28: class std::vector<class std::vector<struct VehicleCargoInfo,class std::allocator<struct VehicleCargoInfo> >,class std::allocator<class std::vector<struct VehicleCargoInfo,class std::allocator<struct VehicleCargoInfo> > > > __cdecl vehicle_cargo_util::MakeVehicleCargoInfo(const class transport::CargoTypeRep *,const struct model_metadata::TransportVehicle &,const class std::vector<int,class std::allocator<int> > &,int,class std::vector<int,class std::allocator<int> > &): Assertion `(int)capSums.size() == cargoTypeRep->GetNumTypes()' failed.
MinidumpCallback: dumpPath "C:/Users/Admin/AppData/Roaming/Transport Fever/crash_dump/", minidumpId "09bb9661-27d8-41f9-ba51-1f8ee7dd7c2e", succeeded 1
local time is Sun Apr 21 21:22:53 2019
CrashDebug stream open wchar*: C:/Users/Admin/AppData/Roaming/Transport Fever/crash_dump/09bb9661-27d8-41f9-ba51-1f8ee7dd7c2e.dmp
CrashDebug stream open wchar*: C:/Users/Admin/AppData/Roaming/Transport Fever/crash_dump/stdout.txt
CrashDebug stream open wchar*: C:/Users/Admin/AppData/Roaming/Transport Fever/crash_dump/stderr.txtIn Joefried's Industriepark gibt es doch kaum eigene Texturen,vieles wird doch durch Verweise auf Tpf-eigene Texturen erledigt...
Und vor allem - was ich am wenigsten verstehe - jetzt heißt es in der Fehlermeldung nicht mehr "numMipMaps2 == numMipMaps' failed" sondern "cargoTypeRep->GetNumTypes()' failed."
Hmm - ganz andere Baustelle, würde ich mal sagen.
Also ein Problem mit einem Script-Mod?
Das sich mit der vorherigen CommonAPI als mipmap-Fehler getarnt hat?
Nein das ist ein anderer Fehler, was hast du denn vorher gemacht als der mipmapfehler kam? Texurquali umgestellt?
Nein, das war nur zum Testen von Laden von MidMaps bestimmt. (Wäre schön gewesen wenn du direkt im Anfangspost erwähnt hättest, das du mit den Nvidia Einstellungen gespielt hast)
Mein Problem ist wie schon angedeutet, das ich erst mal Testfälle nachstellen muss.
Der Fehler mit dem VehicleCargo kann (muss aber nicht) ein Problem meine einem Hook an der Stelle sein. Normalerweise zeigt der Crash an, das ein Cargo Type nicht mehr gefunden werden kann. (Beispiel: Entfernung eines Cargo Types bei einem Fahrzeug, so teste ich meinen Hook gerade)
Eine Lösung um ein TransportVehicle zu Tracen bin ich gerade dabei zu entwickeln.
Ich hab zwar die model_metadata::TransportVehicle als Adresse, kann aber noch keinen Fahrzeug zuordnen. CargoTypen sind zurzeit auch nur einfache IDs ohne Namen.
TPF Lädt erstmal alle MDLs & Texturen (Dann sollte es bei einem Fehler mit TGA oder DDS direkt crashen)
Danach werden die geladenen Fahrzeug Modelle verarbeitet, deswegen ist das letzte Modell nicht die Crash Ursache hier.
Sollte CommonAPI nun Fehler bei den Cargotypen machen, so lasse mich das bitte wissen.
Die ältere Version der CommonAPI (Webdisk stabil) installieren und schauen ob der selbe Fehler bleibt...
Also liegt die defekte Datei anscheinend (auch) im texturcache, schau doch mal was dort so drin ist 
vllt hilft das weiter.
Naja ich meinte eher das der fehlerhafte Mod einer derjenigen sein muss die auch im Texturcache liegen. Sicher keiner aus res also eher unter mod und da stehen ja die Ordnernamen.
Wie was? Also welchen Fehler passiert wie? Ein Crash von Texturen mit CommonAPI Dev oder ein Fehler mit Cargo? Außerdem wird der Hook für Fahrzeuge, Dateien erst dann installiert, wenn man Crash Debug aktiviert im Spiel. War es aktiviert?
Hmm, sehr komisch... Dann kannst Du testweise die DLL per settins.lua auch abschalten und schauen ob es weiterhin einen Fehler gibt. Ich wüsste aber jetzt wirklich nicht, wo ich für eine Fehlersuche im Code starten sollte. Wenn es ein bestimmter Mod ist, wäre es nett mir diesen zu nennen, so kann ich versuchen den Fehler nachzustellen.
