I’m not comfortable with saving PlayerPrefs if I’m running with Virtual Player Editor Instances to test, and loading them if I’m playing again.
I have the following scenario
Press Play to launch two Virtual Player Editor Instances.
Save the accounts as PlayerPrefs for each to use the auto-login feature on the next launch.
exit Play and press Play again to launch the two VIrtual Player Editor Instances.
Load the previously saved accounts as PlayerPrefs.
At this point, the accounts loaded in each Virtual Player will only load the accounts that were saved in either of the two Virtual Player Editor Instances.
I think the above situation can be quite confusing and troublesome when testing.
Is it possible to improve this?
Besides not using PlayerPrefs, you can always make the keys unique by using something unique about each instance.
Perhaps add a player tag like “one”, “two” etc to make the keys unique, as in var key = "AccountData" + playerTag;
There are probably other ways to find something unique about each virtual instance. Perhaps if they set the working directory to their Library/VP subfolder you could use that.
But other than that I would double-check with a quick test to see if virtual players actually do read from / write to the same key. Perhaps the issue is merely that you get the main editor player’s key every launch? Seeing the code would help.
This sounds like a great idea.
However, we’re too far along in our project to use this method and we’ll be launching soon.
So it’s not an easy situation to apply this method to our current project.
Can you be more specific about this?
Do you mean to open each Virtual Player project folder in the Library/VP path with Unity Hub?
Not “always”, but “almost always” when I tested it.
I had the following code, and the values saved in the main editor were almost always loaded in the virtual player as they were.
PlayerPrefs.SetString("AssetVersion", Version);
If the value saved in the main editor is 1.0.1 and the value saved in the virtual player is 1.0.0, both the main editor and the virtual player will load 1.0.1 on the next run.
In this situation, I expected the main editor to load 1.0.1 and the virtual player to load 1.0.0, but this was not the case.
I say “almost always” because the first time I configured the virtual player, played it, and then ran it again, it seemed to save separately.
But when I repeated it multiple times, it didn’t.
Check the location of the saved key. In Windows it’s in the registry. Make a button that saves a (random) value to the same key and run it from main editor and VP, then refresh the registry.
I bet they both save their values to the same key in the registry and what you observe is a race condition - whichever player saves last has their value stick.
Problem being: you will have the same issue if a user runs multiple instances of the app on the same machine. So if the order of execution of instances is causing you issues because they read to/write from the same local place (be it registry or file) then the solution can only be to individualize each instance.
For example, you could store (and in the editor: update and maintain) an AssetVersion.txt file under StreamingAssets so that if you run different copies of the game they may have a different version of that file because then it’s part of the application instance.
If you need this primarily to test the behaviour of clients connecting with different asset versions then that would also make testing easier since you can take any build and modify the individual AssetVersion.txt files.
For MPPM you’d have to find a different solution however because the VPs share the assets with the main editor. Tags may be one way, or perhaps Directory.GetCurrentDirectory if that is different for each VP instance (it may or may not be). Or a developer GUI where you can select or enter an asset version first thing the instance launches, or any time before the version string is used.