Better support for a network drive cache disk
SherbDrgn
Moving the cache itself is annoying due to having to edit a file and not having a UI element or launch option to change it easier. But moving it to a network drive has strange quirks with it I have found out.
I have a metered internet connection so I want to keep as much as I can in the cache as possible so I don’t go over my internet limits or just have to stop playing for the rest of the month so I don’t get fined. Me and my roommate both play VRChat and I got the weird idea of having a shared cache disk on a network drive that both clients can share from and shockingly it works pretty well. Doing this saved us ALOT of data like 100s of GBs a month. The cache ended up getting to like 500 gb before issues started to pop up that ended up in the entire cache getting broken.
Losing connection to the drive itself for a moment seems to cause the database get corrupted, making the entire cache just junk data that has to be removed and redownloaded over time again. Another problem arises when both of us are in the same instance as 1 person will download faster than the other and that person will see the avatar loaded fine, where the other person will stop downloading and the avatar will be displayed as an error until they hide and show the avatar.
Having a UI for changing the drive in game and adding the ability to point it to an internal network IP would make this a lot easier for users to set up such a system. The ability to change the settings for a cache would be nice as well such as specifying to dump something if a newer version is uploaded; as well as turn off the “janitorial duties” of a client so you can allow just one persons client to be responsible for the wiping and maintaining the file size of the cache, possibly making this the default option when connecting to a network drive so someone does not join it and accidentally wipe the cache from 500 gb to the default 20GB.
Log In
zexc
This issue has shown up multiple times for me, so i wrote out possible issues vs solutions to be implemented.
The issue 2tb/month Data cap
Multiple users in one household playing vrchat on a limited network.
Vrchat currently will download same data multiple times to multiple users on same network.
The solution is to use shared network drive and have all user share the same cache.
The next issue
This turns out to be a hassle. Why? Because vrchat doesn't know the file being downloaded from User 2
is already being downloaded. So when it loads the unfinished download it turns into an error model.
The file is also still being downloaded nearly 3 times which is harsh to data capped users
The (possible) solution
Better handling of cache + Unfinished Cache detection
Easier way to handle config settings is needed especially for these situations. Setting a separate drive for cache should not be editing a config file in a folder in app data you likely never new it existed.
To go with this settings to change cache size and expiry is needed too. Cache version clearing would also help. Users will never load older version of avis and worlds. So why keep old versions?
A solution now for User 1 and 3 needs to be handled. We don't want to download the same data or attempt to load unfinished data in cache.
So lets detect that,
Have client share a local network port to communicate current cache downloading behavior. Hash of this cache item is currently being downloaded by User 2 therefor User 1 and 3 will not download it or share the ui of it downloading while actually waiting for cache.
Or have client detect when another user is writing this model to cache and rather attempt to load unfinished data wait for it to be finished and wait for the caching to be finished.
HOBaRT
Ultimately VRChat would likely need to implement some standalone caching server middleman thing rather than just a drive for it to work between multiple clients without things colliding. I'm honestly surprised a shared FS-based cache even worked for you as well as it did.
Salbug
This is a very specific edge case use you have here but interesting nonetheless. Although not entirely sure how likely it'll be looked at considering seems very specific especially considering your setup and also, adding additional UI elements that most likely may not see much use at all may lead to unnecessary bloat.