the text in big bold red was written by Prince on elysiun
also, I am using a blender build from CVS, not 2.33a. some buttons shown here are not in 2.33a but will be in 2.34. I do not use any of the new features here however; this should be applicable to all versions with the new interface, and only slightly different on versions back to 2.23 [and probably further, 2.20 or 2.21].
the questions have been put out of order to allow the answers to be combined, and a few of them will build on the previous answer
for an environment, this is my method
if you need just dynamic lighting, and can limit yourself to 8 lamps per layer [no more than 8 lamps can effect a single object], and you don't need shadows, this is what you do
to jump you would understandably use a motion actuator, the only question is of what type of motion to use, and how to make it so you can't jump in the air. LINV is the type of motion you want to use, it can set the velocity of an object [or add to it] on a single frame. force is gradual, dloc should never be used, and the other types of motion are for rotation.
so, here could be a jump actuator
this will jump [with the default physics settings] over 1 unit.
so, how do you tell if you are on the ground? you could use a collision sensor, a ray sensor, a touch sensor [I think]... personally I like the idea of a ray sensor because it will not trigger when you touch a wall. you could configure a collision sensor that way, but it would require you to give your walls a different material, or require them to be a different object which doesn't have some property.
the ray sensor logic brick setup
so, there are a bunch of things to point out here.
this requires knowledge of your 1st person camera setup. But skipping the unnecessary communication, I probably would consider it inadequate.
okay, so here is the setup I propose. you use two objects, one for the horizontal rotation, one for the vertical rotation. the horizontal rotation one will be dynamic, the vertical rotation one will not, and will be a child of the horizontal rotation one. the vertical rotation object is either a camera or the parent of a camera. I will modify the script so it can be a camera.
well anyway, this script takes the movement of the cursor and rotates the two objects according to that movement [in the x and y direction] and some constant values which correspond to sensitivity in both directions. there are limits so for example you can't flip the camera upside down by looking past straight up or down.
as I do not want to teach how matrix multiplication works, and teach you python, I will just present the script's logic brick setup.
[for your information: the text has changed slightly since this picture]
okay, so Cube.001 is the object that rotates around its z axis, as in horizontally. The Camera rotates around its X axis, as in vertically. the logic brick setup shown in the text is shown here. the always sensor [init] and the python controller it is linked to simply hides the cursor. to make links between objects in logic bricks you need to enable showing of selected object's controllers by pressing the Sel button above the list of controllers, and actuators. with both the camera and cube selected you can create a link between the their logic bricks.
this is shown in mousescript_z3r0_d_fps2.blend
now then, how would you make the camera move up and down? simple, play an ipo of the camera moving up and down.
this setup will crouch as the C key is held down, and go back up when it is released. if you wish to toggle with the C key you'd use the ping pong mode [it is shown as Flipper] for the ipo actuator
this can be seen in mousescript_z3r0_d_fps2_crouch.blend
it should be noted that the setup shown here it is possible to move into the same size spaces regardless of whether or not your are crouching. It appears you wish to have crouch be automatic when walking under something, or perhaps be optional but not required to walk under something. this could be done with a ray sensor pointing upwards [opposite of the one for jumping] in place of or in addition to the keyboard sensor.
I haven't decided how to implement not being able to get into smaller spaces when not crouching in a good way.
I'd imagine that a key that would open doors would do other things too...
well anyway, here is what I am going to show:
now then, opening a door simply involves playing an ipo
however, as we would like to be able to duplicate that door elsewhere across the map we will have set up things accordingly.
one way to do this is to use the dRot or dLoc curves [dLoc much less so, because it would result in difficulty rotating our doors]. if you don't know what these are, it doesn't matter, we will not be using them as they seem not to work in the game engine.
what we will be doing is playing an animation of an object which is the child of an empty. we can then move the empty around as we like, and re-use the same ipo and logicbricks.
now, consider this. when opening a door we do it by the knob, not the hinge. so, when the door is open we close it using a different position [relative to the room, not the door]. this means that the point which we will face in the game will change when opening and closing the door. Okay, so lets just make that the center of the door [it is just as hard as the door knob the stuff to follow]. so, as the object will not be rotating around its center, we either need another object which rotates when the door opens and closes [which is much easier to do], or we need to setup the ipo for the door to move, keeping the hinge of the door on the hinge. this is more complex than just key framing the beginning and end because none of the interpolation types will keep the door on the hinge throughout the animation. some doors do in fact open that way [they have several parts to their hinge], but most of them do not. Because I do not want to explain [I'm lazy] how to do the latter, I'll just do the former, use another object at the hinge.
so, just a door [open/close with the spacebar] is shown in door_stupid.blend
play with this file some. notice how you can select all 3 objects, copy them [alt+d], and move [and rotate] them around, and they will still work as intended.
notice that the spacebar sensor is on the door. The user will not be interacting with the hinge, they will interact with the door.
Okay, here is where things are combined. The door will be given a state property, of type bool [let us assume other objects may have different type properties], and a property of Int type named interacttype. interacttype corresponds to the type of object it is [switch, door, ...] and state corresponds to its state [open, closed, on, off, set to the value of 7...]. we define these properties, so I am going to make True open, and doors will have an interacttype of 1.
the camera will have a radar sensor detecting objects having a interacttype property. This, and the keyboard sensor for the action key, will be connected to a python script which changes the state property on the detected object. so, it will change the state property of a door to true to open it. This script will also handle the showing of the interact text on the screen [which is based on the state and interacttype of the object]. It also decides which object if several is in the region of the radar sensor to use.
so, the door now only needs to know when the state property is changed to false from true or to true from false. the property changed sensor seems like a good answer to this problem, but it isn't because if the property is changed twice quickly, the first time it will open the door, the second time [while the door is still opening] it will not close it, but the property will end up saying the door is closed.
... but I have a new idea, why do I have to use ping pong for the door?
A property sensor testing for if state is true [the door is open, or should be] and a Flipper mode ipo actuator should do what we want [stop opening the door, and close it, when we change the property while it is opening, and vice versa], and it turns out it does. this can be seen in door_stupid1.blend [the spacebar now changes the state property]
now, to combine it with my 1st person view stuff. combination.blend shows it, with added 1st person controls (WASD, and with spacebar jump). the python script is used because DLOC IS EVIL and because the ebullient logic brick setup would be painful [if not possible, when I tried only one motion actuator had an effect at a time]. This file still has no interaction code
and yet, I come to another conclusion that changes the things I have said before. [clearly I haven't planned this well]. why don't I just use a ray sensor instead of a radar sensor? this means doors will be 2 objects again [because I can move their center around], and I don't have to think about which object I am interacting with, or how I will get a negative axis sensor.
so, I do that. the door becomes two objects, and the radar sensor is put on the -z axis of the camera.
so, a good bit of experimenting I will not mention later, I completed combination1.blend which has 2 doors, and some simple geometry. you can walk around [the logic for which is similar to that in Squish-the-Bunny.blend from the blender gamekit], you can jump with the spacebar, and you can crouch.
I know of no such script... and I am to lazy to write one [it isn't as trivial as the other questions]. at least for a few hours [no promises]