SDK Bug & Feature Requests

Please check out the following rules and use the provided template when posting a bug report! Off-topic posts will be deleted.http://bit.ly/vrchat-bug-reports
[1854] In local world testing, launching multiple clients causes the second and subsequent clients to freeze on a black screen
〇 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.
2
·
Bug Report
·
tracked
The Content Manager tab in SDK has a footgun - "Make public" has no confirmation prompt and is located next to "Copy ID" (anti-UX)
The Content Manager tab in the SDK has "Make public" and "Copy ID" right next to each other. This is a footgun with plausible legal or contractual consequences of shooting one self in the foot, including plausible suspensions from VRChat. "It's too likely to accidentally make avatars public." Upload a private avatar. For this fictional example, you may be awarded additional thoughtful rewards if the avatar includes controversial topics, sensitive, intimate, or provocative material, or extreme horror or “shock” content permissible in private, or licensed content permitted on a private avatar but not to be made available to the public due to copyright. Go to the Content Manager tab. Find small "Make public" and "Copy ID" look-alike buttons next to each other. Get into the mindset of wanting to press "Copy ID", but not the "Make public" button. Optionally, press the "Make public" button and see an avatar being made public immediately without a prompt. Then rethink the consequences of the action you've just made - or pretend you didn't notice this action being taken for this example. The safety was off and the footgun may have been loaded. This is a rephrased duplicate of a Feature Requests board topic: https://feedback.vrchat.com/feature-requests/p/confirm-button-when-making-avatars-public-to-avoid-accidental-ban OP had accidentally shot themselves in the foot by pressing "Make public" instead of "Copy ID", which doesn't have a confirmation prompt when pressed and went unnoticed. OP was aclaimedly banned from VRChat for a week for this. In comparison, the "Delete" button has a confirmation prompt. The legal consequences of accidentally making an avatar public are common with BOOTH style avatars, which allow avatars to be uploaded with Private status only. An avatar set to Public status would often be a license violation and may be subject to a DMCA takedown notice. The contractual consequences of accidentally making an avatar public may result in conflict with VRChat's Creator Guidelines and subsequent suspensions, if the avatar content intended for private but accidentally made public has controversial topics, sensitive, intimate, or provocative material, or extreme horror or “shock” content, which is not permissible for public content. According to avtrDB 's reported statistics, there are 1,567,380 public searchable avatars, and 4,003,344 private avatars (avatars that have never been made public). The number of private avatars seems to significantly outweigh the number of avatars intended for the public. It's often plausible to copy an existing avatar ID from the Pipeline Manager component attached to the avatar root gameobject, but there are cases where that may not be plausible, requiring a click of Copy ID or a visit to the VRChat Home website to acquire an existing avatar ID. When using the VRChat Home website, the avatar ID is in the URL and nowhere near the "Make Avatar Public" button. In the Content Manager, these buttons are close to each other. For reasons stated before, I think this UI/UX design is unintended or anti-UX and should be considered an UI/UX bug. Expected behavior: Larger buttons, prompts to confirm to make public, change the colors of the buttons, or simply don't place these buttons close to each other or on this Content Manager tab. Anything to remove the footgun, the anti-UX, and the severe consequences of accidentally and potentially shooting yourself in the foot. Actual behavior: "Make public" is a small button that can be misclicked (especially in SteamVR with a laser pointer from controllers) and doesn't have a prompt, with plausible legal consequences or unintended violations of Creator Guidelines, when an intent may have been to "Copy ID" instead. SDK 3.10.3 Reported-by: Ƙiri
2
·
Bug Report
Load More