Pixel Crushers Forum

Whenever my game saves it blocks the main thread for a brief second or so. I'm already spawning a separate thread for the actual file writing but no help. So I profiled what the problem was and it was RecordSavedGameData(), most of which is the DialogueSystemSaver generating a very large string for all the variables etc. Even though it is running out of a coroutine, no help because there's never a yield in there so it just runs for a long time without yielding back.

The duration it takes to save doesn't bug me, but how do I go about getting this to not block somehow? I already tried tossing RecordSavedGameData onto a separate thread, but it uses too many Unity API calls and Unity disallows those unless on the main thread. Would I have to somehow split up this method with yields? Problem there is if I yield per every single variable write, that's way too many and it will take ages to actually save. I suppose I could do an arbitrary number of em and chunk em out, then yield after each chunk.... If it comes down to that, I'll have to do it, but wondering if you have any good tips on this. Thanks.

I just tried the "raw" setting with a binary serializer and it sped it up quite a lot, almost no delay now, but the save filesize went up by over 100x, which is quite absurd..... I think I'd still rather pursue the non-blocking save between these two options.

Hi,

As you've seen, the save process makes Unity API calls, so it needs to be on the main thread.

First check this: How To: Tips to Reduce Dialogue Database Size/Memory

Then try the raw data save. If there's still too much delay, and if you're not using the full save system (e.g., SaveSystem.SaveToSlot()), then use PersistentDataManager.GetSavepDataAsync(). If the delay is due to a very high number of dialogue entries, you can tweak the Dialogue Manager's Persistent Data Settings > Async Dialogue Entry Batch Size value.

If you are using the full save system, it doesn't currently record DS data asynchronously. (The saved game data storer system, however, does allow for the option of async saving to permanent storage.) Your choices are regular or raw. However, SaveSystem.SaveToSlot() does wait one frame before kicking off the blocking save process, which allows you to activate a onscreen save icon or something similar.

In the GetRawData() method, I removed the writing of conversations, actors, items, and locations, since I only need to save variables. This reduced the filesize drastically, almost back down to what it was before. Is this going to impact something negatively? I made sure to get rid of those same ones in the raw reading during loads too, seems okay so far but are there any other scary unforeseen gotchas about this?

You'll want to make sure the other data tables get initialized to the values in the database. In ApplyRawData(), comment out the same things. Change the Lua.Run() line to:

Thanks, I'll try this.