Default.bind.cs: $mvForwardAction, etc: where to go from there?
by Ryan Anderson · in Torque Game Engine · 05/01/2006 (2:43 pm) · 4 replies
I'm playing around with starter.fps, trying to get the camera and player controls to behave like I want them to. Basically, what I want to eventually do is restrict the camera yaw/pitch and be able to move or rotate the camera based on the player's position.
Unfortunately, I've run into a problem: I can't figure out where this movement occurs!
As far as I can tell, when a button is pressed it fires the function you've bound to the key in default.bind.cs. So for instance, when you press the 'w' key, the game fires moveforward, passing it a value dependant on the input source (1 for a key press). Then it calculates the movement speed my multipling it to a variable that determines the overall speed. Finally, it stores that value in $mvForwardAction, presumably to be acted on later, during the next calculation cycle. So far so good.
Now my problem is, as far as I can tell, that's where the code ends! I can't find any reference to $mvForwardAction or its cousins in any of the included script files, or in the common script files. So where does this get calculated? How does this influence player movement? I can only presume that this variable is acted on within the engine itself. Am I wrong in this? If it does, where is this action occuring, so I can modify its behavior? (Perhaps a question for the engine forums...)
Unfortunately, I've run into a problem: I can't figure out where this movement occurs!
As far as I can tell, when a button is pressed it fires the function you've bound to the key in default.bind.cs. So for instance, when you press the 'w' key, the game fires moveforward, passing it a value dependant on the input source (1 for a key press). Then it calculates the movement speed my multipling it to a variable that determines the overall speed. Finally, it stores that value in $mvForwardAction, presumably to be acted on later, during the next calculation cycle. So far so good.
Now my problem is, as far as I can tell, that's where the code ends! I can't find any reference to $mvForwardAction or its cousins in any of the included script files, or in the common script files. So where does this get calculated? How does this influence player movement? I can only presume that this variable is acted on within the engine itself. Am I wrong in this? If it does, where is this action occuring, so I can modify its behavior? (Perhaps a question for the engine forums...)
About the author
#2
05/01/2006 (3:50 pm)
Excellent, thanks for the quick reply! Now I have a place to start digging... 
#3
05/02/2006 (10:39 am)
You don't need to worry about movement controls for this. Look at camera controls, and I suggest implementing Advanced Camera, which is a resource here. I believe it has the ability to constrain yaw/pitch.
#4
05/06/2006 (2:11 am)
I ended up implimenting AdvancedCamera for this, had to add my own mode to get it working exactly as I envisioned. Still not complete (AdvancedCamera doesn't support constraint of yaw, for instance) but I'm well on my way, thanks for the help! 
Torque 3D Owner Stephen Zepp
Those variables are tied to c++ variables within the Move struct on the client, so that when they are changed in script, their corresponding c++ data fields are changed as well. In addition, the move information is applied directly to the control object in the client side simulation (non-authoritative, which means it's subject to server correction on a later cycle).
Periodically (very quickly!) as part of the networking packet construction, these values (the Move structure) are collected on the client, packed up into a packet, and delivered to the server via the networking protocol.
Once they arrive at the server, they are decoded, placed into a server side Move struct, and passed along to the appropriate control object for that client as part of the ::processTick() for that object.
During the server side tick processing (Player::processTick() for example, as well as ::updateMove() and ::updatePos() ), the various information is processed by the server. Once processed, appropriate updates are packaged up (ghost updates for most clients, control object updates for this specific client), and are sent out to clients that have the object in scope.
At that point, the clients each take into account the authoritative server position, and use interpolation to gently (or quickly as the delta requires) correct their simulation to match the server.
And yes, that is the short answer--it's actually quite a bit more complex!