Question Running One Command Followed by Another

Basic question here, I'm trying to make a script to control the pitch of a player camera. I have a camera parented to an empty gameobject that serves as the pivot (or 'gimbal') for the camera. The gimbal, in turn, is parented to the player mesh. Whether this is the best approach I don't know, but I can then position the gimbal to wherever I like in relation to player mesh. I use scripts attached to the player mesh to control the movement of the player and scripts attached to the camera gimbal to move the camera rotationally and independently from the player mesh. There's a script for the camera gimbal that controls the pitch of the camera, while the yaw is dictated by the parent, as in the player mesh. I want to be able to toggle so that the camera gimbal will look at another gameobject independently of the mesh (on all axis), but when I toggle it back, I want it to centre on the player mesh then enable me to control the pitch (only) again. And that's where I'm struggling, with the 'then' part. I can make the camera gimbal look at the ball and if I toggle it back it will control the pitch of the camera, but with the yaw of the gimbal offset to the angle it was at when it was when it was last looking at the other object. Or, I can make the gimbal centre on the mesh again but I'm unable to control the pitch. I know why this is happening, because the gimbal is being continuously centred on the mesh I'd like to know how to centre the gimbal (one frame), before restoring control of the pitch. It's probably a very basic programming concept (or method or statement or something) that's required. Sorry for the essay, I didn't want to be unclear in any way!

 

So, first things first. Parenting the camera to the player which is moving around will work in simple situations but as you're finding out, can become increasingly complicated as you add new constraints.

Usually, you want the camera (or its "gimbal" parent object) to be free to calculate its position and rotation, and the player to separately be free to calculate its position and rotation. The camera may very well decide to check the player for constraints, but it cleans things up to have the hierarchies separate; you won't have to add anything to "restore the pitch" since you simply calculate the desired pitch independently.

There is a built-in optional package called Cinemachine (with many tutorial videos on YouTube) which offers a lot of high-level capabilities for camera control, but you can still write your own effective camera controlling script if you consider the needs of the camera independent from the needs of the player.

As for sequencing, when you have similar code in multiple scripts all running their own calculations in their Update functions, it can be a challenge to make sure that one script runs before or after another. Interactions that need careful attention to which runs first are usually a sign that your design could use some work in clarifying the dependencies. A good interaction between two objects would have one script (e.g., player controlling) perform its calculations in Update while the other (e.g., camera positioning) perform its calculations in LateUpdate; this ensures the ordering so the calculations have all the information they need.

This approach to sequencing is a part of what makes packages like Cinemachine work smoothly: they expect to be run last so they implement their code to run as late as possible in the regular engine execution cycle. (There is another "last resort" approach to enforcing order, called DefaultExecutionOrder or Script Execution Ordering, but all other architectural approaches to solving the dependency should be considered first.)

 

Thanks for the info, maybe it would be better to link the camera and the player via code rather than in the object hierarchy? I've got the Cinemachine package but haven't really had a very in-depth look at it! Might have to watch a few of those lengthy tutorials...