Persistence

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.

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

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. 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).

Steps to Reproduce Create a GameObject with VRC Player Object and VRC Enable Persistence Create an UdonSharp script that have 27 or more [UdonSynced] int fields (27 int is 108 byte) Attach it to the GameObject Build & Test the world Change field value and save by RequestSerialization Rejoin [UdonSynced] fields are not restored Additional Information * Serialization succeeds with OnPostSerialization * It does not output any errors, so I am unsure if it is failing to save to the server or if it is failing when restoring * ClientSim does not have this issue * 14 or more double fields also leads the same issue * I attached UdonSharp script that reproduce the issue Proposal This limit is easily reached, and I would like to be able to handle more fields if possible. Also, this limitation is not written in the documentation and should be added.

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.

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.

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.

Launch World: https://vrchat.com/home/world/wrld_882d1b16-ef0d-470f-b6e1-9523702e44d3 Check Logs to see Data has been written. Rejoin World. Check Logs again, notice that Test3 failed for both Continuous (expected) and Manual (unexpected). Manual Sync behaviours are expected to be able to persist one serialization on their own within a PlayerObject with Enabled Persistence. Test 1 works as expected. Test 3 serializes correctly over the network but fails to keep data between sessions. This is despite both storing roughly a similar amount of bytes in Manual sync and should be within the Manual Sync limit. Serialization expectedly fails for tests with Continuous > ~200 bytes. Tests 1-3 are ran on Empty Objects that are children of their own individual Player Objects with Enabled Persistence. Test 4 is ran on two individual empties. C = Continuous Sync Mode. Expected to fail at ~200 bytes. M = Manual Sync Mode. Expected to fail at ~280,496 bytes. Test4 - PlayerData test with SetBytes (40 & 256) Test1 - long[] test with 5 & 32 elements. Test2 - 5 long variables. Test3 - 32 long variables. Screenshot shows logs after rejoin.

Although it would still be best practice to save data periodically, it would be a nice quality of life feature to have one final opportunity to save as the player leaves. Please allow us to save data in OnPlayerLeft OR provide a new event before OnPlayerLeft to the local player which would allow us an opportunity to save any data.

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