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

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

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.

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.

Create a PlayerObject with pickup + sync on it Join an instance with 2 clients Move the pickups Have a player rejoin You will notice that when the sync is applied, once the saved data is loaded, the object lerps - this should ideally have discontinuity flagged on it when it is moved into position.

Enable Unity Configurable Enter Play Mode https://docs.unity3d.com/Manual/ConfigurableEnterPlayMode.html Enter Play mode > Persistence Breaks

This might be related to this issue : https://feedback.vrchat.com/persistence/p/in-the-world-audioorbs-the-ui-is-not-working "AudioOrbs" by KilerBomb : https://vrchat.com/home/world/wrld_5edb4d7d-2400-49f8-bae1-a8eb48a258e2 See video below, I wasn't able to reproduce that issue on live.

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.

This ones a little odd and edge-casey, but I observed that even though we have OnPostSerialization(), this method doesnt actually seem to be called when the client has finished uploading the new persistence data to the vrc servers, and is instead called roughly when actual uploading happens. So if you have large enough data, you have no direct way of indicating to the user that its still being transmitted/saved remotely, and that they may lose data.