Beiträge von Gordon Dry

Dann wurde mir etwas missverständlich rübergebracht.
Ich hatte es so verstanden, dass bei der Erstellung des Texturcache mipmap-Level mit erstellt werden.

Klarstellung:

Ich hatte es so verstanden, dass der Texturcache nur für TGA angelegt wird, jedoch nicht für DDS.

Da Tpf nur dann crasht, wenn mit vorhandenem Texturcache der Spielstand geladen wird und dann ein mipmap-Fehler in der Log steht, habe ich daraus geschlussfolgert, dass eine defekte TGA (oder mit falschen Dimensionen versehene TGA) nicht sauber in den Texturcache umgewandelt wird, was dann beim nächsten Ladevorgang MIT Cache zum Absturz führt.

Wenn ich vor jedem Laden des Spielstands den Texturcache lösche, gibt es keinen Absturz.

Das mod verwendet tga (deswegen ja Texturcache).
Aber einen Moment, ich bin fast fertig mit der Testreihe.

Fehlen noch Varianten, also ähnliche, aber nicht komplett gleiche Züge auf einer Linie, z.B. bei Güterzügen

Ich versuche gerade intensiv, das pöse Mod zu identifizieren, was nicht leicht ist.

Aber ich sehe einen Silberstreif am Horizont und habe einen Verdacht, den ich aber noch nicht nenne.
Zuerst einmal muss ich alles zum Mod gehörende aus dem Spiel entfernen und das Mod danach entfernen.

@eis_os am Ende crashte es auch ohne den aktivierten Hook, aber mit der neuesten dev.

Mit der Release 20190331 ist es wurscht, ob niedrige oder mittlere Texturen.

Genauer:

Mit der dev, mit niedriger Textur, ohne texture cache: Cargo crash
Mit der dev, mit niedriger Textur, mit texture cache: Mip map crash

Mit der dev, mit mittlerer Textur: nur Cargo crash

Mit der rls: gar kein crash

Edit:

Ich muss mich korrigieren - eben ist es zum ersten mal mit der rls abgestürzt.
Bei niedrigen Texturen und bereits vorhandenem Texture cache ...

Ich versuche es wieder mit hohen Texturen.

Damn it.

Pfft, jetzt hatte ich den Absturz auch mit mittleren (aka. "hohen") Texturen.

JETZT gehe ich mal zurück auf die letzte rls der CommonAPI 20190331. @eis_os

-> niedrige (aka. "mittlere") Texturen, kein Absturz.

Das Problem tritt ja nur bei niedriger Texturauflösung auf (ingame "mittel" genannt).

Bei mittlerer Texturauflösung (ingame "hoch" genannt) tritt der Fehler nicht auf.

Wenn der Texturcache neu erstellt wurde nach dem Laden des Spielstandes habe ich folgende Ordner in mods:

archbridge_1\
bandion_190er_ki_1\
br146_massstab_3\
br146_oberleitung_1\
br146_signalkomponenten_3\
br189_abfahrsignal_1\
br189_ks_signal_1\
dma_Stations_1\
eat1963_roundhouse_fix_1\
grimes_unterfuehrung_1\
hugedragonyk_urban_expansion_package_crossroads_series_1\
hugedragonyk_urban_expansion_package_crossroads_series_b_1\
jansch_bahnueberganghaeuser_1\
jansch_gleisbaustapel_1\
jansch_mav_cargostation_tpf_1\
joefried_industriepark_1\
kaleut_br_423_422_1\
kaleut_kompaktsignal_auslegermast_komponenten_1\
kaleut_traxx1_1\
kaleut_traxx2_1\
Kawaii-es_ETCS_Signal_1\
majus_beschrankter_bahnuebergang_1\
majus_u-bahn_signal_li_re_1\
mav_bandion_signalbrucken_1\
mav_dad_cargo_con_station_1\
maverick2002_dbdosto_1\
maverick2002_metronom_1\
meister-zogi_ice3_1\
merk_modular_station_1\
nando_container_asset_set_1\
nown_post_mod_final_release_version_1\
randomx7_random_Roehrentunnel_SFS_1\
randomx7_tunnel_schwarzkopf_1\
Rheingold_Deutsche_Gleise_1\
Rheingold_Deutsche_Oberleitungsmasten_gruen_1\
Rheingold_ZS_Signale_1\
RPGFabi_TruckTrainIntersection_1\
Schallschutz_40m_mod_1\
sebbe_formsperrsig_komplett_1\
sebbe_hlsignale\
sebbe_hv69signale_brucke_1\
sebbe_hv69signale_erw3_1\
sebbe_signal_bue_ueberwachung_1\
sebbe_signaltafeln_db_1\
skyjoe_br101_1\
slumpie_trackballast_1\
spyos_schallwandmod_1\
swiss_sexy_rocks_1\
TPF-Addon-Dekoration_-_No Random Trees_2\
TTR66_BR211_1\
ultimate_underground_station_1\
unixroot_natural_environment_pro_1\

Also nicht mal eben machbar, das Problem zu identifizieren.

Wenn es einen Viewer für das Format gäbe - oder Tpf den Cache im Format .dds anlegen würde - kein Problem.
Aber so ...

So, wieder da.

Also, wenn ich den Texturencache nicht lösche, kommt die mipmap-Fehlermeldung.
Wenn ich den Texturencache lösche, kommt die Güterfehlermeldung.

Was soll ich damit anfangen?

Ich hatte in dem Nvidia-Profil herumgedoktert (das habe ich schon oft gemacht, ohne Probleme).
Also z.B. Antialiasing-Einstellungen.

Ziel war es, die Leistung zu verbessern beim Strecken ziehen und Terraforming (alles im Pausemodus).

Ich habe das letze Backup der Profile (wenige Tage alt) wiederhergestellt und den Texturcache gelöscht und versuche es nochmal.

@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.txt

In 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?

Maverick'S UIC sind aktuell nicht auf der Map unterwegs und die anderen genannten habe ich nicht installiert.

Ich schaue mir mal die .dds an ...

Basis-Lektüre:
Problem: tex_load::LoadFile() Assertion `numMipMaps2 == numMipMaps' failed

Das Problem ist, dass irgendein Mod (!) es nicht mag, wenn niedrige oder mittlere Texturauflösung verwendet wird.
Die dazugehörige .dds ist fehlerhaft oder hat gar keine mipmaps oder was weiß ich.

Und was hier gewünscht wurde
Problem: tex_load::LoadFile() Assertion `numMipMaps2 == numMipMaps' failed
ist wohl noch nicht passiert.

Das heißt, ich kann die fehlerhafte Texturdatei nicht identifizieren.

Tja, vielleicht war der Wunsch der Gedanke Meister oder so.

Aus selbigen Gründen.

Für jedes neue Spiel einen 4x so schnellen PC kaufen kann nicht jeder ...
Und abgesehen davon werden die Prozessoren ja garnicht mehr wirklich schneller.

Und wenn ich den neuesten 16-Kerner hätte, Tpf würde auf einem Kern laufen ...

Ja, mein PC ist nicht der schnellste.

Jedoch folgende Symptomatik ist schon störend:

Nach dem Erstellen von 4 Güterzuglinien und dem Kauf der Züge ist die Performance viel schlechter.
Sogar im Pausemodus.

Insbesondere Gleisbau und Terraforming sind extrem betroffen.

Sobald ich die Züge verkaufe und die Linien lösche, sind Gleisbau und Terraforming wieder flüssig und gehen leicht von der Hand.

Und das alles auf einem Kern (also 25% Gesamtlast, von Windows auf die Kerne verteilt - aber de facto singlecore-perforance).
(-> ja, ich weiß, das Programmieren von Simulationen jeglicher Art ist nur schwer in Richtung multicore umzusetzen, aus Gründen.)

@EAT1963 Danke. Jetzt hat die Kohlelinie 2 Züge und die Erzlinie 4 Züge, der Takt bei beiden ist (vorläufig berechnet) bei 7 Minuten und es geht los mit der Eisenerzproduktion.

Ist die 12-Minuten-Regel irgendwo dokumentiert oder "Erfahrungswissen, das im Forum vagabundiert"?

Hmm.

Der (eine) Kohlezug kommt jetzt alle 14 Minuten.

Die (mittlerweile drei) Eisenerzzüge kommen alle 12 Minuten.

Mal sehen, ob sich da was tut.

Das Spiel läuft langsamer, mit den 8000ms pro Tag.

Mit Hilfe von BR146's Maßband habe ich mal die ungefähre Länge der Eisenerzlinie gemessen:

~ 23,5 km

Ich werde mal in den sauren Apfel beißen und eine (total irrationale) Güterumschlagstation in die Linie einbauen.
Umladen von einem Zug in den anderen sozusagen ...

Mal sehen, ob es hilft.

Da ich eine höchst offizielle Info nicht finden kann, muss ich wohl fragen...

Unabhängig von der Taktung; wie lang darf eine einzelne Güterlinie maximal sein?

Ich habe aktuell das Problem, dass kein Eisenerz an das Stahlwerk geliefert wird - Kohle aber schon.

Die Kohlelinie hat mit einem Zug (baugleich zu Eisenerzzügen) und niedrigerer Durchschnittsgeschwindigkeit eine Taktrate von 14 Minuten (Anzeige nach Erstellen der Linie: 18 Minuten).
Die Eisenerzlinie ist ca. 3x so lang, hat aber eine höhere Durchschnittsgeschwindigkeit und hat mit 2 Zügen (baugleich zu Kohlezug) eine Taktrate von 16 Minuten (Anzeige nach Erstellen der Linie: 25 Minuten).

Die Kohle wird in großer Menge an das Stahlwerk geliefert, aber nicht ein Krümel Eisenerz bis jetzt.

Kann es also sein, dass es ein hardcoded Distanzlimit gibt und basta?