PlayerPrefs don't persist on Facebook WebGL game - What's the solution?

Unity Engine
1

My testing shows that each time we release a new version of our game to Facebook, the PlayerPrefs will not persist through versions. My understanding is that it’s due to the URL differences between the two versions and the method used by Unity+WebGL does not handle this.

Is that assessment correct?

If so, what’s the solution? How can we use PlayerPrefs in this scenario?

2

Hi! Yes, unfortunately, we have a bug, it creates new PlayerPrefs each update, because Facebook puts your game into new URL. We already have a new logic that fixes it, but you can workaround that by looking at IndexedDB playerprefs location and replace lookup function with it.

Generally, steps to workaround are next:

  1. prepare a new build A.
  2. open NAME.asm.framework.unityweb (in release mode it’s gzip’ed file, you must decomress it first)
  3. find

function _JS_SystemInfo_GetDocumentURL(buffer, bufferSize) {
if (buffer) stringToUTF8(document.URL, buffer, bufferSize);
return lengthBytesUTF8(document.URL);
}

  1. replace with

function _JS_SystemInfo_GetDocumentURL(buffer, bufferSize) {
workaround = “workaround”;
if (buffer) stringToUTF8(workaround, buffer, bufferSize);
return lengthBytesUTF8(workaround);
}
(or change “workaround” with something you already know from IndexedDB inspector)

  1. compress back to gzip, if you’re working with release build

Yeah, it’s not that easy, sorry.

2 Likes
3

Hey jura_z, i tried this workaround but for some reason I always get an
“SyntaxError: illegal character” when I compress the file back to .gz and try to run the game again.
I`m doing the gz using 7zip default settings (I tried only editing the already compressed file, resulting in the same error)
Is there a special configuration to gzip the file?

EDIT

Ignore the reply, i found that this only happen when running the file locally to test

1 Like
4

Aplogies if I’m just showing my JS ignorance, but does the declaration of workaround need to be preceded with var?

Should that be:

function _JS_SystemInfo_GetDocumentURL(buffer, bufferSize) {
  var workaround = "workaround";
  if (buffer) stringToUTF8(workaround, buffer, bufferSize);
  return lengthBytesUTF8(workaround);
}
5

How have you successfully gzip’d the file and have this work?

(jura_z)

I’ve tried in gitbash on a windows machine:

mv facebook-webgl.asm.framework.unityweb facebook-webgl.asm.framework.unityweb.gz
gunzip facebook-webgl.asm.framework.unityweb.gz
gzip facebook-webgl.asm.framework.unityweb
mv facebook-webgl.asm.framework.unityweb.gz facebook-webgl.asm.framework.unityweb

That is, gunzip, then gzip without any modification to any files and recompressed with 7z then uploaded to FB and running I get

Uncaught TypeError: UnityLoader[r] is not a function
at UnityLoader.loadCode.Module (UnityLoader.js:1)
at HTMLScriptElement.o.onload (UnityLoader.js:1)

I’ve also tried gzip’ing it using my linux box - same result.

What am I doing wrong?

6

Ok, I finally got this to work by simply not recompressing (gzip) the facebook-webgl.asm.framework.unityweb file - not ideal as it’s now about 5 times the size (maybe FBs server will gz it (???))…

But, it would be fantastic if you could let us know what the workaround string will be when the fix is publicly available?

I’d like to know this so I can use that same string now or I’m setting myself up for a lifetime of manually changing that facebook-webgl.asm.framework.unityweb file every release (ahhhhh - maintenance nightmare).

7

Bump…

@jonas-echterhoff_1 , @Schubkraft , @Marco-Trivellato , @jura_z ,

Can anyone help here? I just need to know what string will be used (or if it can be specified as a build parameter) for the workaround ( PlayerPrefs don't persist on Facebook WebGL game - What's the solution? ) when this is publicly available.

I really don’t want to release with an different string than Unity will use or I’ll be setting myself up for a maintenance nightmare.

This is the only thing holding up our release now.

Any information will be greatly appreciated.

8

Bump - no one?

This would be very helpful - a few minutes of your time to let us know how this workaround string will be derived will save me a maintenance nightmare.

I must release tomorrow - deadline for review is looming, so I’ve got about 12 hours to find out or I’m going down the maintenance nightmare path :frowning:

9

Sorry, we just don’t have the solution at this moment that’d fit all situations and will be there forever. I think I will try to give you a workaround that will help you to avoid maintenance hell just after we have a general solution

10

Thanks for the info. Do you think it is possible that the final solution could allow us to specify this as a build property? That way I can be sure that there will be no maintenance issue.

Ideally I’d like a “Manually Set PlayerPrefs storage key” checkbox that’d allow me to enter the string I’m using now - and therefore not break existing users PlayerPrefs when we release using the final solution. This would be fantastic… Or if that’s not practical, perhaps just allow it to be scripted as part of the build process for those in a situation like I’m in.

Thanks again.

11

Hi @jura_z ,

We’re still using 5.6, is this fixed in the latest release?

Thanks!

12

Hi @jura_z ,
In a HTML5 build, it seems my PlayerPrefs do not save, from Play to Play… So once someone plays the game, all in game PlayerPrefs are stored, but if they turn off the game and reopen, they are gone.
Is this true? What can be done?