PackUpdate not called for client controlled object

#1 Is your update logic within the InitialUpdateMask check by chance?

#2 You'll have to explain the InitialUpdateMask a little more for me. By "within" do you mean below the...

// The rest of the data is part of the control object packet update.
   // If we're controlled by this client, we don't need to send it.
   if(stream->writeFlag(getControllingClient() == con && !(mask & InitialUpdateMask)))
      return retMask;

... line in packUpdate? I'm having trouble finding a better explanation on this subject.

#3 Control objects use writePacketData and readPacketData instead of packUpdate and unpackUpdate.

#4 That seems to be the little part i was missing. So under what cases is packUpdate/unpackUpdate called for a control object? Just at startup?

#5 Ok i got it working now by simply copying the stuff i was writing from packUpdate/unpackUpdate to writePacketData/readPacketData. It's probably being done incorrectly because the client isn't predicting, but just doing exactly what the server does.

I did notice that i get alot more writePacketData calls than i do readPacketData calls. I think i read about a packet checksum being used to test if the client and server state are in sync or not. Since my client and server are local for this single player and the prediction is perfect i assume this would be causing me to not get as many reads. Is this correct?

#6 Torque Game Engine Documentation: Networking

That says it better than I could =)

#7 Actually i prefer this version for all the nice hyperlinks, but still i've found some things confusing. It says stuff like "player object might have a movement state" then proceeds to tell me about using packUpdate()... well that is what lead me to believe that movement state belonged in packUpdate.

About write/readPacketData it says...

Quote:These functions are only called for the current control object, and only when the server can determine that the client's simulation is somehow out of sync with the server. This occurs usually if the client is affected by a force not present on the server (like an interpolating object) or if the server object is affected by a server only force (such as the impulse from an explosion).

But doesn't enlighten me as to why i see so many writePacketData calls without a single call to readPacketData.

#8 I can explain that.

Both the server and the client call writePacketData to write the control object's state into a buffer. They then compute a CRC on this buffer -- this is the control object's CRC. The client sends the CRC to the server after applying user input Moves. When the server gets the client packet, it applies the same Moves to the client's control object. It then calls writePacketData and compares the generated CRC to the CRC that the client sent after playing the same moves. If the CRCs are equal that means that the client has perfectly predicted (client-side prediction) the server state of the object and the server doesn't need to writePacketData the object state into the packet. It's only if the CRCs disagree that the server will write a new authoritative state to the client, in which case readPacketData will be called on the client.

Make sense?

#9 I understand perfectly now... thanks alot Mark.

I know i read about the CRC check somewhere, but for the life of me i don't know where that was. It wasn't in the docs... how about getting this little gem in there? =)

#10

Quote:Control objects use writePacketData and readPacketData instead of packUpdate and unpackUpdate

This is incorrect. Control objects use write and readPacketData but those functions only transmit "crucial" data, lots of things are synced by pack and unpackUpdate for all objects, including control objects.

Ian

#11 Does the pack/unpackUpdate also go thru the CRC check? Still don't know why setMaskBits() didn't force at least a packUpdate() to be called then. I'm sure i'll eventually need to solve that one.

#12 No, pack/unpackUpdate doesn't crc. You are calling setMaskBits with an argument right? Like setMaskBits(MoveMask)? Just calling setMastBits(), presuming it compiles at all, won't set any flags, as it ORs the current mask state with the argument.

Ian

#13 I'm setting mask bits. In face i had to change the amount of mount images to 4 in ShapeBase to get the one more bit i needed.