Persistence

At the moment there is a high risk that a world builder may release an update to their world that ends up breaking everyone's Persistence data in an unrepairable way. This could be caused by bugs within Persistence itself. When either of these conditions occur, there is zero recourse for the world builder to correct peoples' data beyond telling everyone to wipe their data completely, losing all progress. This can be catastrophic in cases where player progress was enhanced by purchases through the Creator Economy. This problem isn't unique to VRChat, as it occurs within Roblox as well, and is especially important due to how many transactions are tied to progress in their games. However, Roblox provides a comprehensive interface where the world builder can force a roll back of player saved data to any prior date at any time. This effectively eliminates all risk with releasing world/game updates, giving the builder recourse in the case of irrecoverable corruption. I brought this to Fax who thought it was a good idea and recommended making a Canny post, so this post is to request that we get a similar feature, so world builders have the option of force rolling back a prior date of saved Persistence data. An example world is my world: Elite's RNG Land. Players can purchase an upgrade that speeds up progression, however there have been instances where a bug, either through code or API bugs, caused players to completely lose months-worth of progress. The only recourse was to tell people to wipe their player data and start over.

The ability to open two instances of VRChat in separate windows under the same account, each being a different instance of the same world, creates significant issues for any game world that relies on persistence. I'll refer to the two windows as "Window 1" and "Window 2." Both are running the same world but in different instances. If a player performs an action in Window 1, such as getting a reward or losing progress, and the world saves that, they can simply close Window 1, switch to Window 2, and wait for the world to save their data. This will entirely overwrite the changes from Window 1, restoring their progress as if nothing had happened. This exact issue happens very commonly on mismanaged Minecraft servers, where you can have two instances open on the same server but in different subservers. This is most commonly used to duplicate items, which no RPG-style game world wants. An example in VRChat would be the world "Project Aincrad". If, in Window 1, Player 1 trades 10,000 in-game coins they have to Player 2 while Window 2 is up, then at the end of the trade, when the game forces them to save their persistence data, Player 1 in Window 1 will have 0 coins, Player 2 will have 10,000 coins, but Player 1 in Window 2 will still have the 10,000 coins, meaning that 10,000 coins have now turned into 20,000 Coins. I'm not very technical, so this is more of a guess for a potential solution, something like only allowing Window 1, or whichever window was first in that specific world, to be capable of changing the persistence data for that user and world.

When multiple Udon components with synced variables attach on the same child GameObject (whose parent has VRCPlayerObject and VRCEnablePersistence), Persistence only restores variables from the first Udon component. Steps to Reproduce: 1.Create two Udon components (A and B). Each Udon component contains one synced variable. 2.Create a parent GameObject with VRCPlayerObject and VRCEnablePersistence. 3.Create a child GameObject under it and attach components A and B. 4.Run a local test with a single client. 5.Set the values of the variables in A and B using any method. For example, set A to 3 and B to 5. 6.Rejoin the instance. 7.Check the values of the restored variables using any method. Expected Behavior: All variables are restored to their previously set values (A is 3, B is 5). Observed Behavior: Only the variable in component A, which was attached first, is restored. Component B's variable is reset to its initial value. (A is 3, B is 0). Additional Notes: Swapping the order of components A and B on the child GameObject reverses the result (A is 0, B is 5). This confirms that the issue is related to the component order. SDK version is 3.8.1. Similar issues found below, but it's unclear if they are related: https://vrchat.canny.io/bug-reports/p/pickup-events-may-not-be-called-when-multiple-udon-components-are-attached https://ask.vrchat.com/t/potential-issue-with-multiple-udon-components-execution-in-sdk-3-7-5/33845

If the Unity project settings Reload Domain is disabled, ClientSim doesn't properly handle Player Objects, causing exceptions and stopping work. Repro Start Unity. Create a scene. Add VRCPlayerObject component(s). Enable Play Mode Options and disable Reload Domain (via Unity menu > Edit > Project Settings > Editor > Enter Play Mode Settings) Press the Play button to start ClientSim (it will work normally at the first launch). And exit play mode. Press the Play button again. Then, MissingReferenceException occurs (see attached). And it doesn't work correctly anymore. Version World SDK 3.7.5 Analysis Clientsim caches the Player Objects in ClientSimNetworkingUtilities._playerObjectList . And it depends on the reloading to initialize it. It should be initialized when starting the simulation. Snipping from the log for searching MissingReferenceException: The object of type 'VRCPlayerObject' has been destroyed but you are still trying to access it. Your script should either check if it is null or you should not destroy the object. VRC.SDK3.ClientSim.ClientSimPlayer.SetupPlayerPersistence (VRC.SDK3.ClientSim.IClientSimEventDispatcher eventDispatcher, VRC.SDK3.ClientSim.IClientSimUdonEventSender udonEventSender, VRC.SDK3.ClientSim.IClientSimBlacklistManager blacklistManager, VRC.SDK3.ClientSim.IClientSimUdonManager udonManager, VRC.SDK3.ClientSim.IClientSimSyncedObjectManager syncedObjectManager, VRC.SDK3.ClientSim.IClientSimPlayerManager playerManager) (at ./Packages/com.vrchat.worlds/Integrations/ClientSim/Runtime/Player/ClientSimPlayer.cs:198)

Would be nice if a component was introduced to the SDK that would set the Network ID of a GameObject automatically when uploading / regenerating IDs for the sake of convenience and consistency. Requesting this because PlayerObject Persistence requires the same Network ID for the data to be loaded, currently regenerating network IDs doesn't guarantee the same ID for the PlayerObject which can result in losing the saved data in the PlayerObject. Hoping for something like this to address this comment regarding the Network ID Utility in the #open-beta-persistence channel https://discord.com/channels/189511567539306508/1294086083524432022/1294170696703934484

Saw this comment under the latest dev-blog by the user "harunadev" and thought it would be worth to propose. I don't know the actual limits of the backend but i can defo see value fort this. "I would love to see if the persistent user data could sync between worlds (within the same author). For example, User makes a change on world A, then whenever the user joins the world B (same creator from world A), world B gets to read the changes the user made on world A. This could allow world creators to sync user settings/infos within their collection of worlds. And also I really hope to see a custom resolution option (whether it’s in config.json or UI configurable) for the new desktop stream camera in open-beta. Keep up those good things team!"

ClientSim spawns player objects in OnBeforeSceneLoad, so changes made to Player Objects in PostprocessScene don't persist to the local player's Player Object. Further Player Objects spawned through "Spawn Remote Player" do have the changes. Please move the player object spawning to later in the runtime so changes made through PostprocessScene can persist to the local player's game object. As far as I can tell, this is only a problem in ClientSim. It seems to work fine in-game.

Issue: Currently Player Data doesn't support VRCUrl, which makes using persistence for URL Input Fields really annoying to do. Currently the only way to store a VRCUrl is with PlayerObjects, which can often lead to some quite cursed setup. Suggestion: Add VRCUrl to the support data types of Player Data, this would allow us to more easily store and access them.

Currently there's no way for World Creators to clear PlayerData keys, we can set the value to whatever is the smallest, but the key is still going to exist forever, take space, and be synced to every other player unless the user manually resets his player data. If a complex world goes through rapid changes or frequent updates to their systems that involve PlayerData there's a big chance some keys will turn obsolete, and it is likely that recurring visitors will unavoidably store unused keys and data, unnecessarily cluttering the network and their persistence data. Udon Function: An Udon method for PlayerData.Remove(VRCPlayerApi player, string key) would allow for creators to manually handle clearing these keys. Some other solution: I think there should also be another option for creators that are not familiar with Udon and mainly rely on prefabs. Example scenario: using a badly coded prefab or too many prefabs that fill up the PlayerData size. Even if the prefab is deleted, a new player with no PlayerData would not experience issues, but a recurring player might because he still has the old keys.

I would love a way to store persistent data that doesn't get replicated. This likely wouldn't make as much sense on PlayerObjects, but it would be great to have either a flag or a section in PlayerData that's scoped only to the local user, for storing more private data. This would be great for things like a "last entered code" for admin panels, for example, where it improves UX but you wouldn't want it replicated out to all clients in an instance. I can forsee one potential issue with this however, users storing potentially sensitive information in these keys (such as passwords) so this would likely need to come with some kind of disclaimer.