TGE Networking Question
by Jared Schnelle · in Torque Game Engine · 03/29/2003 (9:55 am) · 4 replies
Some Background
---------------
I'm controlling a mounted turret on top of a vehicle with my mouse. There are 2 approaches that I have taken, and both seem to work, but the issue lies with networking at the moment.
:Approach 1:
(For simplification I'll only talk about yaw)
Modify the Move structure to allow for turretYaw. When the getNextMove function is called, it grabs the static variable $mvTurretYaw from the scripts, and stores it like:
curMove.turretYaw = MoveManager::mTurretYawSpeed;
Then, in the move::Pack it does
This let's me take mouse input up to about 127, which is if you really really yank the mouse, anyhow. This is obviously unpacked, and sent throughout the system, as a normal move is.
Now, in the vehicle::onMove(...) function, I handle the rotation of the turret. This occurs on both server and client, so it is important that they both have the same exact move, which is part of the reason I chose to use integers in the move, instead of floats where you receive errors depending on how many bits you use to pack it. So, both the server and the client rotate it correctly, and all is well.
Problem : What if a move packet is dropped?
I noticed that if the server and client had different moves that there would eventually form a flicker between the two (if i'm hosting the server on the same machine), so the position of the turret on the server and client would eventually deviate. How is this fixed? When the server sends out the Vehicle::packUpdate(...), does he also send this to my client? Or do I need to use the Vehicle::writePacketData(...) function to send the server's value back to the originating client?
Approach 2:
I'll keep this short. 2nd approach is to use the camera's transform matrix to orient the turret. I get the yaw rotation from that, and store it in a GameConnection member variable. Then, when I do a GameConnection::writePacket, i send the turret rotation to the server, and that trickles down through the packUpdate/unpackUpdate to the rest of the clients. The problem I think I might run into, is a delay in the sending of the packets.
Are the move packets sent more often than the GameConnection::writePackets, or are they sent at the same interval?
Thanks so much for the help.
-Jared
---------------
I'm controlling a mounted turret on top of a vehicle with my mouse. There are 2 approaches that I have taken, and both seem to work, but the issue lies with networking at the moment.
:Approach 1:
(For simplification I'll only talk about yaw)
Modify the Move structure to allow for turretYaw. When the getNextMove function is called, it grabs the static variable $mvTurretYaw from the scripts, and stores it like:
curMove.turretYaw = MoveManager::mTurretYawSpeed;
Then, in the move::Pack it does
bool neg = false;
if(turretYaw < 0){
neg = true;
turretYaw = -turretYaw;
}
stream->writeFlag(neg);
stream->writeInt(turretYaw, 7);This let's me take mouse input up to about 127, which is if you really really yank the mouse, anyhow. This is obviously unpacked, and sent throughout the system, as a normal move is.
Now, in the vehicle::onMove(...) function, I handle the rotation of the turret. This occurs on both server and client, so it is important that they both have the same exact move, which is part of the reason I chose to use integers in the move, instead of floats where you receive errors depending on how many bits you use to pack it. So, both the server and the client rotate it correctly, and all is well.
Problem : What if a move packet is dropped?
I noticed that if the server and client had different moves that there would eventually form a flicker between the two (if i'm hosting the server on the same machine), so the position of the turret on the server and client would eventually deviate. How is this fixed? When the server sends out the Vehicle::packUpdate(...), does he also send this to my client? Or do I need to use the Vehicle::writePacketData(...) function to send the server's value back to the originating client?
Approach 2:
I'll keep this short. 2nd approach is to use the camera's transform matrix to orient the turret. I get the yaw rotation from that, and store it in a GameConnection member variable. Then, when I do a GameConnection::writePacket, i send the turret rotation to the server, and that trickles down through the packUpdate/unpackUpdate to the rest of the clients. The problem I think I might run into, is a delay in the sending of the packets.
Are the move packets sent more often than the GameConnection::writePackets, or are they sent at the same interval?
Thanks so much for the help.
-Jared
About the author
#2
In the GameConnection::writePacket(..) function, they call the moveWritePacket(..) function which in turn calls the Move::pack(..) function.
So the answer is, the moves are sent at the same frequency as the GameConnection::writePacket(..), so I'm going to do this:
Grab the mouse events, convert those into pitch/yaw, adjust my rotation of the turret, then store this into my GameConnection member variable mTurretPitch, mTurretYaw.
I'll send these over GameConnection::writePacket(..) and not the Move list, since this should cut down quite a bit on network traffic.
Since you can send up to 30 moves at once, and the pitch/yaw will contribute 2 bools and 2 7 bit integers to each move, I'll just send two floats across that hold my pitch/yaw.
If anyone ever reads this and thinks of something better, or sees a flaw, let me know.
03/30/2003 (11:10 am)
Well I guess I might as well try to answer my own question.In the GameConnection::writePacket(..) function, they call the moveWritePacket(..) function which in turn calls the Move::pack(..) function.
So the answer is, the moves are sent at the same frequency as the GameConnection::writePacket(..), so I'm going to do this:
Grab the mouse events, convert those into pitch/yaw, adjust my rotation of the turret, then store this into my GameConnection member variable mTurretPitch, mTurretYaw.
I'll send these over GameConnection::writePacket(..) and not the Move list, since this should cut down quite a bit on network traffic.
Since you can send up to 30 moves at once, and the pitch/yaw will contribute 2 bools and 2 7 bit integers to each move, I'll just send two floats across that hold my pitch/yaw.
If anyone ever reads this and thinks of something better, or sees a flaw, let me know.
#3
Sorry it didn't get through :(. Glad to hear you fixed it, though!
03/30/2003 (4:43 pm)
Odd, I thought I had posted roughly the same idea earlier today... I guess Phoenix ate my post. o.0Sorry it didn't get through :(. Glad to hear you fixed it, though!
#4
-Process the mouse events within the move structure. Then, update the animation client side(for your control object) using the move structure. At the end of this, I send the current animation position across the network to the server, which sends it to the rest of the clients.
What I end up with is smooth animation on the client's end, and a little jerkier animation for my vehicle when being viewed from another computer. This is a good tradeoff for me. I get better accuracy, and less network usage for a little less pretty animation. Which, in itself is ok, since it's going to be a fairly fast paced shooter :)
-Jared
03/30/2003 (5:39 pm)
Well what I ended up having to do was this:-Process the mouse events within the move structure. Then, update the animation client side(for your control object) using the move structure. At the end of this, I send the current animation position across the network to the server, which sends it to the rest of the clients.
What I end up with is smooth animation on the client's end, and a little jerkier animation for my vehicle when being viewed from another computer. This is a good tradeoff for me. I get better accuracy, and less network usage for a little less pretty animation. Which, in itself is ok, since it's going to be a fairly fast paced shooter :)
-Jared
Torque Owner Jared Schnelle