Lerpz Tutorial Question

Newbie issue: I’m running through the Lerpz tutorial and I’ve set a camera for the cut scene at the end, where the ship flies off. Animation is perfect, and I added the SmoothLookAt script to the camera, and when I watch the camera gizmo, it seems to be doing what it is supposed to be doing, but the view in the viewport spins around in circles. Does anybody know what I’m doing wrong?

Welcome to the forums! :slight_smile:

Nothing jumps out immediately, have you properly assigned the space ship as the target for the SmoothLookAt script? When you say “spins around in circles” is it pointing at the ship and “rolling”, or is it spinning in a plane (rotating around y for example)?

Spins around Y. I debugged SmoothLookAt and it seems to be fine. I think something else is screwing with the rotation, but nothing jumps out at me either. Trying now to just stick in a stationary camera that responds to the LevelCompleted() function… just thought maybe another newbie had made the same mistake before. (Sigh.)

It was the near camera, flying off trying to follow the invisible Lerpz as I shot him into the air to make it look like he vanished (and the guards would stop harassing him). So the issue was the new cut scene camera was not activating. I found that I had to check the active checkbox, then set the camera to inactive in the Awake() function to get the proper behavior. This was also true for the PiP cut scene camera. Had to set it explicitly to active, then deactivate it in my script when game begins. Is this correct behavior? Its a bit irritating because now the Game View (when Game is not playing) shows me the camera with the greatest depth, which cannot be the near camera. Not important really, but not what I was expecting. Anyway, now I’m off to the races, eh? Thanks for responding…

I’ll put my hand up here and admit that I wrote the 3D Platformer Tutorial. In hindsight, I think it would work better in a more visual medium. (Video, for example, although Unity itself has a lot of potential. “Unitycasting” has an intriguing, “Web 2.5” ring to it…)

This thread also illustrates a common problem with linear tutorials: they tend to give the impression that there is a single path to enlightenment – a single, “best” solution to the problems covered in the text. A good tutorial is written with education in mind, so the code tends to be written to be easy to read, rather than necessarily being the most optimal solution. The tutorial is just one way to solve the problem, but not the only way.

For example, instead of firing Lerpz into the ether while making him invisible, an alternative is to simply hide him by disabling his renderer and setting a flag, accessible to the robots’ scripts. A simple script with an Update loop would then check this flag. If the flag tells us the player is now invisible, our new script would just disable the robot’s AI script, effectively shutting it down.

I suggest putting this check process in a separate script for flexibility (using a “FixedUpdate” loop). You could then have this same script re-enable the robot’s AI should you need this functionality for your own experiments with the tutorial. A separate script is needed for this as a disabled AI script obviously can’t run itself to test whether it should be re-enabled again.

(NOTE: Using the Enabled / Active feature built into the GameObjects and Components seems like an easier option, but this tends to annoy the more complex camera control scripts.)

Yes. Unity makes a distinction between “Enabled” and “Active”. I forget exactly what the distinction is, but there is one. (It’s one area that could use some expansion in the docs, come to think of it.) I seem to recall that one or the other was deprecated in Unity 2.x, so it may be that Unity 3.x won’t have both.

There’s probably also a spectacularly, knee-tremblingly awesome reason for some API elements to be named using British English – “MonoBehaviour” – and others, US English – “Color”. :slight_smile: Unity is great, but it’s not perfect. (Yet.)

You do know that Camera objects can have their depths changed easily through scripts, right?

The tutorial was written with Unity Indie in mind, so rendering to a texture wasn’t an option; this part of the tutorial showed how to get around that for Indie users.

Heh…Unity can use both “grey” and “gray”, so I think it should be the same for the others. :slight_smile:

–Eric