- Home /
PlayerPrefs changing the name of keys?
I am in the process of updating my game from 2.6 Pro to 3.x Pro. I've noticed something very strange about the way PlayerPrefs is working.
When I save a value via PlayerPrefs, it keeps adding a suffix after the key name in the registry (using Windows 7 - 64).
For instance, the following code:
PlayerPrefs.SetString("justTesting", "TEST!");
It saves into the registry, BUT it changes the string name to the following:
justTesting_h3837386411
It adds a "_hxxxxxxxxxx" suffix to every key I save. Each time it has the "_h" but the number sequence is different. I can't for the life of me figure out why it's doing this. Anyone have any ideas?
Answer by jahroy · Oct 19, 2011 at 01:01 AM
That's probably data that's internal to Unity that you're not supposed to understand. It might have to do with how/where it's storing data or anything under the sun.
This only appears in the registry editor right? (I assume these values don't appear when you access the data from your game)
It's actually some kind of hash value of the key-name itself but nothing i can identify :D. It generates always the same hash for the same text.
Answer by Lance Sun · Jan 20, 2012 at 01:56 PM
the hash they use is djb2-xor
uint hash = 5381;
foreach (char c in name)
hash = hash * 33 ^ c;
string key = name + "_h" + hash;
Answer by Ony · Oct 19, 2011 at 01:10 AM
The problem is that my installer sets up a whole range of variables in the registry, and those variables are all being ignored now when Unity reads them. It ends up making its own keys with that suffix on the end, and doubling up everything in the registry (one key will be "Path" for instance, and another is "Path_h3827827302").
Is this something that Unity 3 does to everyone or is it just happening on my system? I'd prefer it just names things what I name them, instead of adding on some arbitrary suffix to the keys.
Is Unity giving them a random name because you're installer is creating them first (and Unity doesn't want to overwrite them)?
Or does Unity name them like that for its own purposes?
I don't know the answer to these questions.
Unity writes them that way regardless of whether the key exists or not.
I'm experiencing the same problem. It really clutters up the registry. I wouldn't be surprised if it's something they needed for Android or iPhone phones but forgot to disable in Windows - since before that registry entries worked just fine on any Windows version.
@Orion 1: no, it's a way to avoid name collisions, specifically because of the registry in Windows, and not needed or used for anything else.
Answer by DaveA · Apr 03, 2012 at 11:49 PM
Seems you can, on Windows anyway, use the Registry class to 'roll your own' player prefs to get around this. Eg:
var rkey :RegistryKey = Registry.CurrentUser.OpenSubKey("Software\\MyCompany\\MyApp");
rkey.SetValue("justTesting","TEST!");
rkey.Close();
if the concern is only with registry keys generated by using PlayerPrefs, which is the question asked, then your solution works i think (i'm not sure what cross-platform considerations there are).
this wasn't the question posed, but for our project, we needed to work with the "standard" registry values that unity uses, such as the video settings, and had to contend with the appended hash. we could scan the registry key for value names that begin a certain way, such as "UnityGraphicsQuality_", and that would work. but in some situations, we needed deter$$anonymous$$istic knowledge of the registry value name. specifically, we have a custom "launcher" that includes an options dialog for graphics settings. we could have used unity's builtin one, but there was no way to hide the input tab. also, our launcher also serves as the patcher, includes an rss news feed, and has other requirements. with a custom launcher, on first run, there will be no registry values set, but our launcher still needs to be able to set video options. we needed to be able to predict the registry value names to support this.