Creator Companion

Due to concerns about leaks, many creators have transitioned to using uploads only, often utilizing third-party software or systems. The VCC should include an option that ensures safety for both creators and users who need to upload content, such as those without a PC or those with low-end PCs that cannot handle uploads. I propose that the VCC front page or VRChat website incorporate an uploading system where users can provide or receive codes to enable creators using the VCC to upload purchased content directly to the user's account. Additionally, it would be beneficial to add a feature that disables the ability to change uploaded models from private to public. This would prevent users from violating the creator's terms of service by setting the model to public after upload.

I just spent ages wondering why I was struggling so much with packages not being installed when I expected them to be while jumping backwards and forwards in my git history... plus, when installing new packages, I had to manually forward them to my teammate to install manually as well, unlike everything else that we were able to sync over git. I'm not sure if the .gitignore file in the Packages folder is an accidental oversight, or if it was intended for some reason; I could understand it keeping the vrchat library files off of git, but it absolutely shouldn't be keeping the evidence of their inclusion off of a repo too! I'd be happy with getting rid of that .gitignore entirely (that's what I did locally, and I haven't had any trouble), but at the very least there needs to be an exception for the various manifest json files.

In the VCC, it would be great to have folders for projects. I often do commission work, but I also livestream or will share my screen to other people. Being able to put commission work into a separate section/folder to hide it would be incredibly useful. But also in general, being able to just organize projects through folders (or even tags I guess) would be useful too.

I have two gitlab links, one returns a content-disposition header whereas the other does not. The one without content-disposition fails to be properly imported via VCC, even though the NUKE build reads it properly and it is correctly listed as a selectable version in the dropdown. With: https://gitlab.com/techanon/protv/-/releases/v3.0.0-beta.18/downloads/package Without: https://gitlab.com/techanon/protv/-/releases/v3.0.0-beta.20/downloads/package With a curl -I command, you will notice these are redirects. I post the original link as it is relevant to my repro. Redirect target with content-disposition: https://gitlab.com/techanon/protv/uploads/e0b1df0c8c7c162de876489f75ebd199/ArchiTech.ProTV_v3.0.0-beta.18.zip Redirect target without content-disposition: https://gitlab.com/api/v4/projects/27741679/packages/generic/ArchiTech.ProTV/v3.0.0-beta.20/ArchiTech.ProTV_v3.0.0-beta.20.zip The working package link was published using gitlab's file upload API (typically used for uploading files for a changelog or release info). The other was uploaded to the gitlab package storage. I recently switched from the upload API to the package storage due to some recent instabilities with gitlab's upload API returning 404, so I had to find a solution and landed on the package api. For full context here are the CI scripts used for each: upload api: https://gitlab.com/techanon/protv/-/blob/v3.0.0-beta.18/.gitlab-ci.yml package api: https://gitlab.com/techanon/protv/-/blob/v3.0.0-beta.20/.gitlab-ci.yml My observation of the failure is that because there is no content-disposition defining the filename on the redirect, VCC implicitly uses the end of the file path for the initial URL as the file name when downloading it into the file cache. I confirmed this when checking the %APPDATA%\Local\VRChatCreatorCompanion\Repos\dev.architech.protv folder and the newer version was downloaded as just package . So when VCC tried to read the downloaded file, it failed for whatever internal reason. I updated the source.json for the listing with the redirect target url, the one with the file name at the end, and that allowed VCC to pull in the release correctly. I think if a content-disposition is not provided, VCC should look through the possible redirect stack to find a path that ends in a .zip name. Or maybe to keep things simple, if no content-disposition is available, implicitly download the file as {package.displayName}_v{package.version}.zip instead of the ending path segment name.

I just tried to install the Creator Companion on Linux via Wine, to see if it'll work going forward next year. While I'm able to install it, once started it is unable to find the Unity editor; which makes sense as Unity is installed natively instead of the Windows version in the Wine prefix (which wouldn't run). Additionally, none of the UI elements in the Creator Companion are clickable. Considering that effort has been put into making sure that VRChat runs on Proton, thus on Linux, would it be possible to have the Creator Companion be ported for Linux, so we won't get excluded from content creation once manual SDK downloads stop being shipped via the website?

VRAM is going to become a very important metric in the near future for avatar/world optimization. Among other tools, this tool includes a handy VRAM calculator that assesses your performance hit from your textures. Including this as a curated package in the VCC will speed up the optimization process by giving creators one click access to the tool.

In general it's not good practice to install software while the license is uncertain. So I want view license document of a package before installing it on VCC, especially in case of Community Packages. Also, it will be good if I can reconfirm after installing. For comparison, Unity Package Manager shows URL in Links section on details view. https://docs.unity3d.com/2019.4/Documentation/Manual/upm-ui-details.html

Would be nice to see n update all button for the package updates

Even though there is a proper place to download the VCC installer, it doesn't guarantee that it's not getting intercepted, or worse, compromised as in hacked. A user will not be able to tell if the download was tampered with, if they cannot verify the certificate anywhere.

With VCC you should be able to pick for PC or Quest when making a new project so you don't need to import everything first, wait for it all to load, convert over to Quest and wait for that all to load too. I'd be great for projects that just jump right into Quest.