So will stuff made in udon 1 be fully compatible with the udon 2 compiler?
Yep, that’s the idea!
However, we recommend re-uploading worlds with the Udon 2 SDK to take advantage of the performance gains in Udon 2.
Very excited to see actual progress on both Udon 2 and Persistence (stuff I’ve been eager to get my hands on / see what others do with)!
Out of curiosity how does the setup for player objects work? Is it only one script / object that will get networking when instantiated or will the networking work for multiple objects (ex: multiple vrc pickups parented to the initial player object)?
Also will multiple player objects be supported per world?
Is the persistence mentioned going to be cloud saved or cached on the user’s pc (or their device)?
In editor, it’s just a single object which you put a component on. That source object is then disabled and kept around as the “original”. When a player joins, that object is duplicated and network IDs are assigned.
You can have multiple separate synced objects per player object, in the children. You can also have multiple completely independent player objects, which is of course very important for prefabs.
It’s stored server-side! But it’s only available while a player is in the instance.
So different players can access each other’s player data to make scripting easier.
^from Fax’s comment earlier
Just commenting to note that I attempted to reach out to the “ux @ vrchat . com” email listed in the user research form and was met with an “Address not found” error.
Thought I’d comment here considering it’s on-topic and will probably get noticed and fixed faster this way haha
Oh. Will follow up internally, thanks for flagging! I’ll comment when we get this sorted.
I will second being able to have global data across worlds, being the developer of a system multiple world creators use it would be nice to be able to have global settings for said system. A great example is audiolink for if you have very specific settings you like for your avatars
saving in udon is happening udonbros we’re so back
gone are the days of password systems for saving
Happy for native persistence at long last. Also appreciate that VRC did not break VRCX’s interim solution as was originally discussed a while ago.
And yes please more world fav slots/rows. VRC proudly boasts the number of worlds it has and then only lets you fav a relatively limited number of them, it’s a bit silly!
It sounds like the player object is basically a native and faster built in version of Cyan’s PlayerObject Pool? Or does it add a little bit more beyond what that library provides?
We updated the Google form! It was supposed to be " ur@vrchat.com" not ux. Sorry for the confusion!
It’s basically Cyan’s player pool, yes. The interface is slightly different, but it’s all the same goal and should have the same core feature set. However, then it also has persistence on top of that. You can disable persistence on a per-object basis though if you don’t want that.
Hmmm…
I’m thinking of two changes:
-
4 preset color themes if not subscribed to VRC+
-
More reporting options (user is underaged, etc)
1st one is because some people aren’t used to looking at blue all the time and can switch to a different color they can take for a long time (possibly based off of user rankings?)
2nd one is because…
(Well, why do you think?)
Whether udon2 has opened restrictions on URL construction is really important for string and image loading
Udon2 does not currently have any changes to the VRCUrl system, that’s a separate issue.
Have you considered opening up vrcurl’s build restrictions, perhaps requiring some security measures such as notifying players before building?
VRC+ would be basically worthless if it didn’t have extra world + avatar groups (besides being able to make groups now), lmao
Yes, this is something we discussed in great detail internally, looking forward to when we can share the plans.