Persistence

Steps to reproduce (TLDR: bold ): Create a world that has this UdonBehaviour(OurTestObject.cs): https://gist.github.com/hai-vr/3439f25571fcc4ad4f65107ad46657d8 Hierarchy example: - Pool - PlayerObject -- VRCPlayerObject + VRCEnablePersistence - OurTestObj -- UdonBehaviour(OurTestObject.cs) - Canvas 5x5 - Text -- TMP_Text 5x5 Alignment=Center&Bottom Wrapping=Disabled Overflow=Overflow In UdonBehaviour(OurTestObj), reference the TMP_Text component Upload the world Start two real clients Make Client A join the world Make Client B join Client A's world Make Client A rejoin the world After Client A finished rejoining the world, Make Client B rejoin the world At this stage, timesJoined should equal to 2 for both clients, confirming that Persistence is working for this world. In OurTestObject.cs, uncomment line 2. This will add a new UdonSynced bool field initialized to false, and a new line in the debug text. Recompile and reupload the world. Make Client A create and join a new instance of that world In Client A's perspective, notice the following in the debug text over the their own head: - The dateTime timer is ticking - timesJoined is equal to 3 - testBool has no text displayed (neither true nor false), but testBool is defined as a bool in U# (testBool appears to be null) Make Client B join Client A's instance In Client B's perspective, notice the following in the debug text over the Client A's head: - The dateTime timer is NOT ticking - timesJoined is equal to 2 (instead of 3) - testBool has no text displayed (neither true nor false), but testBool is defined as a bool in U# - The message "No new data received since ...s" appears, indicating no serialization has occurred. In Client A's perspective, notice the following in the debug text over the Client B's head: - The observations are identical to Client B's of Client A (serialization is failing, so no new data is received) (despite the above, data has been restored to persistent values because timesJoined is greater than 1) (testBool appears to be restored to null from the perspective of other clients, prior to the failed serializations) In Client B, go to the world description and click "Reset User Data", this will make Client B rejoin the world In Client B's perspective, notice the following in the debug text over the their own head: - testBool is equal to false In Client A's perspective, notice the following in the debug text over the Client B's head: - testBool is equal to false - The dateTime timer is ticking (resetting the User Data has correctly set testBool to its expected value of false, so testBool is correctly supposed to be initialized to a non-null value of false) In Client A, rejoin the world. In Client B's perspective, notice the following in the debug text over the Client A's head: - The message "No new data received since ...s" appears, indicating no serialization has occurred. In Client A's perspective, notice the following in the debug text over the their own head: - timesJoined is equal to 3 (despite the Client A having rejoined the world 4 times, the data can no longer be updated. VRChat servers still appear to retain the value of 2 being stored for timesJoined) Observed: Persistent data becomes frozen, unable to be updated any further, and is no longer syncable. UdonSynced fields is contaminated with illegal values (null is never supposed to be in a field of type bool), possibly affecting other Udon program that depend on the integrity of that data. Expected: Persistent data should remain updatable after new fields are introduced to Player Objects. Fields of a certain type should not be contaminated/overriden with illegal values for that type. A clear guideline about adding new fields to Player Objects should be documented officially. According to a VRChat representative on Discord: "in theory it should be just adding udonsynced fields and it's done. There's even metadata that is used to match up an old serialization to a new script to ensure compatibility (and this code has been in use for over a year when two people in the same instance are on different versions of the world). There seems to be some bugs with that system occasionally and it's definitely got room for improvement. Providing a default value rather than straight null would definitely be a good start, and I assume that's 90% of the issues, but it's hard to quantify so I'm not sure exactly what other issues might exist" https://discord.com/channels/189511567539306508/1294086083524432022/1330996987797045320

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.

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)

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.

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

SDK Version 3.7.2 persistence beta Steps to reproduce Attach this script to a GameObject twice: public class TestScript : UdonSharpBehaviour { public override void Interact() { Debug.Log("Interact triggered"); } } Expected bahaviour The line "Interact triggered" should be outputted twice Actual bahaviour The line "Interact triggered" only gets outputted once, meaning that the second Interact event gets ignored This issue doesn't happen in-game. It also works fine on version 3.7.1.

Create a new game object and add VRC_PlayerObject + VRC_Enable_Persistence + An UdonScript with synced variables. Try to check ownership of the object during start, or after player data restored: ```csharp public override void OnPlayerRestored(VRCPlayerApi player) { logDebug($"Player Restored: {player.displayName}"); if (!Networking.IsOwner(player, this.gameObject)) { logDebug($"Player {player.displayName} does not own { this.gameObject.name }."); return; } } ``` Ideally the object that is instantiated for a player should be owned by that player. The docs seem to indicate that this is the case, but doesn't actually work. https://creators.vrchat.com/worlds/udon/persistence/player-object/#ownership I tried using player.isLocal instead, but then late joiners will also process this event for all previous joiners' objects. The only way I'm seeing to workaround this at the moment is to compare if the player is local, then check to see if the game object is in the list of objects' components returned by Networking.GetPlayerObjects(player); SDK Worlds: 3.7.5

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.

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

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.