unnecessary readpacketupdate

readPacketupdate() is called on the client side when the server sends a control object state correction. These should be avoided unless they are absolutely necessary.
I encountered a problem that I'm not sure is a stock 1.5.2 problem or one of my own making...

In gameConnection.cc line 950 in method gameConnection::writePacket()

if (bstream->writeFlag(gIndex != -1))
      {
         // assume that the control object will write in a compression point
         if(bstream->writeFlag(mControlObject->getPacketDataChecksum(this) != mLastControlObjectChecksum))
         {
#ifdef TORQUE_DEBUG_NET
            Con::printf("packetDataChecksum disagree!");
#endif
            bstream->writeInt(gIndex, NetConnection::GhostIdBitSize);
            mControlObject->writePacketData(this, bstream);
         }
         else
         {
            // we'll have to use the control object's position as the compression point
            // should make this lower res for better space usage:
            Point3F coPos = mControlObject->getPosition();
            bstream->write(coPos.x);
            bstream->write(coPos.y);
            bstream->write(coPos.z);
            bstream->setCompressionPoint(coPos);
         }
      }

I found this method called on the server when Movelist was not empty meaning the server had not yet processed all the moves in the queue sent by the client. However it would still compare its present control checksum against the checksum sent by the client. This is incorrect because the client checksum represents the control object sum only after all the moves have been processed. Doing the check when there are still moves to execute is like comparing apples to oranges(or the results after move X on server to the results of move X+Y on the client where Y is the yet to executed moves on the server).
To fix this I changed the code to

if (bstream->writeFlag(gIndex != -1))

	  {
         // jreilly - Do not compare checksums unless we have processed all the moves because the client checksum is with all moves processed ->
         //  Assume that when all the moves have been processed(moveList empty) that the control object state should equal the mLastControlObjectChecksum
         // otherwise don't bother checking. Also check if mLastControlObjectChecksum = 0 because that means we need to set the initial position on the client
         // "assume that the control object will write in a compression point" - why is this comment here? what does it have to do with checksum?
         if (!mMoveList.size() || mLastControlObjectChecksum == 0)
         {
             if(bstream->writeFlag(mControlObject->getPacketDataChecksum(this) != mLastControlObjectChecksum))
             {
// #ifdef TORQUE_DEBUG_NET
                 if (mLastControlObjectChecksum != 0)
                    Con::printf("packetDataChecksum disagree! current %u last %u", mControlObject->getPacketDataChecksum(this), mLastControlObjectChecksum);
                 else
                    Con::printf("mLastControlObjectChecksum = 0");
// #endif
                bstream->writeInt(gIndex, NetConnection::GhostIdBitSize);
                mControlObject->writePacketData(this, bstream);
             }
             else
             // jreilly - disable compression points until I figure out how they work ->
             /*
             else
             {
                // we'll have to use the control object's position as the compression point
                // should make this lower res for better space usage:
                Point3F coPos = mControlObject->getPosition();
                bstream->write(coPos.x);
                bstream->write(coPos.y);
                bstream->write(coPos.z);
                bstream->setCompressionPoint(coPos);
             }
             */
             // -> jreilly - disable compression points until I figure out how they work
         }
      }

and this seems to be working. I wonder if anyone else has run into this condition?
I commented out compression point code until I have a better understanding how it works. I was getting the same results with it in or out so I don't think it is related.