Attached "pet" not retain independant angularVelocity


#1

update: this bug is only valid for CUSTOM MODEL ENTITIES! {{see video 2}}
When “pet” is rezzed as an independant Entity with initial angular velocity = {x: 0, y:3, z:0} Entity rotates upon YAW axis. This is intended behavior for this phase, to rotate at a constant velocity in YAW whilst being attached to your avatar. However, when the “pet” is rezzed and given a parentID = MyAvatar.sessionUUID, the Avatar Rotation is unfortunately overwriting angular changes in the “pet”. To reiterate, in the video, the fairy should be rotating in place with respect to the YAW axis at all times. This rotational behavior is unfortunately only seen when the parent is in motion. Please fix this in a hotfix asap for contest entrants!

This was a simple test of mechanics prior to scripting much more “impressive” activities for fairy/world/player interaction.

cc: @Jherico, @leviathan, @ZappoMan

video2


#2

I cant seem to replicate this issue when I just create a cube, apply it to my sessionId, and apply a static angular velocity to it and rotate my avatar.

Are you sure its not something to do with the way you calculate the angular velocity instead? when stuff are parented to the avatar and use LookAt, it will always be from the world perspective, never the relative frame of the avatar. Add to that the rotation change of the avatar, and it will spin if you do not compensate :slight_smile:


#3

I’m actually pretty pumped you couldn’t replicate ((edit: we think we’ve rooted it to custom entities)), which means I have something screwy((edit: i don’t, it’s in source probably)), but perhaps try the following and consider also:

• I’m initializing the “pet” with a constant angular velocity of 3. Set it; then leave it alone.
• The angular velocity does not change in my example via scripting (or rather, I just want 3 at this point)
• Does your red “pet” continue spinning in constant velocity even if your avatar remains stationary?
• LookAt would be good for it to face us, yes, and have experimented with the text entity for signage, but in this particular use case, I really need to parent/unparent on-the-fly no pun intended. :smiley:
• Have you tried this using a custom model .fbx?

I’ll take a closer look at the code when I get there today, and post any findings. I’m not too proud to admit mistakes; this one just has me confused and worried. What I find extremely odd, is the particleEffect that is parented TO the “pet” is behaving as expected, but the “pet” is not. I understand a code snippet could help here, and I’ll grab that shortly (within the hour)((shown))
these are the important values shown.

dimensions: {   x: 0.1433, y: 0.3166, z: 0.1107  },
parentID: MyAvatar.sessionUUID,
damping: 0.0,  
angularDamping:0.0,
angularVelocity: {x: 0, y:3, z:0},  
lifetime: EXPIRE_TIME,
dynamic: false,

#4
  • The red cube I made was just a cube, that I created in edit script with a static angular velocity, then set the parent to my sessionID, It followed me as expected as seen in my gif, it keeps rotating, even if the avatar remains stationary, and regardless how they move, as expected.
  • Custom model I havent tried, but I suspect it will behave the same as the still use same entity objects.
  • I also havent tested a tree of parents, where a Entity has another entity as child.

Is there anything else that maybe effecting the rotation of the pet entity?


#5

lemme grab a coffee, I’ll kill the ocean shader. meet me at “arts”.


#6

Unfortunately, I aint home right now though currently on lunch break, only later on in the day :slight_smile:


#7

This could be the smoking gun. I’m full of puns today. :smiley:

…I’ll see myself out…


#8

Try just with simple cubes: create a cube thats a child of a cube that has a static angular velocity, and then parent that to your avatar and see what happens. Just to eliminate variables :slight_smile:


#9

Complete. Initial findings stand. See first post.


#10

Okay, will check with custom FBX as well once I get back home to see if it can be replicated with them.


#11

The parenting is conducted via the initialize scripting, as listed in the entity properties set on createEntity. Perhaps this is the difference?


#12

Didnt you just demonstrate this via the script? seemed constant to me for the second video.


#13

Yes. I did basically as you asked. I wanted to make sure I was using the same “fairy” scripts to ensure that if it fails we could be sure it wasn’t the scripts. So, the box entities were substituted into the custom fbx spots. The second video is basically those scripts using cubes instead. As can be seen, the cubes behave just fine.


#14

Sigh… also experiencing the “hiccuping” effect when parenting stuff to Avatars.

Haven’t figured out what’s behind it yet, but did find a really :poop:y workaround – continuously “modifying” an arbitrary Entity property ~20 times per second or more. This seems to trigger update packets that help keep everything flowing smoothly and kept in sync.

WARNING: this is NOT meant as a real solution – just a something better than despair for the short-term. :slight_smile:

Here’s an Interface script to demonstrate: create-buddha-shoulders.js.

Once loaded you should see two continuously-spinning Buddahs on your shoulders. Clicking on them toggles their update streams on/off. If considering this workaround then be sure to turn on stats display to get a feel for how much extra bandwidth it uses…


#15

If you give the fairy a shape-type of “box” does it spin?


#16

Let me try… brb…

Interesting results sir!
It manages to maintain spin in YAW, but does have the ‘hiccup’ @humbletim describes.
fwiw, this will at least get her to “spin in place” while the MyAvatar remains stationary.

… now where did I leave that multi-tool… :slight_smile:


#17

If your team maintains vision on this bug, I will go ahead and mark this as solved under assumption it will be coming in a later-release.

Thanks!


#18

It is not solved, but there is a workaround.