Closed NorthTen closed 3 months ago
Due to the existence of dependency packages and the support burden due to users installing incompatible mixtures of package versions, I do not intend to enable unitypackage builds again.
Consider using ALCOM if you don’t want to use VRChat’s VCC: https://github.com/vrc-get/vrc-get
I’ll note that there are ways to use MA without VCC. However there are enough ways for this to go wrong and result in hard to debug problems that I don’t want to make this an obvious or easy option. If you know enough to fix your environment if things go wrong you know how to do this already.
Oh? I'm not sure if I understand this correctly
Due to the existence of dependency packages and the support burden due to users installing incompatible mixtures of package versions, I do not intend to enable unitypackage builds again.
Because I've already got a project setup with the VRChat SDK installed via the unitypackage
, and VRCFury with the unitypackage
, they both work enough to my extent of knowledge and usage, and if users install "incompatible mixture of package versions" apologies for my broad and maybe ignorant statement, but however why don't you have some init code that prevents people from installing if there's already a old pre-existing installation of MA?
I’ll note that there are ways to use MA without VCC. However there are enough ways for this to go wrong and result in hard to debug problems that I don’t want to make this an obvious or easy option. If you know enough to fix your environment if things go wrong you know how to do this already.
You don't have to answer this but what could go wrong exactly? You can also link to a source. Did a quick search and there was nothing major that I have found where unitypackages
could lead to serious issues other than generic import issues due to some enabled setting.
Consider using ALCOM if you don’t want to use VRChat’s VCC: https://github.com/vrc-get/vrc-get
Though, why do I need to install a package manager tool, to install your package, when I could install it manually via the unitypackage
that you provide.
I've already downloaded the .zip
from your release, so I'll try importing the .prefab
, maybe this'll help people, haven't tested this yet.
Because I've already got a project setup with the VRChat SDK installed via the unitypackage, and VRCFury with the unitypackage, they both work enough to my extent of knowledge and usage, and if users install "incompatible mixture of package versions" apologies for my broad and maybe ignorant statement, but however why don't you have some init code that prevents people from installing if there's already a old pre-existing installation of MA?
MA requires specific versions of NDMF (and in the future, NDMF-RQ or NDMF-CORE or whatever I end up calling the portion that'll work with world projects too). I'm concerned that offering unitypackage downloads easily to users who don't know how to read and resolve console errors will result in confusion, frustration, and inappropriate error reports. As such, I don't want to make this easy.
You're free to manually install the releases, of course, which isn't much different from the unitypackage. Actually, it works better, because unitypackage installations can't delete obsolete files. But I don't want people thinking this is a supported way of doing things - it's not, and you need to be knowledgable enough to fix things yourself when they break.
(if there's a specific reason you're unable to use a package resolver, I'd be interested in hearing it, however)
I'm just on Linux. VRChat doesn't support Linux natively, despite VCC being a package resolver for Unity, it should've been compiled as a command-line application to begin with, and built on Linux, but it wasn't. Of course this is user preference, but would VRChat get any better anytime soon, functionality wise and performance wise?
So far, I am able to use Unity just fine, and import unitypackage
's, of course I already have a package manager apk
, and I am already knowledgeable about how to import unitypackage
's, so there's really no point in me using VCC, especially since there's no need for a tool like that to begin with, if you can already import packages natively with Unity..
I also shouldn't really be having issues with any plugins/packages since I can create a new project for handling an avatar at a time, and use what I need. (maybe this info may help someone in the future)
Appreciate letting me know of why though.
ALCOM should be usable on Linux, so I'd recommend using that going forward.
I ended up finding out about OpenUPM.
I moved your package from the .zip into my assets, extracted of course, and it kept giving me compilation errors, I installed ndmf
or whatever via OpenUPM, and it still gave me compilation errors, although I now was able to search for MA scripts.
To be specific, it's ndmf
throwing an error, not MA yet, I now have MA installed via OpenUPM because I thought MA was giving me issues, looked at the console turned out it was ndmf
.
Exception: Failed to persist asset container
nadena.dev.ndmf.BuildContext..ctor (UnityEngine.GameObject obj, System.String assetRootPath, System.Boolean isClone) (at ./Library/PackageCache/nadena.dev.ndmf@1.4.1/Editor/API/BuildContext.cs:167)
nadena.dev.ndmf.VRChat.BuildFrameworkPreprocessHook.OnPreprocessAvatar (UnityEngine.GameObject avatarGameObject) (at ./Library/PackageCache/nadena.dev.ndmf@1.4.1/Editor/VRChat/BuildFrameworkPreprocessHook.cs:41)
UnityEngine.Debug:LogException(Exception)
nadena.dev.ndmf.VRChat.BuildFrameworkPreprocessHook:OnPreprocessAvatar(GameObject) (at ./Library/PackageCache/nadena.dev.ndmf@1.4.1/Editor/VRChat/BuildFrameworkPreprocessHook.cs:48)
VRC.SDKBase.Editor.BuildPipeline.VRCBuildPipelineCallbacks:OnPreprocessAvatar(GameObject)
VRC.SDK3.Builder.VRCAvatarBuilder:ExportCurrentAvatarResource(Object, Boolean, Boolean, String&, Action`1, Action`1)
VRC.SDK3.Builder.VRCAvatarBuilder:ExportAvatarBlueprint(GameObject)
VRC.SDK3A.Editor.<Build>d__106:MoveNext() (at ./Packages/com.vrchat.avatars/Editor/VRCSDK/SDK3A/VRCSdkControlPanelAvatarBuilder.cs:2121)
UnityEngine.UnitySynchronizationContext:ExecuteTasks() (at /home/bokken/build/output/unity/unity/Runtime/Export/Scripting/UnitySynchronizationContext.cs:107)
This is happening on Unity ver: 2022.3.6f1
.
EDIT: Should note that I utilized OpenUPM via Unity's native package manager. Instructions is listed on OpenUPM's manual installation instructions for any package(s).
I don’t provide support for and have not tested installing via OpenVPM. Please feel free to reach out to whoever added it there to see if they can help.
(Note that MA on OpenUPM is not registered by bdunderscore, so it's unofficial distribution. bdunderscore did not even know it had been registered on OpenUPM until recently.)
Ensure compatibility for users who do not use VCC by re-enabling support for UnityPackages caused by commit chore: disable unity package generation.