Attached entities with scripts are now being sold on the marketplace
(rWatch) and are now being worn by various users. Because of this, it's
now common for the 'removing entity scripts' case to be hit in code for
every update, which causes debug log messages every 60 seconds for each
entity entity with a script.
Repro: Have an avatar wear rWatch. With a second instance of interface,
turn on verbose logging while the first avatar is local. See debug logging
60 times a second.
Fix: Given attached entities with scripts are happening, it's not an
exceptional case and should probably not be logged.
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)
