Is this type of Rotation possible?

Clicky for example

I posted this in the wrong section (Building Tips) a week ago, having overlooked this section initially (I thought it was weird I didn't see it the first time XD; ) so, I'm reposting this with a bit more collectiveness to research.
here's the link to the original thread if anyone wants to look at Rime Wirsing's ideas on how to do this: clicky
The first idea didn't work so they brought up that llLookAt() might work, but I'm unfamiliar to this and I wanted to ask if it was possible to keep 16 child prims connected to use this technique?
here's my build: Fiery pet guy and like the picture provided up there, I thought it'd be cute if he was hovering up and down, to give it a hovering affect.

I was linked to this thread as well: /54/8a/44187/1.html

but it doesn't look like it's been used in a while and the idea is good, to have the child prim rotate off the parent prim... but in this case I'm not sure if that's what I need exactly unless there's a round-about way to keep all the child prims facing one direction ?


thanks much <3

I would need to know in what context the children are looking.

IE...
do they all need to look north at all times?
do they all need to face the direction of travel at all times?
is the Z-axis a factor in where they look (will they ever look up or down)?

and so on...

Without this I'm not sure I'd know how to set this up.

TBH, Rime's suggestion in your other thread is the best option. Or something similar to an invisiprim where you want the children to look at and a timer based llLookAt() in each of the children.

Well, the Z axis would be an added bonus, I just wasn't sure if it were possible (the look around effect would be neat though, I've been using Puppeteer to get a life-like feel but it's a bit laggy when something needs to move distances).

Basically they should all face the same direction the avatar is (at all times), as if it were hovering over their shoulder, so I don't think the in-world coordinates apply to that method? Assuming that means were the set facing North and the av turns in a circle the group stays stationary?


I'll experiment with the timer-based llLookAt(), but I've never touched on it before. Is the timer similar to checking what the prim is doing ever x seconds and reverts it to specified location? If so, will there be a noticeable jump/twitch/reset when that happens?

TBH, you'll probably want to use llRotLookAt() or llLookAt(), it depends on which axis you need to point with, +X for llRotLookAt() and +Z for llLookAt().

The real problem you'll face is communicating the proper target to point at. llLookAt() points +Z at target vector. llRotLookAt() points +X at target rotation.

The timer would be in the root prim, the children won't need one. The root prim will need to send out linked messages regularly broadcasting the root prim's current facing and the children, upon hearing the linked message, should update their llRotLookAt() or llLookAt() calls to the new rotation or vector.

Here's a trick to convert a vector fwd into a “look that way” rotation for llRotLookAt. This causes the prim to rotate so that it's local +x is pointing in the fwd direction and it's local +y is parallel with the region XY plane (no tilting). Of course the code here is completely untested, but I do this all the time in real scripts and something very similar to this is guaranteed to work....

fwd=llVecNorm(fwd);
vector lft = llVecNorm(<0,0,1>%fwd);
vector up = fwd%lft;
rotation lookthere=llAxis2Rot(fwd,lft,up);
llRotLookAt(lookthere,1,1);

The cross product (%) of the z axis and fwd is perpendicular to both, so it lies in the XY plane. (By the way this will fail if fwd is looking straight up or down!) llAxis2Rot requires unit vectors, so the calls to llVecNorm are necessary (unless fwd is a unit vector AND it always has a .z value of zero).