Unity 2018 now uses the Standard particle shaders by default (e.g. `Particles/Standard Unlit` ), with transparency enabled by default using keyword _ALPHABLEND_ON/queue override. [edit: `Particles/Standard Surface` is also affected] The shader does not specify a renderQueue, so it defaults to Geometry (2000). However, most blend settings require Transparent (3000) render queue. As is widely known but not well documented, be it through a Unity bug or VRChat issue, either the upload or asset bundle load process resets all material renderQueue settings to From Shader. If done to Standard Particle shader, it would cause it to use alpha blending with queue 2000 which looks broken. See attached picture. Just like Standard, it assigns keywords which can be used to detect the intended renderQueue after upload: _ALPHABLEND_ON, _ALPHAPREMULTIPLY_ON and _ALPHAMODULATE_ON use Transparent (3000); _ALPHATEST_ON uses AlphaTest (2450)

Hello folks, I am currently redoing one of my 2017 worlds in Unity 2018.4.13f1 and when I load up my world, the game crashes right after "Initializing World" with only a window popping up which has a red ! on it. I am Using the newest VRCSDK which is available on the VRChat Discord. This happens when I upload it as a private world and when I test it local. The World ID is: wrld_0c13be85-b803-4d4e-9295-523d995175d4 (If you are able to join, don't judge me, its in an early W.I.P state)

Hello, I was testing the build with a few friends earlier and we tried going in a world that contains a few different elements that were supposedly fixed (seats, climbing for example) but whenever we try to join the world in Open Beta (884), the game crashes. Here's the world ID, do note the world has not been reuploaded for 2018 (I'm about to check if building for 2018 fixes that issue) : https://vrchat.com/home/launch?worldId=wrld_3c33d3fc-3e7b-4fc3-944e-bd369ad36fc8 Here is the end of the log upon joining that world: https://pastebin.com/8a8aX6zj Precised "a certain" world in the title post, but clearly this could happen with a lot of other worlds and we just don't know about it yet.

IK follower is not following IK. Objects attached with IK Follower only follow the player animations at the moment. Example avatar with IK follower attached to right hand for world space particles: avtr_0d5f3c34-d1af-48c5-9471-02807fa037c1

https://docs.unity3d.com/Manual/Constraints.html This system seems to be far better suited to perform a lot of task previously accomplished with other comments, while providing additional options for avatar creators Allows limb copying without fixed joints (allowing avatars with multiple arms or legs) Allows using world particles in situations that IKFollower doesn’t allow (Attach to non-IK-following bone) that previously required fixed joints I believe these allow you to Animate holstering / unholstering weapons without needing to duplicate the mesh (IIRC, FinalIK supported this) Aim/LookAt constraints can be used to replicate hydraulics pistons or other mechanical joints for robotic avatars (previously this could be achieved with dynamic bones any maybe FinalIK) These components likely can be used to achieve other effects. These components hopefully won’t have the disadvantages of the systems they replace, such as; IKFollower: only allowed on IK-following bones (As per documentation) Rigid Bodies: Known to break in Combat enabled worlds (https://vrchat.canny.io/bug-reports/p/avatar-rigid-bodies-break-in-combat-enabled-worlds) Rigid Bodies: Some configurations of joints can drift out of place over time or during teleports.

Sorry, I know there are already enough canny as is. This was in the "New Years 2020 Test Totally" world

Not sure if this is noted anywhere else or known of, but if you have a VRC_AudioBank on any gameobject inside your project, you cannot then add (+) actions to any VRC_Trigger.

If you have an object sync that is disabled at start, the object will not sync for remote players. Objects enabled at start, but later disabled will still sync after being enabled again. Example world: wrld_12728c32-3675-4796-8a7c-a36c8ddddc1d The green sphere is always enabled. The red sphere is disabled at start and enabled with OnNetworkReady. The green sphere syncs but the red sphere does not.

When joining a world, you see some other players appear right next to you when they might be far away. After seeing them, my reaction is to look around spawn for my friend or assume they are nearby but they might be across the map.... I also might start talking to them, so it is quite confusing. I am unsure if it is origin or spawn. In some worlds they are the same so it's hard to tell. If it's world origin, the bug might not be apparent in all worlds. Steps to reproduce: 1. Launch one client into https://www.vrchat.com/home/launch?worldId=wrld_98dee37e-e0a2-4b4a-a545-7a8c96f9feb8 -- Use a normal size avatar. 2. Walk forward from spawn. 3. Launch another client into the same instance. 4. repeat a few times if you miss it. To reproduce exactly my test, I used the shorter default avatar with the yellow hat (the angle might matter) What to observe: The client that joins later will see nobody else in the instance, then after a second, the other player will appear clipping inside, and then teleport far away. What I expect: Ideally, the other client will not be visible until we know their position and have set their initial IK.

World ID: https://www.vrchat.com/home/world/wrld_bc1cb1f8-a6ef-4957-bd1d-a5775034245a These sliders are synced using Animation Sync, but instead of being set directly, the output cube colors are actually being set using an OnDataStorageChanged trigger There's some glitch where the first time you use a slider the colors will be wrong. To test properly, have each client click on each slider once, and then start testing that they should always match (with 1 second delay due to OnDataStorageChanged rate limit) On Beta, the cube color will usually not match between both clients (except the first time you join the world)