Changed unsigned int to signed int for resync in DistributedSmoothNode.

[rushingseas8]

Issue description

The current code in direct.dc is as follows:

  suggestResync(uint32 avId, int16 timestampA, int16 timestampB, int32 serverTimeSec, uint16 serverTimeUSec, uint16/100 uncertainty) ownrecv clsend;
  returnResync(uint32 avId, int16 timestampB, int32 serverTimeSec, uint16 serverTimeUSec, uint16/100 uncertainty) ownrecv clsend;

suggestResync is called in the method for DistributedSmoothNode#setComponentTLive, where uncertainty = globalClockDelta.getUncertainty(). The definition for ClockDelta.getUncertainty() states:

    def getUncertainty(self):
        # Returns our current uncertainty with our clock measurement,
        # as a number of seconds plus or minus.  Returns None,
        # representing infinite uncertainty, if we have never received
        # a time measurement.

Therefore, the return value can be either positive or negative. This is exemplified by the following exception trace, where getUncertainty happened to return a negative value:

ValueError: Value out of range on field: suggestResync[102679575, 9862, 9771, 253722.0, 288.0651640589349, -0.16683287050850307]

Since the associated method returnResync is called on the other party with the same value of the parameter uncertainty, fixing both is necessary to correct this issue.

Solution description

To fix this issue, the value of uncertainty should be a signed integer, since the documentation for the values it can take on indicate that it can be negative.

Checklist

I have done my best to ensure that…

• …I have familiarized myself with the CONTRIBUTING.md file
• …this change follows the coding style and design patterns of the codebase
• …I own the intellectual property rights to this code
• …the intent of this change is clearly explained
• …existing uses of the Panda3D API are not broken
• …the changed code is adequately covered by the test suite, where possible.

[Moguri]

Looks good to me. However, I am not too familiar with DC and if this change has the potential to break existing code. I believe it's fine as long as everything (clients, servers) uses the updated code.

[Wizzerinus]

This should indeed not break existing code as long as both server and client update to the version of the engine with this patch. Unless uncertainty goes above int16 bounds. Which it honestly might because most network time measurements use uint16. Although if someone has a latency of 328 seconds the game is probably unplayable anyway (if I understand uncertainty right)

[Maxwell175]

The problem is if the client and server don't have synchronized versions it will break. This should only be merged into master. A mitigation for 1.10.x can be to just wrap it in abs() to at least prevent the crashing.

[Moguri]

Yeah, let's keep this for just 1.11 and not backport it. I agree that 1.10 versions should remain compatible. I also agree that the new upper bound is fine.