Beiträge von Gordon Dry

Es sieht im Grafikprogramm nach Graustufen aus, aber technisch ist es ein Farbbild.

dview

btw I still got a dump files issue, but it does not look like that your mods are still the culprit, as mentioned here:

Tpf2 lief stundenlang ohne Probleme, aber hat 1432 crash dumps erzeugt

But who knows?

dview I just will do a quick test - I delete all those config folders again and try to reproduce the issue.

Seems like a discrepancy between core frequency (FSB), CPU multiplied frequency and RAM/Bus frequencies.

Update:

Wenn ich ein Stück Gleis ziehe, egal welches, egal wohin, solo mitten in der Landschaft oder angeschlossen an ein bestehendes Gleis;

sobald ich dieses abreissen will (Bulldozer-Cursor über dem Gleis, gelbe Markierung), werden 3 *.dmp - Dateien erzeugt.

Wenn ich es dann abreisse, werden weitere 3 *.dmp - Dateien erzeugt.

doug  dview  EISFEUER

Interesting. I did not use any of the "austria_fever_760_infrastruktur" set until now (it's 1860) - and this special behaviour is new, max. 2 days ago it started to behave like that.

Last session I tried to reproduce the error and after doing this and that the first time a bunch of those dump files was created was as I added a switch with a short segment of railroad to an existing railroad track.

Edit majuen :

The latest "railroad track mod" I added was https://steamcommunity.com/sha…iledetails/?id=2581062718 - that mod contains tracks so perhaps they could be the trigger for the behaviour of "austria_fever_760_infrastruktur"?

Edit doug :

I removed "austria_fever_760_infrastruktur" and tried to trigger the issue again.

This time no "lua exception" to be found in stdout.txt, but still dump files created - after I deleted a few track segments that I dragged into the wild, not connecting to anything:

stdout.txt

(FYI I already mentioned several issues about "austria_fever_760_infrastruktur", but I think they are not taken into account because I just wrote comments at the filebase entry.)

I actually try to find the culprit for masses of *.dmp files being generated while ingame.

No crash, no obvious issues, but ...

see Tpf2 lief stundenlang ohne Probleme, aber hat 1432 crash dumps erzeugt

Could it be that those lines of the script before the appearance year of any of the cars with license plate triggers this?

local n = game.interface.getEntity(t)
if n.name == 'no name' and string.find(n.fileName,nameToCheck) then
local s = string.format("%d",t)
local sn = api.cmd.make.setName(t, s) --the new name will simply be the string version of the entity id number.
api.cmd.sendCommand(sn)

I'm just curious ...

This behaviour started two days ago, I recognized it last night.

There were a total of over 2700 dump files over 3 sessions, starting with shortly after I reenabled the updated VW T3 ...

Die Menschen sind echt blöd - anstatt die bewährten "Backupsysteme" zu behalten, werden diese einfach ersatzlos gestrichen. Wie z.B. der Turm bei einer Feuerwehrstation. Warum? Weil es Satelliten gibt? Und was ist, wenn ein Sonnensturm die Satelliten bzw. deren Elektronik hinwegfegt? Dann wird man sich noch nach dem Turm zurücksehen...

Und das gilt stellvertretend für so vieles, was die ach so tolle Menschheit abschafft, weil es was "besseres" gibt. Ohne Backups...

Gibt es einen Debugging-Parameter, der, wenn gesetzt, alle naslang .dmp-Dateien erzeugt?

Wenn ja, könnte ich nach diesem Parameter im Modordner suchen, irgendeine Mod muss ja dafür verantwortlich sein.

Ich meinte nicht den Modconverter ...

Es wurden "nur" .dmp - Dateien erzeugt, keine zum Dateinamen passenden XXXstdout.txt - sondern nur die normale stdout.txt.

Aufgefallen ist mir das erst nach Beenden von Tpf2, als ich Backups erstellen wollte.

Nur stdout.txt

stdout.txt

Der komplette Ordner

crash_dump.part001.rar

crash_dump.part002.rar

crash_dump.part003.rar

crash_dump.part004.rar

Da ich nicht weiß, wie die Roadmap aussieht, frage ich mal, ob eine Version für Tpf2 von "Convert Capacity To Compartments" in Arbeit oder in Planung ist.

Das wäre eine unglaubliche Bereicherung und steht auf der "Vermisstenliste" ganz weit oben.

Nun, ein Viadukt ist ja auch nicht zum Überspannen größerer Abstände gedacht. Dann muss an der Stelle ein anderer Brückentyp eingesetzt werden.

Oder zuerst das Viadukt, dann die Gleise einzeln unten durch.

It seems that removing the config folders also solved another issue of another mod:

https://steamcommunity.com/wor…3916/3108016147991274001/

5th post from top, I quote:

Zitat von 5th post from top at "Freestyle train station" discussion "Bug reports"

When I draw a platform track parallel to a rail track, after each finished segment when starting to drag a new segment, it "disappears from the cursor" and I have to start dragging that segment again - after each one.

Each time this happens this is logged:

replaceEdgeWithSameRemovingObject: objectIdToRemove is no good, it is nil

Even the logging of that error message is gone now.

Aften reenabling VW T3 and deleting all config folders incl. all other bko_ mods the issue is gone.

dview those 3 I got before disabling for confirming:

bko_vw_t3_4

bko_vw_t3_4_brands_4

bko_vw_t3_4_roadcars_de_4

Perhaps check for accidental global variables? Stuff like that?

dview

I can confirm that removing "VW T3" solved the issue (all of them as I don't know if one or several or all of them trigger that issue).

Edit:

The Jag is okay.

I guess I should like to this here:

Asset Placement Delay

tzm as only mods with prefix "bko_" are triggering this issue, do you also use the

Jaguar SS100

which also got a "bko_" prefix and is uplaoded by dview ?

I just wonder if that car also triggers the same issue or if it's a VW T3 issue only.

Edit:

for clarification - I'm aware of the fact that the VW Golf III and the Cars of the 1990's are also from dview aka. bko.

Those have been added to my game by me long before VW T3, the Jaguar was added later, so I can't be sure if the Jaguar also is problematic.

That's why I'm asking.

Unfortunately not - the issue still persists after removing the Thumbs.db files.

I can do another test run with VW T3 disabled... it would be weird if that is the culprit.

tzm this issue already occurs in 1850 and so way before any VW T3 ever appears.

Do you think that the VW T3 mods got issues that affect the whole game whatsoever? Could you please try to reproduce with enabled VW T3 mods but before they appear in 1978?

And then without VW T3.

Important is, that after loading the save playing for some minutes is necessary, it could be that the issue is not already triggered just after loading.

dview

Edit:

I found that only the VW T3 mods got hidden thumbs.db files in them. I will delete them now and see if that helps.