Permanent storage is disappears on HTML5 export (SOLVED)

Questions
#1

Hey,

I use the code below to load and save data in HTML5.

local GAME_ID = "game id"
local FILENAME = "Storage.txt"
		
local path = sys.get_save_file(GAME_ID, FILENAME)
local data_table = sys.load(path)			

local path = sys.get_save_file(GAME_ID, FILENAME)
local t = {test=1}
local success = sys.save(path, t)

For some reason the HTML file content that’s been previously saved successfully is not always loaded (the data is missing from the file). This happens both when bundling the game and when exporting directly to HTML5. Am I missing something basic, maybe the files is stored in a temp folder or something?

#2

Just tried doing this in https://www.defold.com/codepad and it seems to work. But keep in mind that storing data permanently/persistent in browsers is “hard”. Depending on security settings in the browser the data might get wiped, or the user has disabled it, or the user could have deleted it themselves. Web-dev being web-dev also means it can differ from browser to browser, or even OS the browser is running on.

The best and most reliable way to store data persistently in browser games is to store it server side. :slight_smile:

3 Likes
#3

Yes, there might be environmental factors, but what gets me is that it works most of the time, then all of a sudden SOME of the data goes missing, or appear to revert to a previous version of the file. Because of this it’s very hard to debug!

get_save_file returns “/data/.game id/Storage.txt”. Where can I find this file? I’ve looked everywhere. On Mac.

1 Like
#4

JavaScript don’t have “regular” filesystem access, but HTML5 does provide a thing called IndexedDB which Emscripten (and thus Defold) use to create a virtual filesystem.

In Chrome you can open the developer tools, go to the “Application” tab and then “IndexedDB”. Iirc the “files” should be available there, but I’m not sure if they are stored in raw text or not.

Worth noting is that file writes/saves are written asynchronously in HTML5 if my memory serves me right. This means that even if you write/save to a file it could take a few seconds until it is actually “written”/“saved”, which could indicate the issue you are describing.

1 Like
#5

Thanks for the info, that’s very useful. However, in this case, I figured out what the problem was. My code logic.

Instead of merging the data (to preserve the whole structure) I overwrote the data with a smaller set. I did this only in one place, leading me to think it was “random”.

Shame on me.

:man_facepalming:

4 Likes
#6

Haha, alright, but now we have a thread to reference next time there are questions on HTML5 and persistent storage. :+1:

bug_in_the_code

8 Likes
#7

Ultimate Shame With a Silver Lining ™. :upside_down_face:

2 Likes
#8

I’ve added a section about this in the HTML5 manual: https://www.defold.com/manuals/html5/#_file_operations_in_html5

I do need to verify the delay with async operations though. I don’t think a sys.save() and an immediate sys.load() would pose any problems. I think the state is kept in memory until the transaction into the DB is completed. There might maybe be a problem with dataloss if doing a sys.save() and immediate shutdown/crash of the browser.

2 Likes