SDK Suddenly Cares About Duplicate GameObject Names
available in future release
Enverex
Historically the SDK didn't care about GameObjects sharing the same names. On much older versions of the SDK you'd get a warning that it may cause issues but it was only a warning and wouldn't cause problems for most worlds. Though it would also offer a "fix" button to auto-rename those duplicated names for you (this no-longer exists).
Something recently seems to have changed and now the SDK is failing to compile the world if any GameObjects (at the same level in the heiarchy) have the same name. What's worse is that this doesn't seem to stop the process of the upload, but does break the build, so the SDK will then upload whatever the last successful build was (in my case, a completely different world from a different scene) breaking the live copy of the world (as it'll upload a broken file, which will fail to load and kick people back to home).
I've seen at least 3 other people complain about this in the Discord in the last few days, so something's changed that has suddenly caused this to become an issue despite no update to the SDK itself.
This form doesn't let me enter 3.5.2 as the SDK version as it wants an Integer only which makes no sense.
Log In
This post was marked as
available in future release
Faxmashine
Hi, Enverex!
> the SDK is failing to compile the world if any GameObjects (at the same level in the heiarchy) have the same name.
Hmm, I'm unable to reproduce this - but we'd like to look into it. Do you have an example of how we can reproduce this issue?
Enverex
Faxmashine No, unfortunately I'm not sure what's triggering it (and the world project in this case is ~100GB).
If I clear the network ID array, it'll build. But then after working on the world again for a bit it'll happen again until I clear the network IDs list again. I'm seeing more people experiencing this now including someone I happened to mention it to the day before I logged this, but again no obvious trigger. I can point others having the same issue to this post though to see if any of them have narrowed down what's causing it.
techanon
Faxmashine I was able to repro part of the issue for at least the network id utility.
1) Scene with VRCWorld, verify the network ids list is 0'd out
2) Create a game object and put a synced udon behaviour on it.
3) Duplicate the object some number of times for good measure.
4) Rename 1 of those duplicated objects to be the same as the first game object's name.
5) Open then Network IDs utility.
6) Regenerate Network IDs.
7) Error starts spitting out.
Anecdotally, I did run into the AssignNetworkIds failure on build (zeroing out the network ids did fix it), but I have not been able to get valid repro steps for it. When I ran into it, the only things that had changed was the addition of new udon behaviours to the scene. I never messed with the network id utility until afterwards.
StormRel
tracked
M E R C
Since it wasnt mentioned in your post, this is typically fixed by using the network ID Utilities in the VRChat menu to regenerate your network IDs.
Enverex
M E R C That unfortunately doesn't really "fix" the issue as it starts to pump out thousands of errors, complaining about every single object with a duplicate name until you manually rename everything, which shouldn't be necessary.
It looks like zeroing the Network IDs array in the VRC World Scene component and NOT using the Network IDs tool may actually be the correct way to fix this.
Fairplex
Enverex I think they are planning to remove that array in the SDK 3.6.0 so not sure if your workaround will be possible after that
Enverex
Fairplex The workaround is far from ideal anyway as I suspect doing that means you need to reupload both PC and Quest to make sure they talk to each other properly and switching like that is a pain as it breaks a lot of shaders (transparency problems, keyword issues, etc which then also all have to be fixed). And it keeps coming back anyway, still not sure what the trigger is though as it doesn't come back immediately.