Persistence

I can envision a situation in which one PlayerData key (or a collection of keys) might contain a large amount of data (for example: saving the state of a 'tycoon' world or other UGC), but other keys might be updated rapidly or in succession (example: world settings). Currently, if the PlayerData gets too big, updating the smaller more frequently updated keys will start to throttle the network. The docs suggest using PlayerObjects for larger AND more frequent data, but PlayerObjects have an entirely separate API lacking the ability to dynamically specify a key (and currently a separate data limit). It would be much better if a partial update could be sent over the network so we can update smaller fields without worrying about larger data which is already stored throttling the network.

This is part bug report, part feature request. Play any world that has persistence data Have vrchat disconnect with the error "Your connection to VRChat timed out. Verify connection and try again." - preferably where the entire instance times out, not just you. (maybe photon crash?) Rejoin the world All persistence data for that session will have been lost. Ideally, VRC would either periodically permanently flush that data even without disconnect, or have some backup method to save persistence data in the case of a photon crash, so games where multiple hour long sessions occur don't result in total data loss. Alternatively, some way for the client to recover state upon reconnect in the case of a server crash (some kind of server-provided short-lived signed copy of the data that can be sent and reverified on reconnection, if it has a timestamp older than the server's copy) would be a nice to have, as it can prevent VRC-side infra netsplits resulting in total data loss in many cases. This was seen on US-east servers today, multiple times. Entire instance disconnects and total data loss for all users in the instance. The state gets reset back to how it was prior to loading into that instance initially - it is all rolled back/forgotten.

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.

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!"

According to the persistence docs, there is a 100kb (compressed) data limit for PlayerData, and a separate 100kb limit for Player Objects. PlayerData and Player Objects have completely different APIs, so if we want to make full use of the data limits for a single purpose, we have to implement it in 2 ways. Example: A world where users can create custom user-generated content (UGC). If I want to allow users the maximum space to save their UGC in persistence, I would have to implement a PlayerData API and a Player Object API, and detect when one is full to switch over to the other. Instead, it would be useful to allow us the maximum 200kb split any way across PlayerData and Player Objects.

I was playing the Suika game and streaming some music over VRCDN. Then suddenly my Internet connection became very unstable. My stream stopped, and while I was trying to figure out what was wrong with it, I got the "connection to VRChat timed out" message. After a couple retries a managed to get back into the world, but the game was not functioning - all players and their games were frozen, their avatars weren't loading, and as I noticed later, the persistence data hadn't loaded either (I had only 1 Melbux instead of 425 billion). After half a minute I got another "connection timeout" message and rejoined the world again. This time it was working, but very sluggish, and my persistence data didn't restore - it was gone at this point. Here's a recording of all of this happening: https://youtu.be/rL3wOgvS0rQ Also attaching the log file and two screenshots: the first shows that I had 425B Melbux before the disconnection, and second shows me having only 1 after rejoining.

It would be nice if world creators could save some setting locally on the players device. Saving options like performance settings will create a headache for world authors having to check if the settings are available on that platform or saving separate keys for each platform. If world creators don't add extra checks, it could lead to things like crashing on lower end devices. A good example of this is Steams cloud saves feature, some developers save graphics settings inside cloud saves, making switching between devices like a PC and Steam Deck a headache, often leading to crashes because of invalid resolutions or poor performance. Ideally settings like game progress would be saved on the servers to help prevent tampering and things like visuals could be saved locally.

Now that Persistence is in the game, it would make sense to give us the ability to also locally store data that isn't game-breaking if it's lost, but that would benefit from not being constrained by networking limits (and not taking up the limited persistence space). Some examples would be: Settings for local-only state in the world. Precomputed textures/models for dynamic content, such as character customization. The game already does this for per-avatar parameters. And of course we wouldn't be able to choose where to store it for security reasons, but make it similar to PlayerData in that we only get to say what we want to save, but expanded a bit on data-types, such as textures & JSON. (and ability to only load the data from specific keys when you need the data, not all of it at once). Having this capability could reduce networking needs, especially for more ambitious worlds and open up more gameplay possibilities. Understandably there would still need to be limits on how much data could be stored, but it could certainly be much, much more than the 100KB each of Player and PlayerObjects, say 2GB for PC only worlds and 400MB for Quest, with limits that could rise as min-hardware levels change. (and creator can fallback to regenerating content instead if local-space limits are hit). Would probably want to display how much local-storage a world is using when a person clicks on the world in the menu and option to sort worlds by data usage, so people can identify junk worlds they might join that try to fill the space for no reason just to annoy, then user can hit the "Clear data" button for that world which already exists (or better have a button also for local-data specifically in case they are just trying to free space).

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.

World persistence in VRChat can for example allows creators : Build global leaderboards that carry across instances. Share cumulative player statistics. Create worlds that evolve based on player actions, etc. Allowing groups making changes or perform actions or set custom parameteres in a world, save them, and later these settings would be applied to any users who joined. Basically, creating more advanced worlds that attract and retain players on the platform. Limiting it to Creator Economy members would encourage more creators to join the program rather than rely on external services, while helping increase VRChat’s revenue. This feature could be offered as a paid option with a small fee, because data storage has real costs. The service could provide access to a lightweight database (such as SQLite, with XX.XX MB of storage) for use in a single world or shared across multiple worlds. Single World Database Plan : $5/month (or ~600 credits) Access to a dedicated SQLite database for one specific world. Universal Database Plan : $10–15/month (or ~1200 credits) Access to a shared SQLite database usable across multiple worlds. You pay for a limited database, and depending on your plan, you can use it in one or multiple worlds. Similar feature request: https://feedback.vrchat.com/feature-requests/p/multi-world-persistence https://feedback.vrchat.com/persistence/p/cross-world-persistency https://feedback.vrchat.com/feature-requests/p/vrchat-provided-world-data-persistence PS: For anyone concerned about the cost -> VRChat needs revenue to operate, and since this feature is limited to Creator Economy users, they can earn money that will quickly covering the cost.