Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] VCC ignores & restores changes to settings.json. #111

Open
anatawa12 opened this issue Mar 9, 2023 · 4 comments
Open

[BUG] VCC ignores & restores changes to settings.json. #111

anatawa12 opened this issue Mar 9, 2023 · 4 comments
Labels
enhancement New feature or request

Comments

@anatawa12
Copy link
Contributor

anatawa12 commented Mar 9, 2023

Describe the bug
If I modified settings.json while VCC is launched, the modification may be restored.

To Reproduce
Steps to reproduce the behavior:

  1. Open VCC
  2. Edit settings.json
  3. Create new project on VCC
  4. See settings.json

Expected behavior
Modification to settings.json on step 2 is not reverted on step 4.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

  • OS: windows
  • Version 10.0.22621 N/A Build 22621

Additional context
Add any other context about the problem here.

@momo-the-monster
Copy link
Contributor

The settings file is written to and read from regularly while the app is open, you need to make changes while the app is closed.

@anatawa12
Copy link
Contributor Author

anatawa12 commented Mar 10, 2023

I think VCC should check if modified using modified time or else before updating config because VCC is GUI app might be launched for long time. VRChat provides VCC CLI so I think this is a bug.

@anatawa12
Copy link
Contributor Author

if settings.json is configuration only for VCC, the current behavior is reasonable enough and I would never send bug report. However, it's not so I believe this is a bug.

settings.json is a config file for VRChat Package Manager, not only for VRChat Creator Companion, right?
So, the VCC must consider settings.json can be modified from other VRChat Package Manager clients, such as VPM CLI.

(This is race condition problem so It's hard to prevent perfectly but current behavior is too easy to make it happens so this should be fixed, in my opinion)

If you don't want to consider that, VCC should lock settings.json while the VCC is launching to avoid external modification, I think.

@Sayamame-beans
Copy link

Certainly, now that VCC can handle user repositories, there is less opportunity for the regular user to use the VPM CLI.
(Users familiar with the command line interface may still prefer to use VPM CLI in conjunction with VCC (GUI), so they may still encounter this bug.)
However, this bug can also be triggered by other opportunities.

Here is one example.
BOOTH (a market platform teamed up with VRChat) is where many Japanese VRChatters commonly look for assets and tools.
Since GitHub and other websites with many VPM repositories are not often browsed, asset/tool authors have a great incentive to distribute their unitypackage on Booth even if they use VPM.
A powerful tool to tie such a BOOTH and VPM system together is VPAI

The VPAI unitypackage allows you to specify assets distributed in VPM format when creating a unitypackage, and download and install them into your project when you import it. You can also specify the version as a wildcard (so you can create a unitypackage that always installs the latest version).

The great advantage of this method compared to the usual VPM unitypackage is that it add repo information to settings.json at the time of import, so that any package once imported with VPAI unitypackage can be managed and installed in all projects from VCC.

However, users basically leave VCC (GUI) open when they work with Unity. (This is natural, since Unity is launched from VCC.)
If the VPAI unitypackage is imported in that state, the settings.json updated by VPAI will be rolled back by this bug when VCC is closed.

This is a major detriment to the benefits of VPAI.
Like this, this bug can still be a serious problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants