sorry, I cut that out, but I have it in my actual script, I just set it to zero, same with vAng;)
See, there's a problem.
Try to imagine what we're doing. We have your entity somewhere, and then, we want to place the camera at some distance to that, right? And in what direction should be dependant on vAng.
However, we can rotate vec_cam all we want - if you set it to zero, it's the nullvector. That one will stay (0,0,0), no matter how you rotate it. And that does make sense, doesn't it? Imagine you ROTATING an arrow - it keeps it's length. If it was length 5 before, it'll be length 5 after rotating. And if it was length 0, well... the arrow will still be of length zero.
So if you later add zeros to your entities' position, nothing will happen.
So, let's correct that:
[...]
//We're probably in a while() { .. wait(1); } loop here
vAng.pan -= mouse_force.x*time_step*10;
camera .pan -= mouse_force.x*time_step*10;
//set vec_cam to a default value
vec_set(vec_cam,vector(-100,0,0));
vec_rotate(vec_cam, vAng);
vec_set(camera.x,ent_for_camera.x);
vec_add(camera.x,vec_cam); //A little shorter
//But really, it's just the same as that:
// camera.x = ent_for_camera.x + vec_cam.x;
// camera.y = ent_for_camera.y + vec_cam.y;
// camera.z = ent_for_camera.z + vec_cam.z;
100 is the distance of the camera to the entity (in quants) - you'll have to play with that value, since I don't know the scale of your level. It's negative here - because we want to move BEHIND the entity (we want to see it!).
Notice the other change - I've added *10*time_step. time_step is a value that depends on your framerate - for high framerate, time_step will be low, and vice versa. The reason to add this is that you want the game to "feel" and control the same, whether its running at 60 or 200 fps. But in the latter case, such a "while(..) { .. wait(1); }" loop will run 200 times in one second, and thus, we'll actually add/subtract much higher values from camera.pan than we were intending to.
A final note, unless you really need vAng to be different from camera.pan, there's probably no reason for you to use it -- you could use camera.pan directly in vec_rotate.
Last, but not least, a word to rvL_exile's script. Typos aside (like the "()" at the very bottom (since you want to assign the function to on_middle_mouse, NOT the return value), or the "Var" in the first line of the function), you would be able to rotate the camera, but about the origin of the level (0,0,0). Compare with the snippet above - note how we set the camera first to the entities' position, and THEN added the rotated vector? The result is, then:
campos = entity.pos + rotatedVector
but here, it's just
campos = rotatedVector
which is really just the same as if entity.pos was all zeros.
To make up for that, we rotate the camera's angle to look at the player. It's a very different kind of camera behaviour, but there's still a lot one can learn from that snippet!
It's not using vec_rotate, but rather does the same thing "by hand". It also isn't affected by the tilt-value, so the rotation will only ever be in the x-y-plane (and never change z). So, well, not quite the same thing, then!
The whole thing can be written as a multiplication with a rotational matrix - and it's not as complicated as it sounds here. Still, I think I've written enough for the moment. Feel free to ask questions, if you still have any!
