This change adds a connection ID to ping packets. Each node keeps a
connection id for each other node that it has connected to. When a node
is removed the connection id is incremented. If a node sees another node
with a higher connection id, it will reset its connection with the new
connection id, ensuring that local state is reset on both ends when
nodes lose contact.
As a form of compression, when encoding avatar data we only send joints that have changed significantly from the previous packet.
Also, if a joint has the same value as the avatar's default pose, we don't send the full value, instead we mark it with a single bit.
This particular issue is caused by an interaction between the default value flag and the joint changed culling.
When connecting to a domain for the first time, it's possible that a I-frame or 'full' packet will not be sent for several seconds.
In this case, the AvatarMixer has no previous history for values that have not changed recently.
This causes the AvatarMixer to broadcast incorrect values to other clients.
Keep in mind that the AvatarMixer does not have access to the avatar FBX file, so it cannot make an educated guess for this value and uses zero values instead.
(0, 0, 0) for translation and (0, 0, 0, 1) for rotation.
When a translation value of zero is received for the lower legs it will cause the legs to fold into the avatar's chest.
Also, we've uncovered a bug where sometimes values were not sent to the AvatarMixer even when the value was previously default.
This would also exhibit the same issue where zero translation values would be sent.
I've done three things to help mitigate this issue.
1) On first connect to a new AvatarMixer, the Avatar now sends a 'full' packet.
2) When a joint rotation or translation changes from the default value, we transmit it. No questions asked.
3) Once a SkeletonModel has finished loading we initialize the avatar's _jointData with the proper
translations from the default pose. This will help the case where a client receives a non default value, but has no previous history.
(cherry picked from commit 94efdf76a6454f316985f95d6a221adb24788d66)
* We no longer make backups at the ES, so there is no backup to
recover from if we crash during persist to disk.
* When loading the most recent backup we look for files that match our
backup rules. If we have no backup rules we end up grabbing
everything.
* Because we grab everything, we are at risk of grabbing the lock file
and treating it as a backup. In the case where we crash on persist, we
end up replacing the models.json.gz file with the lock file (!!).
This commit makes a small change to not do the recovery on startup. In a
future update we will remove the backup-related code on the ES
altogether.
