Loading player data fails between day 10-15

[jawilliams78]

I've been playing since A12 and have never had this issue.  For the last two alphas, I haven't made it past day 15 without my player data file becoming corrupted.  Attempting to rebuild it using the backup isnt an option since the issue doesn't occur until the game loads, therefore overwriting the backup.  Creating backups of the game after every save/exit hasn't worked either because replacing the player data file from the previous save fails to load the same way.  I have uninstalled/reinstalled and validated game files through steam numerous times.  Attached is the output log from the save prior to the failure as well as the output log on the load in that corrupts the player data file.  

Save/exit prior to corruption(I don't see anything I recognize to be errors while saving/exiting game)

https://pastebin.com/EePjiDLF

Corrupted player data

https://pastebin.com/thdb1QTq

 

[Jugginator]

2020-12-06T10:04:22 6.889 INF [MODS] Trying to load from folder: KHA18-BackpackButtonsV2
2020-12-06T10:04:22 6.933 INF [MODS] Loaded Mod: Custom Backpack Buttons V2 (1.0)
2020-12-06T10:04:22 6.933 INF [MODS] Trying to load from folder: KHA19-FoodWater
2020-12-06T10:04:22 6.935 INF [MODS] Loaded Mod: Khaine's Food and Water mod (1.0.0)
2020-12-06T10:04:22 6.935 INF [MODS] Trying to load from folder: Minev2
2020-12-06T10:04:22 6.935 INF [MODS] Loaded Mod: JW_MODS (A19)

Try a fresh game without any mods at all, and I suggest you running a good storage device health check scan to see if you have bad sectors.

 

[jawilliams78]

Problem occurs with no mods as well.  Also, on the last reinstall I installed onto a brand new NVMe SSD.  The issue with reproducing the error is that it takes ~24 hours of play time to get to that point.  Will reproduce with no mods and then post that log as well.

 

[Jugginator]

Something is off, I would still run a storage device stress test. Well over 1000 hours since I have had (I did have one way back in A15 but that was on a dying hdd) a complete save corruption even with crashes; have you noticed any other odd system instability with storage?

 

[jawilliams78]

https://pastebin.com/AkYSUgct chkdsk shows nothing

I have no other issues.  The game runs beautifully at 80 fps, albeit not on ultra.  I don't have any crashes or stutters in the game and no other issues with the PC overall.  

The problem i'm presenting has happened to me on approx. 30 saves in a row and i've tried to do my best to pinpoint the issue.  I don't see any issues in the log nor visually on screen when I exit the game, so i've concentrated my efforts on finding what could be causing the failure on load.  When I load the game I have no browser windows open and no screen overlays(rainmeter/rivatuner/afterburner).  I'm wondering if the problem is related to the file size of the <player_id>.ttp(bak) file.  Do you know if that is getting parsed through GPU memory?

 

[Jugginator]

I doubt it's being parsed through GPU memory but that's certainly beyond my current knowledge. The game constantly writes and reads from the saved file, so if you have some stability issues between your mobo, cpu, ram and storage device I assume the game will find it.

https://www.pcmag.com/how-to/how-to-check-your-hard-drives-health

If you want something to read, there's that.

https://crystalmark.info/en/software/crystaldiskinfo/

As well as diskspd:

https://sqlperformance.com/2015/08/io-subsystem/diskspd-test-storage

 

[SylenThunder]

Backpack Buttons from a18 would not be compatible with the current client. These features are now enabled in the client by default anyway, so you don't need Khaine's mod to enable them.

No the player data should not be parsed through VRAM. 

Something I see is curious.

2020-12-06T10:04:50 35.335 INF BloodMoon SetDay: day 9, last day 7, freq 2, range 0
2020-12-06T10:04:50 35.337 INF BloodMoon SetDay: day 10, last day 8, freq 2, range 0


Have you played with settime?

 

[jawilliams78]

Ok i'll take a look and run all the tests.  The burning question is why does the problem manifest itself at virtually the same stage of /played in every save.  One would think if I had storage issues, it would occur at random and not follow a trend.

@SylenThunder The mod was updated to A19 and the only reason I use it is for the 'lock' feature.  I haven't used settime to change days, normally ill use it when I first load in a new world(settime 04000).  That line of the log is unique to this save as I changed GamePref.BloodMoonFrequency from 3 to 2 after the first horde night.  On previous corruptions, that line wasn't in there.  

I'm in the process of creating a new world without mods and will post the log once that failure occurs.

 

[SylenThunder]

The mod was updated to A19 and the only reason I use it is for the 'lock' feature.

No, it hasn't. The features that this mod added were features TFP has already coded into the client, and had not enabled yet because they were un-tested.  What that mod did was enable the feature.

In a19 the feature is enabled by TFP because they have tested it. That mod has not been updated since 2019, and is basically irrelevant in the current game client version. It needs to be removed.

I haven't used settime to change days, normally ill use it when I first load in a new world(settime 04000).

No offense, but this is a very dumb thing to do. Any time you use the settime command, or the time slider in the DM menu, you risk breaking the save. We're talking about a literal 95% chance of screwing up in-game timers at a minimum, and possibly having a larger effect on the game world an other features.

I've been advising against using this command on anything you care about for 7 years now. Hell, most of the console commands are for testing purposes only, and should never be used on a game you want to keep.

On your issue. Do you have a RAM buffer for your drives?  For example the Asus RamCache III software or something similar.  If used with SSD's or HDD's it's a nice feature. However if you have NVMe's in RAID, I have discovered that the data buffer has issues. I'm not sure if it's going too fast for Windows to manage, or what exactly is going on. (mostly because I haven't had the free time to investigate thoroughly.) What I have discovered is that when Windows is trying to access a lot of data that is cached in this method it has issues reading it properly. I have only experienced it when there was a heavy load utilizing the RAM Cache.

 

[jawilliams78]

No, it hasn't. The features that this mod added were features TFP has already coded into the client, and had not enabled yet because they were un-tested. 

According to this thread, it has been updated for A19.  As I previously stated, the only reason i'm using that mod is for the inventory lock, which TFP code doesn't have implemented.  That being said, the issue at hand was around long before I installed that mod.

No offense, but this is a very dumb thing to do. Any time you use the settime command, or the time slider in the DM menu, you risk breaking the save.

The only reason i'm using it at all is because i've had to continuously start over.  I want all the time I can get since I know the clock is ticking to day ~15.

On your issue. Do you have a RAM buffer for your drives?  For example the Asus RamCache III software or something similar.  

No RAM cache.  Although that does fall in line with what my instincts are telling me.  RAM/VRAM issue?  Power supply issue?  Storage failure(i'm almost sure this isn't the problem since the failure has occured both on an older HDD and a brand new EVO M.2)  I'm going to move forward with the save that I just started.  I'll also be running OCCT, CrystalDiskMark, Furmark, MemTest86, and Cinebench as time permits.  There is a fault on my end i'm sure of it, but I just can't figure it out.  Unfortunately i'm working 70+ hours a week until the first of the year, so the zeds are safe for now.

 

[Jugginator]

Well, certainly let us know your progress. The testing may reveal more, the problem may not be the drive itself but could be linkage inbetween.

Or it could be Windows.

Although Windows is never guilty.