SDK Bug & Feature Requests

I would like to be able to specify a specific instance for the world SDK portal prefab. Different friendgroups of mine have custom worlds we spawn in using a launch parameter into a specific instance, I would like to "connect" them so we can visit each others shared launch instances without having to use weblinks or navigating menus. It would be much more fun and immersive to be able to just travel through in-world means and build a shared, persistent neighborhood that spans across multiple worlds.

In the new SDK 3.7.6, it's now possible to build a world on Linux, but it is not possible to launch a local test with proton. Pls add proton support, similarly to: https://github.com/BefuddledLabs/LinuxVRChatSDKPatch

On MacOS currently in ClientSim VRCObjectSynced gameObjects when told to change either their Raw Transform or using the TeleportTo() does not allow the synced object to move. The way I encountered this is in this snippet of code: var card = objectPool.TryToSpawn(); Networking.SetOwner(Networking.LocalPlayer, card); card.name = deckManager.cardUtils.GetCardString(cardPulled); var cardSync = card.GetComponent<VRCObjectSync>(); if (cardSync != null) { Debug.Log($"{cardSync.name} Is found for movement"); cardSync.TeleportTo(spawnPoint); } // I also tried the following instead of cardSync.TeleportTo(SpawnPoint): card.transform.position = spawnPoint.position; card.transform.rotation = spawnPoint.rotation; MacOs Verison: Tahoe 26.5.1 SDK Version: 3.10.4 Unity Version: 2022.3.22f1 (Rosetta)

Currently, the VCC always creates Windows projects by default. When installing Unity, the VCC should install the modules required for Android and iOS. It would be nice if users could choose Android or iOS directly instead of switching to it after project creation.

Build & Publish will loop building all selected platforms forever, with no obvious error output, if one of them is over the size limit. Tested in 3.10.3, I don't see a fix for this in the 3.10.4 changelog. It's different, but might be related to the issue reported here .

Currently, if the client is launched with --watch-worlds, it will reload into any built world, regardless of whether it was built for Build & Test or Build & Publish. I would much prefer if it only reloaded if the build was for Build & Test. At the very least, please make it not try to load non-Windows builds because this just causes the client to emit an error anyway.

OS: Arch Linux (but any Linux would get the same results) Unity 2022.3.22f1 Unity project managed by ALCOM (a cross platform open-source alternative to VCC) VRChat SDK version is 3.8.2 Summary Setting Build Type to Build & Test Your Avatar in the VRC SDK window, then clicking Build & Test does not place the new avatar inside %LocalAppdata%Low\VRChat\VRChat\Avatars (as per documentation ), and it is thus impossible to locally test avatars. Why This happens because that directory does NOT exist on Linux; the virtual C: drive created for VRChat by Steam is inside its specific proton prefix, and as such the right path is more likely to be located near /path/to/SteamLibrary/steamapps/compatdata/438100/pfx/drive_c/users/steamuser/AppData/LocalLow/VRChat/VRChat/Avatars/ . This path is not right for every VRChat installation, because Steam allows for multiple game drives. Solutions I see two potential solutions; one of them requires fewer changes and is less practical for users : After building an avatar for testing, if the environment is Linux, provide users the path to the compiled avatar asset so that they can move it over to the right folder manually If the environment is Linux, inside the VRC SDK window, in the settings tab, add possibility to set the path to either the root of the virtual C: drive, or just to the folder where the user wants to export their testing avatars Please, please do ask more info if you need it, I will happily provide them, and I'd be happy to see this bug fixed I have found the location, it is inside .local/share/VRChat/VRChat/Avatars/, I have not seen that documented anywhere, maybe updating the docs would be nice... ~~Also if you just give me the path to the compiled avatar I'd be happy, I really wanted to test it out so...~~ Also, I would gladly fix it myself if the sdk was open source... is that planned ? Is it forbidden, in the meantime, to go and decompile and fix stuff for myself ? What about publishing fixed dlls ?

Attampting to upload avatar without adding tags is bugged. It gives an error stating: "tags must be an array: null, tags must be a string: 'null'" The error wont be given if you add atleast 1 tag. Running VRChat SDK - Base and VRChat SDK - Avatars at version 3.10.4

Current if you want to develop Worlds/ Avatars on an Apple Silicon Mac you need to use Rosetta for components of the SDK to still function. This is going to be impossible after in 2028 when Rosetta is removed from Macs. This means it would be ideal if there could be patches made that made the SDK Instruction agonistic. Currently There is only 1 major area that does not support it in the current SDK version (3.10.4): Harmony errors for memory access: Exception: mprotect returned EACCES MonoMod.RuntimeDetour.Platforms.DetourNativeMonoPosixPlatform.SetMemPerms (System.IntPtr start, System.UInt64 len, MonoMod.RuntimeDetour.Platforms.DetourNativeMonoPosixPlatform+MmapProts prot) (at <036d18f9edfb4e6d97ce4f777d0e0eb4>:0) MonoMod.RuntimeDetour.Platforms.DetourNativeMonoPosixPlatform.MakeWritable (System.IntPtr src, System.UInt32 size) (at <036d18f9edfb4e6d97ce4f777d0e0eb4>:0) MonoMod.RuntimeDetour.DetourHelper.MakeWritable (MonoMod.RuntimeDetour.IDetourNativePlatform plat, MonoMod.RuntimeDetour.NativeDetourData detour) (at <036d18f9edfb4e6d97ce4f777d0e0eb4>:0) MonoMod.RuntimeDetour.Platforms.DetourRuntimeILPlatform._HookSelftest (System.Reflection.MethodInfo from, System.Reflection.MethodInfo to) (at <036d18f9edfb4e6d97ce4f777d0e0eb4>:0) MonoMod.RuntimeDetour.Platforms.DetourRuntimeILPlatform..ctor () (at <036d18f9edfb4e6d97ce4f777d0e0eb4>:0) MonoMod.RuntimeDetour.Platforms.DetourRuntimeMonoPlatform..ctor () (at <036d18f9edfb4e6d97ce4f777d0e0eb4>:0) MonoMod.RuntimeDetour.DetourHelper.get_Runtime () (at <036d18f9edfb4e6d97ce4f777d0e0eb4>:0) HarmonyLib.HarmonySharedState.WithState[T] (System.Func`1[TResult] action) (at <036d18f9edfb4e6d97ce4f777d0e0eb4>:0) HarmonyLib.HarmonySharedState.GetPatchInfo (System.Reflection.MethodBase method) (at <036d18f9edfb4e6d97ce4f777d0e0eb4>:0) HarmonyLib.PatchProcessor.Patch () (at <036d18f9edfb4e6d97ce4f777d0e0eb4>:0) HarmonyLib.Harmony.Patch (System.Reflection.MethodBase original, HarmonyLib.HarmonyMethod prefix, HarmonyLib.HarmonyMethod postfix, HarmonyLib.HarmonyMethod transpiler, HarmonyLib.HarmonyMethod finalizer) (at <036d18f9edfb4e6d97ce4f777d0e0eb4>:0) UdonSharpEditor.UdonSharpEditorManager.PatchInspectorTitleIfNeeded () (at ./Packages/com.vrchat.worlds/Integrations/UdonSharp/Editor/UdonSharpEditorManager.cs:833) UdonSharpEditor.UdonSharpEditorManager.OnEditorUpdate () (at ./Packages/com.vrchat.worlds/Integrations/UdonSharp/Editor/UdonSharpEditorManager.cs:785) UnityEditor.EditorApplication.Internal_CallUpdateFunctions () (at /Users/bokken/build/output/unity/unity/Editor/Mono/EditorApplication.cs:381) I understand that Mac may not be a supported platform but it would be really nice for VRChat to implement packages and tools that do also work on Arm processors. Not only could this benefit Mac but also windows and Linux Arm based systems. MacOS Version: Tahoe 26.5.1 Unity Version: 2022.3.22f1 (Arm)

〇 Environment OS: Windows 11 Pro 25H2 Build 26200.8457 Unity: 2022.3.22f1 VRCSDK: 3.10.3 〇 Summary When performing local world tests using Build & Test Your World or Test Your Last Build, launching multiple clients simultaneously may cause the second and subsequent clients to become stuck on a black screen. Launching clients with a delay between each instance can partially mitigate the issue. 〇 Steps to Reproduce Open the VRChat SDK in Unity. Run Build & Test Your World or Test Your Last Build. Launch multiple clients at the same time. The second and subsequent clients may remain stuck on a black screen and fail to proceed. 〇 Additional Reproduction Conditions Based on investigation, this issue appears to be indirectly related to log output. The issue occurs consistently under the following conditions: Disable debug log output for the client. Launch the first client. Launch the second and subsequent clients. The additional clients will consistently become stuck on a black screen. 〇 Possibly Related Issue A potentially related issue, also suspected to be caused by log output, was observed: When two clients are running in a local test and are in the same world, performing a rejoin from one client causes VRChat to crash. After this occurs, VRChat will continue to crash consistently when rejoining the same world, even when running only a single client. This issue can be resolved by deleting the log files in the following directory: %HOMEPATH%\AppData\LocalLow\VRChat\VRChat 〇 Suspected Cause It is likely that a deadlock or similar resource contention involving log files is occurring, causing clients to freeze or crash. 〇 Expected Behavior All clients should launch and enter the world normally when running multi-client local tests. Rejoining a world should not cause crashes regardless of log file state. 〇 Actual Behavior The second and subsequent clients may freeze on a black screen when launched simultaneously. Under certain conditions, rejoining a world causes VRChat to crash persistently until log files are deleted. 〇 Notes This issue significantly impacts local multi-client testing workflows and should be addressed with high priority.