[VRC Constraints] Disable automatic conversion by default
closed
logi_9
In the ongoing open beta test, the automatic conversion from Unity Constraint to VRC Constraint is enabled by default.
However, as you can see from the Open Beta Board, there are still many assets that break due to behavioral differences when converting automatically. (e.g., VirtualLens2 by me and Camera Path by DX.)
As an asset developer, I intend to provide updates that support VRC Constraint as soon as possible, but reflecting these updates will require users to re-upload their avatars. Therefore, it will take some time for the updated versions to become widespread.
Could you please keep the automatic conversion disabled by default until sufficient compatibility can be ensured or until some time has passed?
Log In
Sayamame
I thought VRChat MUST NOT go live this beta without fixing or closing ALL THE PROBLEMS reported in canny related Constraint because of force replacement of constraints, but unfortunately it is already released. There are still cannys and even Tracked ones. (It's okay if there are cannys which are Needs More Information status.)
DB to PB with partially no compatibility was not bad because they are similar but different things.
However, VRCConstraint is not. VRCConstraint should be superset of UnityConstraint…right? So it must have full compatibility with Unity one… except for bugged behavior causing performance impact (I don't know there are such behavior)
_
_tau_
closed
There are technical and design reasons for not allowing this to be a toggle. We hear the feedback, but our way to address it is and has been to fix any incompatibilities as they arise. We will not add a toggle for this, and the automatic constraint conversion will ship to live in the state it ends up in. If you find an avatar or prefab that breaks under auto-conversion, please open a new canny about it, and include an avatar ID. Thanks!
anatawa12
_tau_ There are multiple Canny about behavior difference between VRCConstraints and Unity Constraints.
And today open beta is marked as Release Candidate but some issues (with test avatar id) still broke our avatar.
I strongly think auto conversion should be opt-in unless known issues in known in beta are fixed, or keep VRCConstraints in Open Beta Channel.
How do you think?
One of mine is still broken because of auto conversion (and reported about 2w ago by other user).
Tupper - VRChat Head of Community
anatawa12: We'll be glad to continue to iterate and fix issues and bugs as they come up, so please keep reporting them!
We're continuing to keep track of bug reports and feedback regarding their behavior, and future releases will contain fixes and improvements as we develop them.
However, we are firm set in replacing Unity Constraints upon release as the default experience, recognizing that some older setups will not function properly at that point.
We hope that we can address those issues either by fixing bugs and addressing feedback, or by encouraging users to re-upload with VRCConstraint setups.
anatawa12
Tupper - VRChat Head of Community
> We'll be glad to continue to iterate and fix issues and bugs as they come up, so please keep reporting them!
I'm mainly about already reported problems.
It can't be helped that breaking un-Open-Beta-tested gimmicks.
(it's better to fix in the future release, of cource, though)
> However, we are firm set in replacing Unity Constraints upon release as the default experience
If so, could you consider put off releasing VRCConstraints until fixing known problems?
I think it's bad to break very popular gimmick since it is hard to update gimmick all uploaded (well-used) avatars uploaded by many people.
Tupper - VRChat Head of Community
anatawa12: We do not plan on delaying the release of VRCConstraints.
If the problems are reported and marked as Tracked, we are looking at them and plan on addressing them. Those fixes will come with future updates.
We understand that big changes like this will break some older content, and that is unfortunately the cost of user-generated content at times. We do our best to mitigate these problems via feedback, bug reports, and iteration.
anatawa12
Tupper - VRChat Head of Community I understand you won't change release date. However, I hope VRChat to keep it in mind that this breakage require this very weird and complex release for user generated content (gimmick and installer tool).
Hackebein
i think this should stay as it is. You are on a beta branch for testing. This is the setting it would have when it get released. Please let it stay enabled.
Tony_Lewis
Hackebein
+1 to that.
If issue got reported with detailed info, it will fixed before release + you can toggle off easily by go back to live if you want.
Point of open beta be fix before release with bugs/issue before pushed to live, this idea is not what open beta meant for.
meronmks ／ めろん
Hackebein
I understand that this is the correct setup for an open beta and that it is difficult to make it difficult to find bugs.
But that is only if past open betas have discovered the name of “making it difficult to find bugs”.
We have seen VRChat go through open beta and then for some reason become a live version with additional features that were not in the open beta.
The person who sent this feedback and the people who upheld (included me) doubt whether “Open Beta” can be trusted.
Translated with DeepL.com (free version)
== Original Japanese text ==
It's the correct setting for open beta, and it's understandable that it's necessary to make bugs easier to find.
However, this is a story about how past open betas were kept under the pretext of “making it easier to find bugs.”
After the open beta was implemented in VRChat, it can be seen that for some reason, features that were not in the open beta were added and made into the live version.
I doubt if I can trust the person who sent this feedback or the people who did the vote (myself included).
logi_9
Hackebein It should be acceptable for automatic conversion to be enabled during the open beta to identify and fix defects. I have no objection to that point.
Unfortunately, since the detailed behavior of Unity Constraints is not explicitly documented, achieving full compatibility might be challenging. This post discusses the concerns if the merge to the live branch is done while leaving compatibility issues unresolved due to such factors.
If there are doubts about the feasibility of the ideal plan, a realistic second option should be considered, and the discussion about it should be done before the live release.