llMoveToTarget and llTargetOmega not working together

[gwenavive]

I'm using this code to have an object float above my head and stay there as i walk around and trying to have it rotate on z-axis 360 degees continuously.

startFollowing() {
    llSetStatus(STATUS_PHANTOM, TRUE);
    llSensorRepeat("", llGetOwner(), AGENT, 10.0, PI,1.0);
    followMe = TRUE;
    llTargetOmega(<0.0, 0.0, 1.0>, 1.0, 0.001);
    currentPos = llGetPos();
    currentRot = llGetRot();
    llSay(0, "Start Following"); 
}

stopFollowing() {
    followMe = FALSE;
    llTargetOmega(<0.0, 1.0, 0.0>, 0.0, 0.1);
    llSay(0, "Stop Following Me");
    llMoveToTarget(currentPos,0.4);  
    llSetTimerEvent(2.0);
}

timer() {
    llSetStatus(STATUS_PHANTOM, FALSE); 

    llSensorRemove(); 
    llSetTimerEvent(0);
}
sensor(integer total_number) {
    if (isLoggedOn) {
        vector pos = llDetectedPos(0);
        rotation rot = llDetectedRot(0);
        vector offset =<0,0,1.8>;
        pos+=offset;
        llMoveToTarget(pos,0.4);   
    } 
}  

The object is moving from the ground above my head perfectly and back again on stop, but it seems that the llTargetOmega to rotate the object above my head doesn't want to work with llMoveToTarget?

Any help would be appreciated.

[Quistess Alpha]

12 minutes ago, gwenavive said:

llTargetOmega(<0.0, 0.0, 1.0>, 1.0, 0.001);

That strength is really low. it doesn't matter normally, but it matters a bit when you have a physical prim (which is needed for llMoveToTarget() ).

Is there any particular reason you need a folower and can't just use something rigged to AVATAR_CENTER (sometimes called 'avatar root')?

[gwenavive]

I tried the attachtoavatar but it gets distroyed when trying to detach. People click it and it sits above the head, click again and it goes back to the ground where it was.

if there's another better way of doing that, i'm all ears.

I just set it to 1 from 0.001 and working  yay thanks Quistess Alpha

Edited October 11, 2021 by gwenavive

[Quistess Alpha]

11 minutes ago, gwenavive said:

People click it and it sits above the head, click again and it goes back to the ground where it was.

if there's another better way of doing that, i'm all ears.

It really depends on exactly how it's going to be used. Personally, I'd have 2 coppies of the thing, one that sits in-world and one that attaches to people. Touch the in-world one and it goes invisible and rezzes the attachment version. the attachment version then asks permission to attach to the avatar who did the touch. Touch the attachment version and it sends a message to the in-world version to turn visible then detaches itself.

There are more nasty nuances to deal with in that implementation (What to do if someone teleports out while wearing the copy for example.), but it's less hard on the server.

[gwenavive]

That does sound interesting.

I already have the sensor looking for them when it's above their head so that could run from the invisible one and message the attached one to detach maybe?

Would that ask for permissions each time without something in the parcel experiences?

Realised i could use the [AV]object and the AVSitter experience. Nice solution

Edited October 11, 2021 by gwenavive

[Quistess Alpha]

31 minutes ago, gwenavive said:

I already have the sensor looking for them when it's above their head so that could run from the invisible one and message the attached one to detach maybe?

Would that ask for permissions each time without something in the parcel experiences?

Yes, it would have to ask permission each time unless you have an experience set up and modify the script to use it.

The main advantage to the approach I outlined is that it can be done /without/ a sensor. Sensors certainly have their uses, but nine times out of ten I generally find that there's a more efficient way to do the same thing.

[gwenavive]

Always more than 1 way to skin a cat they say. Poor cats though

Appreciate the idea and effort very much

[animats]

Second Life has several different systems for moving objects. There are ones that use the physics system, there's keyframe animation, there's direct positioning (llSetPos, etc.) and there's pathfinding. They're not interlocked. You can only use one system at a time. Allow a second or two between changing from one system to another. llMoveToTarget and llSetTargetOmega belong to different systems.

llLookAt and llRotLookAt belong to the same family as llMoveToTarget, and can be used together.

llTargetOmega is interesting. It's usually just a visual effect of rotation, done in the viewer. Selecting the object will make it stop rotating for you, but not for other viewers. It's for wheels, windmills, and spinning decorative objects, where you want rotation but don't care about actual position.

[Quistess Alpha]

53 minutes ago, animats said:

llTargetOmega is interesting. It's usually just a visual effect of rotation, done in the viewer. Selecting the object will make it stop rotating for you, but not for other viewers. It's for wheels, windmills, and spinning decorative objects, where you want rotation but don't care about actual position.

llTargetOmega is basically 2 completely different functions depending on whether the object is physical or not. for physical root prims, llTargetOmega is more or less a more convenient form of http://wiki.secondlife.com/wiki/LlSetTorque

I also vaguely remember Omega being able to do physical wheels, but I could be wrong about that.

Edited October 12, 2021 by Quistess Alpha

[animats]

3 minutes ago, Quistess Alpha said:

llTargetOmega is basically 2 completely different functions depending on whether the object is physical or not.

Right. It actually does move physical prims. Weird.

[gwenavive]

I ended up turning physical off after click when it flies through the air and bumps and rotates before it gets to the head and turning it back on just after setrot and setpos  works well. Thanks everyone