Welcome to the Developer Update for 12 October 2023!
Today’s Dev Update thumbnail contains a variety of terrifying(ly good) content that’s been submitted to Spookality 2023! Get your submissions in soon – you’ve only got 4 more days!
If you’d like to catch up, you can read our previous Developer Update from 28 September.
Important Info / Announcements
VRChat 2023.3.3 Rollback and Open Beta PART TWO
So, we put out 2023.3.3 last week. But then, a buncha people told us that there were some serious issues, so we rolled it back.
These issues were hard to track down and repro, so it likely slipped through Open Beta, being waved off as a one-off oddity. However, once everyone had their hands on the build, the problem got way worse!
We recently put out a fixed 2023.3.3 on our Open Beta. If it isn’t on Live now, it’ll be out to live REALLY soon. jk we found a performance regression that’ll prevent us from shipping this for now. sorry!
Unity 2022 Open Beta
Our Open Beta is currently testing a version of VRChat running on Unity 2022! This is a change from our current version, which is on Unity 2019.
We are getting very close to finishing up the 2022 testing. We expect to go Live with Unity 2022 within the next few weeks.
Expect to see us publishing and testing instructions for project migration well before that date, as well as a final “this is the version we’re using” decision.
Remember, though, no reuploads are required. All content from Live VRChat works in this build.
This is your PENULTIMATE warning. Test your content. Test your content. Test your content.
If you find a bug, report it. If you don’t report it, it will not be fixed. Do not assume someone else has reported it. We don’t care about dupes.
Make sure your reports are good. In short, good bug reports are clearly written, concise, and contain all relevant information necessary to make the bug happen on anyone’s computer. If you can’t provide that last part especially, it makes it super hard to fix.
Spookality 2023!
Spookality is upon us! Submissions for both avatars and worlds are already open, and will close on October 16th at 12PM PT. Make sure you get yours in before submissions close!
Avatars and Worlds will be showcased between October 20th and November 11th. Avatars will be shown in the default VRChat Home with a special additional section, and worlds will have their own World Category where you can browse through.
You have FOUR days to send in your submission! Send it in soon!!
New Years 2024!
Just so you don’t think we’ve forgotten, we’re planning and setting up for a New Years celebration once more!
We’re trying to open up poster submission to a wider audience this time around, so the process may be a little different. Change is good!
Keep an eye out for announcements regarding News Years celebrations. If you have questions, feel free to ask in this thread.
SDK Semantic Versioning
With the move from date-based versions to Semantic Versioning for the SDK, we made it possible for community package creators to declare dependencies, but we aren’t truly following the rules:
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes
- MINOR version when you add functionality in a backward compatible manner
- PATCH version when you make backward compatible bug fixes
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
We wanted to follow the above rules, but for a number a reasons, we haven’t. So now, we want to clarify how we’re using version changes in the main SDK packages, and stick to it going forward.
Concept: Branding.Breaking.Bumps
A form of this concept was brought up in a Feedback post regarding the increment of the SDK to 4.0.0 for the Unity 2022 versions, which reflects a community-based point of view as to what we’ve been doing. Anatawa12 suggested “BRANDING.MAJOR.MINOR”, but I suggest alternate names to differentiate our system from SemVer and make its use more clear (since “Major” and “Minor” typically refer to the first and second number, I think it would be confusing to reuse them in different places).
BRANDING
This number would not change frequently, and represents the major shifts between incompatible systems. 1.x was custom scripting, 2.x was SDK2, and 3.x is SDK3.
If a new system for Avatars introduces an incompatible change such that SDK3 Avatars cannot be migrated, we would increment the Avatars SDK to 4.0.0, for example. Since Udon 2 has a migration and code-reuse path from Udon, it would be 3.5.0 instead of 4.0.0, for example (numbers subject to change based on release cadence).
BREAKING
We increment this when we make incompatible API changes such that packages which relied on the previous functionality need to be updated before they’ll work properly. This is how we protect both creators and package creators from confusion over broken packages due to SDK updates.
BUMPS
We increment this whenever we make a new release. They’re often a combination of Bug Fixes and New Features.
The Public API for the SDK
With the release of SDK 3.3.0 and the updated Build Panel, we published our first Public SDK API. This is what we will not break between “Bump” versions. We will work to expand the scope of the Public API based on properties, fields etc. which are commonly used by Community Package Creators.
We encourage VPM package creators to use proper SemVer for their own packages, which did not start at 3.0.0 like ours and won’t have the confusion over compatibility with SDK3 like we would when releasing a 4.0.0 version.
We will publish a new page in the Creator Docs describing this overall “Branding.Breaking.Bumps” approach soon™.
Ongoing Development
Mobile Native UI
Among the many things we’re working on for VRChat on Android Mobile, we’re working on a new lightweight native UI for the client!
The video shows me using Google to log in for the first time. VRChat asks me if I already have an account and allows me to link my existing account rather than creating a new account. If I didn’t have an existing account, I could skip this, and a new VRChat account will be made just like it is for Steam and Meta.
But, if I log into my VRChat account, like I do in the video, my Google account is seamlessly linked to it! I never have to use my extra secure (and hard-to-copy) password on my Android phone ever again!
After logging in, I’m presented with a feed showing a list of friends, a Group Plus Instance someone in the Open Beta group is in, a recently visited world, and some recommended worlds. While the only other thing I show is my profile, there are plenty of other pieces to this UI that weren’t shown.
This is still getting heavy work and is in continued development, so keep an eye out for this to come to the Mobile Alpha at some point in the future!
Content Gating: Reporting Missing Warnings
As part of our Content Gating effort, we will be adding a new report type for worlds and avatars: Missing Content Warnings.
With this new report type, you will be able to inform our Trust & Safety team about any avatars and worlds that you believe contain content that users should be warned about.
We are also happy to report that we are still on track to release the next part of Content Gating this year, where you’ll be able to filter content from your VRChat experience based on that content’s Content Warnings.
Finally, we’d like to thank everyone who has already spent the time to label their existing worlds and avatars with the appropriate Content Warnings. Doing so helps with making Content Gating effective and creating a better experience for all VRChat users!
Screenspace Canvas Changes
This one’s pretty technical, but its important especially for mobile development!
Right now, creators are coming up with inventive ways to handle showing and hiding of screen space canvases to avoid them showing over the top of our menus. This is particularly important when you’re making mobile-focused UIs:
(This is MyroP’s Lightcycle Arena, btw. Go check it out, it’s a ton of fun and really well made!)
We’ve come up with a solution!
Now, when the Quick Menu or Main Menus are shown, we find all user-created screen space canvases and automatically hide them (if not already).
We then track the state of the screen space canvases throughout the duration the Menu is present. Once the menu is closed, the canvases are presented correctly.
For example, if a canvas is changed from disabled to enabled whilst the menu is present, once we close the menu we will ensure the canvas is enabled.
This is an example of some of the changes we’re making to VRChat to reduce the need for our creators to find novel solutions to problems like this, especially for mobile-centric development.
Conclusion
That’s it for this Dev Update!
Our next update is scheduled for October 26th, 2023. See you then!
A lil final note
I’ve been noticing that these threads tend to turn into people going on for two weeks, slinging walls of text at each other as they argue about some highly specific technical nuance.
While I don’t mind discussion, I do mind when it turns into almost-but-not-quite-insulting language. When that takes over the entire thread, it makes it nigh-unreadable for anyone uninvolved.
In addition, many of these forum wars (finally, it’s 2003 again…) are regarding subjects that we didn’t even cover in that Dev Update… or sometimes, in any Dev Update.
These threads are meant to be a place for discussing what we have coming up for VRChat in a kind, accessible manner, so let’s keep it that way. If you don’t have anything nice to say, reconsider pushing that tempting “Reply” button.
I’ll be moderating these threads more heavily going forward, so please don’t be surprised if off-topic posts get hidden or removed.
Thanks!