So basically, I think this repository hasn't received much attention and I think it's time we do something about it. For starters, everything has been reorganized to comply with UPM Guidelines.

There are also some extremely important changes to note as well. Please take a look at what I did. This is my mega proposal to reorganize the Repository and ensure it maintains a clean guideline for years to come, even though VRCBCE2 is being worked on.

I also have a proposal to get a VPM Community Repository of VRCBCE out there sooner than later since v1.5.1 is now too old and is starting to slowly break apart with the latest SDKs rolling out too quickly.

List of Changes

All files have been reorganized to comply with UPM Guidelines and ensure things remain clean. For starters, no more .gitignore needed as all files from the Packages/com.vrcbilliards.vrcbce folder have been moved to the root directory. This will make it easier for future Contributors without having to deal with other directories that are in the same folder as Packages (personally, I think these changes are better). I've already made a release.yml with the proper parameters to ensure it works.
Everything (except for Samples) has been sorted into Runtime folder.
Assembly Definitions and U# Definitions have been re-evaluated for the better, including the removal of unnecessary duplicates.
ALL MAIN PREFABS are now in a new sub-folder called Prefabs in the root directory. It just looks better compared to having to look at a messy folder with a shit-ton of other files surrounding them, since I've noticed the number of different variants now growing.
Removed Filamented Shader from the Repo. The reason I did this is because it heavily conflicts and breaks projects that already have Filamented included and that the version that existed in this Repo is much older. To add to this, Silent plans to make Filamented it's own separate VPM Repository at some point. So this change needed to be made.
Updated package.json to add s-ilent.filamented as a VPM Dependency, ready for when it gets published as a VPM Repository. When it happens, you'll need to add Filamented to your Repository's source.json. The VCC will always tell the difference between the two if both separate Repos are added at the same time in VCC, as long as the name s-ilent.filamented does not change.
Updated package.json to make VCC remove the Assets\\VRCBilliardsCE folder if added to your Project. This is the safety measure to prevent conflicts and breaking U# Scripts.

Because the files have been reorganized, you will be required to update your GitHub Pipeline Workflow to accommodate this change when building releases! I already included a release.yml Workflow into my Repository since I was testing it, but feel free to use it as a reference for your own Workflows.

I understand that these changes I'm proposing is a lot for you to take in and may change the way you work with the Prefab. But I personally think this is for the better. So I really appreciate any comments and feedback from all VRCBCE Contributors about this proposal. Thank you very much!

Hey! Thank you so much for contributing your time for this; I know firsthand how tricky it can be to put a lot of thought and attention into each element that would consitute a "mega-PR" which are often inherently ill-advised! I super appreciate you puttin' this out there.

That being said... they're unfortunately inherently ill-advised for a reason, and I definitely can't merge this without- well- either enormous reverts or breaking it up into several PRs after refinement.

Before I get into the like- weeds of any specific feedback- I should probably explain a quick bit of my thoughts on the psychology of the Project (asset browsing) window. There's oftentimes this concept in UI/UX design of a tradeoff between click count (ease of control) and visual noise; where laying a bunch of settings out in the open makes it take fewer clicks to do the things you want at the expense of obviously heightened visual noise and vice versa. Balancing these is often ideal, but there are many times a designer can/will exploit the specific context of the average expected user ability or state of the environment to lean harder into one side or the other, to increase the benefits of one while the other is more minimally detrimental than normal. I say all this because the Unity Project window is designed to often have a grid containing many individual entries at any given time, and users tend to be used to this. In addition, there are a number of views (like on the left-hand side- or when you're in one-column layout mode) where navigation of folders is done through hierarchy trees which directly benefit from fewer folders and nesting. Ultimately- this means we've been able to get away with having a more "visually noisy" set of folders/assets to gain the benefits of requiring fewer user clicks to find things without much of the detriment that often comes with increasing the visual noise of a particular section on average. I've done my own balancing on this in the past, and what we have currently is a pretty tried-'n-tested solution with almost zero public criticism from creators.

I'm pretty tired at the moment and have only taken a cursory glance at your fork's layout, so I'm going to be basing my feedback on this off of your summary; apologies if I misunderstand something or don't provide complete depth with each note 🥴

I am not personally familiar with "UPM Guidelines" so I don't know what idiosyncrasies you specifically targeted to improve/change with your layout... but it definitely doesn't immediately read to me like something substantial aside from the removal of a parent folder being at the base of the repo (which is something I am okay with if it means we can be rid of the .gitignore, even if it pushes the README down further on the github main page; it ain't much scrolling) You should totally isolate that change alone into its own PR with no other tweaks, I'd merge that!!
Gonna be honest: Runtime is kind of a garbage name for "folder with all of the assets and components that individually make up the prefab". Something like Assets or similar would be much more preferable- if we were to consolidate those folders into another merged sub-folder. (which is an extra click, something I'd prefer to avoid)
I'm not super sure what this means since I don't personally work with asmdef stuff outside of occasionally fixing bugs related to them; but I'll take your word that they're better! This change could likely be merged.
I am hard veto-ing this one. Flat no. The entire point of having the actual mainline prefabs in the root of the project ('s packages) folder was to wholly expedite the process 99% of creators using the prefab were employing, which was picking a prefab to use and dragging and dropping it directly into the scene. Keeping the mainline prefabs where they are (as the very first things you see when checking out the folder) is literally the simplest possible implementation for this and you'd need a damn good reason to justify moving them into a seperate folder (that you'd have to read the name for)
Filamented breaking existing implementations should be fixed as of commit https://github.com/VRCBilliards/vrcbce/commit/57f101e64cab12d0f390bd20390b1418d949ef11, but the big issue I largely have with this is the lack of availability as it stands. I 100% want to move to including it by reference as a dependency to ease off the burden on this repo (read the commit change notes!), but was planning on doing this post-release with a simple patch quickly released after Silent goes ahead and does it (or if before 1.6- which I'm planning on finalizing in a month- then I'd ship 1.6 after it's already solidified). In either case, I don't want to make this change prehumously.
Assuming the naming convention will follow that- this is a good change and could definitely be merged.
Super good change, 100% would merge. (I'd love to have done this myself already but am not super familiar with VCC practices yet, haven't had the time/energy to throw at it extensively and my testing of it pre-release was more in the application itself and its stability rather than setting up/maintaining packages.

Regarding the last bit, I don't think we utilize a CI/CD pipeline? At least- I don't; not sure whether Panda internally has some setup on her end for her own rewrite fork. So it shouldn't be much of a bother since... I don't really know it'd be a bother in the first place!

And again- I'd be more than happy to merge the individual changes I noted were fine for merging, but the rest is too substantial/misses the forest for the trees for me to be comfortable pivoting the basis of the prefab that tens of thousands of creators have in their projects.

VRCBilliards / vrcbce

Cleanup and reorganization for the near-future. Fully ready VPM Community Repository support. #183

List of Changes