When we started talks with Sony, they were confident that the Mono platform would allow us to get Salt and Sanctuary, which uses the .NET framework, running on PS4. For the most part, it has, but it's not without some memory issues that lead to segmentation faults. C#.NET is a managed language, meaning memory management is "taken care of" by the platform. If the platform encounters a segfault, that means it basically failed for some reason that is outside the .NET coder's control.

Segfaults lead to core dumps -- crashes. They happen very randomly, but they happen. I think they happen most frequently while streaming textures from disk into memory, e.g. when a new NPC's armor is loaded in. The worst case scenario that some of you have unfortunately encountered is when the game is writing your save file and encounters a segfault: you end up with a core dump and a partially written save file: a corrupt save.

I can debug my own code easily enough, but random memory allocation bugs that occur within the Mono garbage collector are totally beyond me. The best I can do right now is to try to prevent saving and texture loading from occurring anywhere near each other, and that's something that'll go in the next patch. Basically, the game will keep crashing as often as it does now (blech) but when it crashes, it shouldn't even be thinking about saving data.

We're also hoping that a new Mono update that's in the works will solve all of these problems. It's super frustrating (to me, to you, for different reasons all around), but it's otherwise out of my control.

There are crashes that are under my control (mostly around that Flint & Steel). I'm fixing those. They're wonderfully fixable.

Lastly, I want to extend my deepest thanks and sincerest apologies. This was a game born of our love of the genre and our love of game development, and we count on the support of each and every one of you to be able to keep this going. The last thing I want is to feel like I've let anyone down, and I'll keep working on fixing, mitigating, patching as long as there are things to improve.

Anonymous

Thanks for being so transparent about this, I haven't run into this issue myself but I'm glad to hear that hopefully I won't ever have to. One thing you could look into as a fix for the segfault vs. saving issue is to write out your save files in a more fail-safe manner similar to how databases often do. For instance, you could do something like this:

1. Write out a lock file to indicate you are saving. This doesn't need to contain anything, it just needs to exist.2. Write out the new save state to a new file. Do not overwrite the old save.3. Verify the new save is written out successfully.4. Update game state so that it knows the new save file is the real one.5. Delete the lock file.6. Delete the old save file

The benefit of doing it this way is that it is very hard to get into a state where there is a corrupted save file, regardless of when a segfault might be triggered. Trying to get all of the timing issues associated with preventing things that might segfault from happening at the same time that saves are being created can be very tough to get right, and you still might not ever find all of the issues that could corrupt the save file. With the method above, you can't get into a state where there isn't a valid save file somewhere on disk, so if there is a segfault, on next startup you can check for the lock file, and if it is present you can fall back to the old save file.

Thanks for the great game guys!

0

Anonymous

Anonymous

So I lost my lvl 85 main and all other side characters, I loved this game and was excited for months ahead of time. Now I can't bring myself to play anymore. I don't think I could handle losing all data again, just too big of a slap in the face.

0

Anonymous

Yeah I really appreciate your explanation but in no way is it on for me to lose my 2 day playtime save file, I'm short on gaming time as it is without having to replay things! Shame really as I was really enjoying this game