GameConnection mCameraObject Networking Bug

#1 Here is a folowup with some more information...

I added the checksum for the camera object and, as expected, it does significantly reduce the number of writepacketData calls for the mCameraObject.

Additionally, most of the information sent to the camera seems to be when the server gets a tick ahead of the client. This is fine because the calls to interpolateTick will handle this "synch up" smoothly.

However, it appears that there are times when the client gets a couple of ticks ahead of the server. I am not sure how to properly deal with this on the client.

For example:

Here is an example of the situation where the server seems to be a bit ahead:

ProcessTick() on client final position:      0.01 -14.22 16.42
ProcessTick() on client final position:      0.01 -14.19 16.53
ProcessTick() on client final position:      0.01 -14.14 16.65
ReadPacketData Position from server:   0.01 -14.04 16.86

In the above example the client was happily calculating the camera's position, the server sent an update that seems to be the next tick in the sequence, and we can handle this using interpolateTick().

Here is an exmaple of the situation where the client seems to be a bit ahead:

ProcessTick() on client final position:    0.02 -9.73 18.85
ProcessTick() on client final position:    0.02 -9.50 18.91
ProcessTick() on client final position:    0.02 -9.25 18.96  <==server seems to be here
ProcessTick() on client final position:    0.02 -9.00 19.01
ReadPacketData Position from server: 0.02 -9.22 18.96

The above situation is the one I don't know how to deal with. It appears that the client is a tick ahead of the server. If I start interpolating to the position sent from the server then I will basically be reversing the direction of the camera temporarily which causes jerkiness.

Does anyone have any suggestions?

Thanks for the help.
Todd

#2 Another followup....

Interestingly, when the player class is the control object it almost NEVER actually gets an update from the server from readPacketData because its checksum matches the server. My camera class, on the other hand, frequently needs a small adjustment from the server.

I'm not sure why that would be the case.

#3 Are you using compressed points? When camera sets a compressionpoint it overwrites the player's and could desynch the camera. Somebody posted a fix for that on a mouse controlled player movement resource, you might take a look at it.

#4 Hi Entropy,

I have determined that the reason the cameraObject sends so many more updates from the server has to do with how mRot is being calculated. When I stopped sending the rotation information (and with a bunch of other fixes) I was getting smooth camera movement. I have an idea where the mRot is being hanlded incorrectly and I am going to be digging into how to fix this part next.

Assuming that I can get it so that information is sent via readPacketData/writePacketData only when it really needs to be, I still have one really big fundamental question...

How should data sent via writePacketData/readpacketData() be handled. By the time the client gets the updated information for tick x, it will already be on tick x+1 (at least). And, unlike in packUpdate/unpackUpdate I don't believe that this information is time stamped. So, what is the proper way to handle this?

Similarly, I don't understand what the player class is doing in readpacketData() where it only updates the delta.pos but not the delta.posVec? It doesn't seem correct to only update delta.pos.

Thanks for the help.
Todd

#5 Well I am having the same problem so I am interested in your results, and anything anybody else might suggest as well.

I am using a camera rotating around the player. I tried two methods of placing it, one was just using the objec'ts position to calculate a vector to the target object (mRot was ignored), the second was just setting mrot and pos directly from the servers packet updates. Neither method corrected the shakiness. The first method kept the player object from shaking but caused everything else to shake. The second method kept everything else from shaking but caused the target object to shake.

It seems the player object and camera object are out of synch somehow, so perhaps sending camera position information directly from player (target object) read/write packet might help.

#6 Ok,

I have made a good amount of progress on this and can get most of the existing advanced camera modes operating smoothly.

However, for a new mode that I am working on, the following behavior is problematic. Does anyone know how the following can be mitigated:

ProcessTick on the client and the server is being called in a slightly different order for the camera and the player. For example, I am seeing the following:

Server: 10 calls in a row to process tick for the camera
Client: 10 calls to process tick for camera and 10 calls to process tick for player (alternating)
Server: 10 calls in a row to process tick for the player

You can see that 10 ticks later the camera object and the player object have both had 10 calls to process tick on both the client and the server. However, on the server there were 10 calls to camera then 10 calls to player, while on the client the calls for the two classes alternated.

Is there a way to force the client and the server to behave in the same manner?

Thanks
Todd

#7 Did you look in gameprocess.cpp? Control objects are processed differently than other objects. What mode are you talking about? My problem is Orbit Mode. Take a look at the advanced camera resource thread, I posted my code (without interpolation) just the other night. Maybe that will help. If you can get the interpolation to work it would be pretty awesome if you could post a fix for us.

#8 Hey Entropy,

I have gotten the interpolation working without any jittering for Godview mode. I am very confident that the changes will work for orbit mode as well.

I am also adding a proportionate controller to a camera mode that I am working on. That proved to be a bit trickier. However, I was able to get it to work by modifying gameprocess, as you suggested.

Basically, the mCameraObject was not as well integrated into the engine as the mControlObject. Once I got those things working, the advanced camera resource needed heavy modifications because it was really only setup to work client side.

I have to focus on a specifc camera mode I need right now, however I will shoot you the updated code once I have had a chance to go through and get all of the other modes (including orbit) working.

Todd

#9 I think you will find I have already done most of the necessary mods to get AdvancedCam working server side here (at the end or the thread, if you didn't see my post already).