SDK Bug & Feature Requests

I tried to upload world on Linux . But, it's failing with the message "Last built VRChat scene could not be found. Please Test/Compile Full Scene (slow)". "Last Build" and "Build & Publish for Windows" button does not work with this message, but "Build & Test" can work and I can local test it.

TextMeshPro has missing exposure: ForceMeshUpdate , UpdateGeomerty , transform . They are exposed in TextMeshProUGUI. (note: renderer on 'TextMeshProUGUI' is not implemented on original)

I believe it is time to get a solution to the most plaguing issue (in my opinion) of AVPro: Audio Filters I do not think this is a "can't fix" situation. In this proposal I will go over the problem, considerations that have been discussed historically, and the solution I believe is feasible to implement with working sample code. ### Previous Cannys 1) https://feedback.vrchat.com/open-beta/p/986-avpro-player-ignores-lowpass-reverb-and-other-filters 2) https://feedback.vrchat.com/sdk-bug-reports/p/avpro-video-player-audio-filter-issue 3) https://feedback.vrchat.com/sdk-bug-reports/p/sound-effects-are-not-applied-to-audiosource-using-avpro-that-comes-with-sdk3 4) https://feedback.vrchat.com/feature-requests/p/usharpvideo-stream-audio-does-not-support-filters ### Crux of the issue As previously discussed in above canny #1, the current way of handling the AVPro speaker component (type named AudioOutput ) is that the component is implicitly created via AddComponent on the same game object. This has the critical drawback of being unable to respect any audio filters due to the DSP filter chain being _component order dependent_. The second half of this issue is that Unity has no runtime native way to change the ordering of components without fully reconstructing the references. This causes very obvious issues in regards to dependent scene references. (TCL's comment in canny #1 clarifies this as well) ### What has been considered Detecting and destroying/rebuilding known filter components after the implicit component is added. This is bad because all scene references to those components would be lost (eg: UI Events or public Udon variables). To avoid the lost components issue, a full scene search would be required in order to update the references which is costly and fragile. Placeholder components (shims) for each filter type that gets implicitly created after the implicit AudioOutput This is bad because it does not allow users to reference the actual filter components in the inspector (namely an issue for UI Events) Allow adding the AudioOutput script manually in scene and have the speaker search for it before trying to implicitly add the component. This is bad because it requires that the user import the AVProTrial package to be able to use built-in unity audio filters. This needs to be compatible with situations where the user does not wish to import that package so the dependency is decoupled from the feature itself. ### Proposed Solution A shim script that inherits from the AudioOutput class combined with a compiler flag for detecting if AVPro is present, and if not, then have a stub type of the _same namespace and type name_ which is _ONLY_ present in the sdk. Then update the VRCAVProVideoSpeaker to check for the existence of the shim component before creating an implicit AudioOutput, using it instead if found on the game object. This ensures that when the main shim script is loaded in editor, it is already a valid AudioOutput component and the component order is correctly retained so the Audio Filters will work correctly. In the SDK, the script type will check for the existence of AVPro through a version define, and if NOT present, will enable the AudioOutput stub class of the same namespace. An example of what it might be like: https://gist.github.com/techanon/41efc336604e148dde55862bff1778d9 I've tested this specific example in editor and it works there. Can't test in-client obviously.

There are 2 checkboxes in the "Lower Body" section of the VRC Avatar Descriptor and they say "Use Auto-Footsteps for 3 and 4 point tracking" and "Force Locomotion animations for 6 point tracking". But now, VRChat has some other tracking point states like 11 point and 5 point. So I think it should be change the description to correspond to all supports tracking points.

I'm unsure how viable this might be to add, but a very minor QOL addition I'd like to see would be the ability to preview different hardware objects in the hands/feet/hips etc of avatars. Similar to how opening the large menu in game does with a transparent preview of your current controller. This would allow previewing and debugging problems with avatar bone positions easier, but also assist with setting up the correct orientation of props or held objects a lot easier. (for example, firearm props, etc). But this could extend to a gizmo for previewing tracker positions for head, feet, knees, elbows, etc. The way I do this adjustment currently consists of building a test avatar, taking screenshots of the props with the large menu open, going back to the sdk, adjusting, testing, etc etc. This process would be made a lot faster if I could just have a transparent gizmo I could toggle on to preview its orientation and compare with my physical controller instead. It'd also make designing prefabs for other people (or for sale) easier to accommodate the grip that different controllers have. This additionally could be useful with client sim, allowing you to preview the orientation of held props compared to controllers.

Currently the Physbones physics settings are honestly just the worst. I've been doing avatars for years now and the sliders still make no sense and they all behave completely differently depending on the combination. Configuring Physbones should not feel like playing one of those "lights out" puzzles. For instance: In advanced mode, momentum is inverse air resistance, and stiffness is damping. But then if you have gravity up then momentum is inverse damping and stiffness is like pull but towards gravity. Then in Simple mode if gravity is up then pull does nothing and instead just multiplies against gravity? It really feels like there is no way to predict what a Physbone will do and progress is only made through trial and error in editor Play mode. Now I don't actually propose any real changes to the physics as I realize that Physbones are a very simplified physics simulation for performance reasons. I just want to change the interface that is exposed to creators. And only such that one could reasonably set the physics and reasonably predict how they will react in motion with minimal trial-and-error. The sliders need to be re-done so each one only does one thing and always does that one thing no matter the mode or state of other sliders.

There should be like accepting IP from getting codes and automatically log into the account without codes. Because it's kind of annoying how I have to enter a code everytime I wanna log into my account.

Currently, upon reviewing the request headers, there does not seem to be any way to differentiate between string and image loading requests for the same URL. With the limitations of VRCUrl, it would be very nice to have a way to tell them apart. Some potential solutions include specifying a value for the Accept header, extending the User-Agent header, or adding a new VRChat-specific header. I believe the last option would be the least likely to break any existing worlds, but there are various pros and cons of each. An example use-case would be a system to download a mesh (binary data, string loading) and its texture (image loading) using a single URL. The server could use the headers to determine which content it should respond with. This would also be useful for decreasing the size of VRCUrl pools as used in YTS and other worlds. We are already using useragent-dependent responses between video player and string loading useragents, but we'd like to do the same with image loading too.

My seat trigger colliders are inside of a physical hull collider. The hull is on a custom layer called PhysicCollider and I use the "Interact Passthrough" setting to make it transparent to interaction. Live I can interact with the seats. That was uploaded with SDK 3.5.0. But when I upload my world with SDK 3.6.0, the interaction isn't possible anymore. I have to crawl to reach the seat collider inside. I guess, that feature broke with the layer changes in SDK 3.6.0. The first two images shows live SDK 3.5.0 vs my testworld SDK 3.6.0.

Create an expression menu Create sub menu with toggle for parameter which doesn't exist create menu item in main expression menu and link submenu change menu item type from submenu to toggle Current behaviour: VRChat SDK shows "VRCExpressionMenu uses a parameter that is not defined. Parameter: <your parameter name>" and blocks upload Expected behaviour: No warning/error in SDK window SDK: 3.7.1