This happened because the Clipboard wasn't being completely cleared between uses.
This bug can also manifest in another way (if Interface doesn't crash): the imported entities appear very far away, instead of right in front of the user. This happens for the same reason as the crash: the Clipboard still contains some previously-imported entities. That causes us to calculate the wrong dimensions for the newly-imported entities which is why they are added to the domain far away.
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)
Before this fix, playback of avatar recording frames could overflow the maximum UDP packet size (MTU).
This is playback of a recording was causing all the rotations and translations to be transmitted,
even if the translations were not any different then the avatar default pose.
This explicitly records the rotationIsDefaultPose and translationIsDefaultPose in the recording stream.
This does not break backwards compatibility.
However, it does require new recordings for avatars with large numbers of bones.
