cullam

Restoring corrupted feats

Recommended Posts

Similar to another discussion going on, but I had a tragedy occur last night. As I entered a cabin, my computer simply turned off. I've recently moved, and haven't really set up my office yet, so my desktop is sitting on the floor. Poor thing overheated. I fired up the Long Dark today, and discovered that while me current playthough is still there, I have zero progress on all my feats, and no history of having completed all the challenge modes. Anyone know of a way that I can restore this? Steam cloud? Anything? I would REALLY hate to have to redo all of the bloody feats.... 

Share this post


Link to post
Share on other sites

Update - the feats that I had turned on for my current play-through are still turned on! But it's still claiming that I don't have any of them done. When I first launched the game in this state, it had the update "!" mark on feats, and challenges, clearly thinking that I'd never even looked at either. 

Share this post


Link to post
Share on other sites

You'll need to find a copy of your "user001" file (or reasonable facsimile) from before the accident.  Without finding a backup copy all hope may be lost. 

If you find one, place it in your save game directory while TLD is running (and Steam is online) then quit out.  Replacement should then get sucked up to the cloud and replace all instances.

Share this post


Link to post
Share on other sites

See if there is a way to restore the folder where the user001 file and sandbox saves are to a prior system restore point or something.

When you right click on folders there is an option "restore previous versions"

Share this post


Link to post
Share on other sites

No luck finding a backup, at least locally. I presume that Steam Cloud would have helpfully saved my corrupted version over top of my working version? And that it doesn't keep any kind of version history? 

Share this post


Link to post
Share on other sites

Sigh.... It took me so long to complete all those feats.... 

Share this post


Link to post
Share on other sites
2 hours ago, cullam said:

Sigh.... It took me so long to complete all those feats.... 

Hey cullam, sorry to hear that. And yes, it sounds like corrupted data is involved due to the computer shutdown. One step you might try if you haven't already is a complete re-install of the game. For some players, that has been effective at re-syncing the correct data from the cloud. Let us know how if goes for you. 

Share this post


Link to post
Share on other sites

What about the file user001.cfg, found in TheLongDarkNoSync? Is that something useful? It's dated a month older then the other user001 file! 

Share this post


Link to post
Share on other sites

I can confirm that uninstalling and reinstalling didn't resolve it. Might there be any sort of manual update that could work? Or even a way to take the feats that are active in my current run through, and restore them to my user file? 

Share this post


Link to post
Share on other sites

Renaming the "nosync" version of user001 to not have an extension seems to work.  

But to get it up into the cloud you'll have to drop it into the save directory while the game is running, and then quit.

EDIT:  I can also confirm shutting down the computer without first exiting the game results in save game loss upon restarting the game.  

Edited by selfless
  • Upvote 1

Share this post


Link to post
Share on other sites
10 hours ago, selfless said:

Renaming the "nosync" version of user001 to not have an extension seems to work.  

But to get it up into the cloud you'll have to drop it into the save directory while the game is running, and then quit.

EDIT:  I can also confirm shutting down the computer without first exiting the game results in save game loss upon restarting the game.  

So you fixed it then? If so awesome and congratulations!

Wow, so even though the game saves at certain specific places, if your computer turns off in the middle of playing for any reason the last good save no longer works?!

Is that what you are saying, or am I misunderstanding you?

Share this post


Link to post
Share on other sites
22 hours ago, selfless said:

Renaming the "nosync" version of user001 to not have an extension seems to work.  

But to get it up into the cloud you'll have to drop it into the save directory while the game is running, and then quit.

Holy crap, that seems to have worked!! 

Because the file was older, it doesn't have all my progress, but it's much MUCH better than starting over! Thanks! 

  • Upvote 2

Share this post


Link to post
Share on other sites
On 7/19/2017 at 10:29 AM, selfless said:

EDIT:  I can also confirm shutting down the computer without first exiting the game results in save game loss upon restarting the game.  

Wow, does this happen if the computer loses power or experiences a hardware problem that shuts it down?  In case it does, I'm going to start backing up a copy of my current sandbox file in a separate directory.  Seems like a very bad bug!

Share this post


Link to post
Share on other sites

Yeah, even though getting in the habit of backing up your saves and user001 file may lead to save-scumming, it may be a good idea to periodically back those files up in a folder somewhere else for the day you lose power or something. 

It is unfortunate that the saves become corrupted if the game closes suddenly without exiting properly. Hopefully this is something they can fix to make doing this unnecessary....

Share this post


Link to post
Share on other sites
On 7/20/2017 at 2:29 AM, selfless said:

I can also confirm shutting down the computer without first exiting the game results in save game loss upon restarting the game.

7 hours ago, Ruruwawa said:

Wow, does this happen if the computer loses power or experiences a hardware problem that shuts it down?  In case it does, I'm going to start backing up a copy of my current sandbox file in a separate directory.  Seems like a very bad bug!

6 hours ago, Thrasador said:

It is unfortunate that the saves become corrupted if the game closes suddenly without exiting properly. Hopefully this is something they can fix to make doing this unnecessary....

 

<puts on IT hat>

This generally occurs when a program doesn't actually 'close' a file (such as a game save) after writing to it, but keeps it 'open' to save time when it next wants to write to it. An unexpected power loss causes the file to be left in an 'open', indeterminate state, where the program can no longer access the file because it was never 'closed' correctly.

This used to be a huge problem years ago, before "journalling" file systems were invented for hard drives. A Journalling File System keeps a record of all write actions waiting to be written to disk, enabling the system, on rebooting, to rebuild any files that weren't correctly closed. It's not foolproof, but is far better than in "the bad old days". 

My guess is that this is something more likely to be a problem with Unity's file handling, than a bug within TLD itself. But it possibly IS a TLD bug. Today's programmers tend to be less aware of the problems that can occur with files accidentally left open, because, thanks to more reliable computers, it's a far less common occurrence. They also tend to be more separated from the file-handling routines, simply relying on standard code libraries for such things, rather than having to directly deal with it themselves. Back when I was coding, we had to pay close attention to details like this.

 

Edited by JAFO
  • Upvote 1

Share this post


Link to post
Share on other sites
14 minutes ago, JAFO said:

 

<puts on IT hat>

This generally occurs when a program doesn't actually 'close' a file (such as a game save) after writing to it, but keeps it 'open' to save time when it next wants to write to it. An unexpected power loss causes the file to be left in an 'open', indeterminate state, where the program can no longer access the file because it was never 'closed' correctly.

This used to be a huge problem years ago, before "journalling" file systems were invented for hard drives. A Journalling File System keeps a record of all write actions waiting to be written to disk, enabling the system, on rebooting, to rebuild any files that weren't correctly closed. It's not foolproof, but is far better than in "the bad old days". 

My guess is that this is something more likely to be a problem with Unity's file handling, than a bug within TLD itself. But it possibly IS a TLD bug. Today's programmers tend to be less aware of the problems that can occur with files accidentally left open, because, thanks to more reliable computers, it's a far less common occurrence. They also tend to be more separated from the file-handling routines, simply relying on standard code libraries for such things, rather than having to directly deal with it themselves. Back when I was coding, we had to pay close attention to details like this.

 

Well clearly you know much more than I do about this area of knowledge...

So would it be possible for them to create a save system that is more stable by using some sort of Journaling File System to record the little bits waiting to be saved in the next proper saving moment? So that the save could be reconstructed and function after something like a sudden power loss or the game crashing to desktop without closing it properly?

In theory?

Edited by Thrasador

Share this post


Link to post
Share on other sites
30 minutes ago, Thrasador said:

So would it be possible for them to create a save system that is more stable by using some sort of Journaling File System to record the little bits waiting to be saved in the next proper saving moment? So that the save could be reconstructed and function after something like a sudden power loss or the game crashing to desktop without closing it properly?

In theory?

Well, the JFS is already there.. most modern OS's use JFS by default these days. A JFS works by having pending disk-write operations (such as a save) queued up ready to be written when the system isn't so busy. The queued writes get stored in a recoverable buffer. For something like TLD, this won't work because there is no save pending, until such time as the game wants to update the save.

It probably more comes down to the file-handling routines provided by Unity. If Unity allows saves to be closed after updating (this forces a write operation to the disk, and marks the file as 'closed') then that would be the best way to prevent the file being corrupted, unless you were unlucky enough to actually be in the middle of saving when the power failed. However, in that case, the JFS has a very good chance of preventing damage to the file.

The problem comes because, often for performance reasons, but sometimes because the programmer is simply unaware of the underlying system (most coders no longer have the intimate hardware knowledge that used to be a necessary part of the job), rather than close the file between saves, they keep the file open for the duration of the game. It saves time, particularly for games which may save at random intervals, such as TLD (those brief save pauses when you get hurt would be a good bit longer if the game had to open and close the file, as well as write to it), but leaves the save vulnerable to power outages etc.

But I'm not familiar with the file-handling libraries Unity uses, so I can't say as to how easy what I regard as "correct" file-handling is, when using that game engine.

Edited by JAFO
  • Upvote 1

Share this post


Link to post
Share on other sites
11 minutes ago, JAFO said:

Well, the JFS is already there.. most modern OS's use JFS by default these days. A JFS works by having pending disk-write operations (such as a save) queued up ready to be written when the system isn't so busy. The queued writes get stored in a recoverable buffer. For something like TLD, this won't work because there is no save pending, until such time as the game wants to update the save.

It probably more comes down to the file-handling routines provided by Unity. If Unity allows saves to be closed after updating (this forces a write operation to the disk, and marks the file as 'closed') then that would be the best way to prevent the file being corrupted, unless you were unlucky enough to actually be in the middle of saving when the power failed. However, in that case, the JFS has a very good chance of preventing damage to the file.

The problem comes because, often for performance reasons, but sometimes because the programmer is simply unaware of the underlying system (most coders no longer have the intimate hardware knowledge that used to be a necessary part of the job), rather than close the file between saves, they keep the file open for the duration of the game. It saves time, particularly for games which may save at random intervals, such as TLD (those brief save pauses when you get hurt would be a good bit longer if the game had to open and close the file, as well as write to it), but leaves the save vulnerable to power outages etc.

But I'm not familiar with the file-handling libraries Unity uses, so I can't say as to how easy what I regard as "correct" file-handling is, when using that game engine.

Ok, well I understand the drawback of making saving slower. It becomes a matter of what do you think is worse, slower saving, or losing all your progress in a slow methodical perma-death game.

Maybe they could at least put badge and feat completion in a secondary location so it will no longer be lost by losing power.

  • Upvote 1

Share this post


Link to post
Share on other sites