Per AndrewMeadows comments and up = yAxis not necessarily always being true in the future, the ROT_Y_180 has been moved to be the second quaternion in the multiplcation to determine rotation
- Made parent-ator be off unless it is equipped (this does have the ramification that it does not turn on when it first rezzes. When you equip it it turns on)
- Added the localOnly: true setting to the audio
1) Does not give the message regarding not having permissions except for when first rezing the tool.
▶ Fixed - Added in a check for every time there is a collision between the parent-ator and another entity
2) Sound almost unhearable due to distortion
▶ Fixed - Changed audio to 16 bit mono
3) The Parent-ator model rezzes pointing at the user's face. Would probably be better to add 180 to START_POSITION.y then normalize.
▶ Fixed - Added 180 to START_ROTATION (instead fo START_POSITION) and normalized
4) The Parent-ator model floats away. Would suggest increasing linear damping from the default. Maybe go to 0.9 or more.
▶ Fixed - Added damping of 0.9
5) The face normals are inverted on the three rings surrounding the barrel of the Parent-ator model.
▶ Fixed - Normals flipped
6) Also if the user taps an object then releases and re-equips with the Parent-ator it continues to display "tap the child" but will set the object tapped first as the child of the first other object tapped after re-equipping. So the messages change from Tap the child to the "Yay" success message.
▶ Fixed - Re-equiping now resets the parent-ator.
7) Parenting can be broken with this. On occasions the Parentator seems to get out of sequence. With a group of objects eventually one or more can get orphaned. In effect (occasionally ) a single first tap can produce the success message.
▶ Believed to be fixed - I was unable to really reproduce the problem but the fix for the previous item should fix this too, I believe.
8) There is an error in the description on line 7 of parentator.js
▶ Fixed - Changed reference to pingpong gun to parent-ator
9) Equipping can fail with a smaller than normal avatar as the offsets are hard coded rather than scaled relative to the user's scale.
▶ Fixed - I realized I was adding the entity with larger dimensions than the model normally had. I've scaled it down to where it should be and I think this has solved the issue.
When writing entity properties to a packet, we start off with a list of
requested properties (`requestedProperties`) and keep track of which properties
didn't fit (`propertiesDidntFit`) the packet, which is intialized to
requestedProperties. As we pack the properties, we remove them from
propertiesDidntFit if they didn't need to be written or were able to be
packed. At the end we store propertiesDidntFit, and use it in the future
as our requestedProperties when we try to pack more data into a packet.
The bug: because of the order in which propertiesDidntFit is
initialized, it ended up always being the list of all properties for
that entity. This typically wasn't an issue because we usually go
through and try to append all of the properties, and if we don't need to
append them (because they aren't in requestedProperties)
we remove them from our propertiesDidntFit list. When we
don't have enough remaining space in the current packet for even the
entity header, which is fairly small, we don't bother trying to append
any of the properties. When this happens, propertiesDidntFit contains
the full list of properties, which we save for the next pass through the
entity, and use as our requestedProperties, causing us to resend entity
data again. In the worst case we never end up sending all of the
entity's data.
In entityPropeties.js
line #1079 says:
elParentJointIndex.addEventListener('change', createEmitNumberPropertyUpdateFunction('parentJointIndex'));
The problem should be fixed by changing it to:
elParentJointIndex.addEventListener('change', createEmitNumberPropertyUpdateFunction('parentJointIndex', 0));
createEmitNumberPropertyUpdateFunction() is parsing the value as a
float to a default decimal position of 4. Looks like it only accepts
integers. By adding in that 0 as a second argument, it should coerce the
value to one that will be recognized by the UI/backend.
