GetComponent<CinemachineVirtualCamera>().GetCinemachineComponent<CinemachinePOV>().enabled = false;
GetComponent<CinemachineVirtualCamera>().ForceCameraPosition(positionNearFollowCamOrbit, spaceVCAM.transform.rotation);
= aim turns to
should be
aim remains to POV
until this is fixed, i need to deactivate POV, how do i do that without it breaking?
Does it actually go away, or is it just wrong UX?
You can check by trying to enable it again. If that works, then it’s still there.
POV is gone and nullrefs the bit of code that disabled it
CM Doesn’t support enabling subcomponents this way.
The correct way would be to have 2 vcams: one with POV and one without. Activate the one that’s needed.
Which means extra scaffolding.
It shouldn’t auto clean components. That’s very un-Unity like.
Any other way to turn off user input on POV?
We agree. Cinemachine 3.0 (to be pre-released in November) addresses this and many other such legacy issues.
Looking forward to it. Any eta for the preview version?
November. But the minimum Unity version for it will be 2022.2.
Ouch.
2022.2 broke a few vital things and no sign of fixing them, any chance you lower the barrier of entry?
No, unfortunately. Don’t worry, we will continue to support CM2, so you won’t have to upgrade Unity if you don’t want to.
what’s the feature of 2022 you use in 3.0 that’s not in 2021?w
A few of them. A big one is Unity Splines.
Spline to define camera position search space?
Instead of CM’s custom spline implementation for camera paths, we are using the new Unity Splines.
Then why not just add a few conditional compile to support older builds. That’s what so many single devs making assets on the store sweat to do so I’m sure your team can manage.
There are limits to how much we’re willing to complexify the code. Sometimes it’s better to make a clean break. There is already a lot of conditional compilation in CM, supporting Unity all the way back to 5.x. No one is forcing you to move to CM3; you are welcome to stay on 2.X if you’re not comfortable upgrading Unity.