Rotating attached items?

Okay, the concept is extremely simple; I'm trying to create an attachment for a character, which upon a given command will alter it's rotation, another command will put it back again.

The specific case is a tail for a character, which I would like to be raise and lower by changing the tail's position and rotation in relation to the character.

However, despite all my efforts the damned thing won't budge, I can get the script to quite happily spout out messages in response to commands and so-on, but it simply won't move the object.

So, what I'm wondering now is this even possible? I reckon it can be done by causing an object to attach/detach as needed (ie have one model for the raised tail, one for the default tail, attaching the default tail when the script begins and switching as required). However, this seems like an imperfect solution in a way, as the models would be identical and I just want to move them around (which I can do quite happily in edit mode anyway).

Thanks for any help, I can post the script I've got so-far but I doubt it helps anymore to describe my requirements, and it's too broken to be of use to anyone

/142/89/60253/1.html

Right now it can only be done in 1.7. You can have two fixed states and switch between them but thats really it for the moment. Don't worry man, when 1.7 is offical will be your day to shine. ~_^

Cool, can't wait!

I'm actually trying to do it via fixed states now as well, but I'm having trouble with it. What's the best way to set it up to switch individual objects with each state?

For example if I enter the command '/1 raise' I'd like to switch to state 'TailRaised' which would switch the model to that of a raised tail. But I'm not seeing a way to do this, I thought perhaps I could set-up each model to have it's own script (ie it would contain the relevant state) and the main object would contain the script for switching between these, but it won't let me save a script which attempts to change to a state it does not contain within itself.

Can it be done through setting alpha channels, like making the main object invisible but making an object in it's contents visible instead?

This has me really stuck, and I'm actually fairly adept at programming

normally whats done is you make two tails, one up & one down and script them to go invis during their opposite states. Pretty much what everyone does.

Yeah but what should the script look like? The concept I understand just fine, but the llSetAlpha command seems to only work for an owned object, how do I set-up and script the thing to actually work?
An example script would be really helpful, because either the commands I'm finding don't do what I need, or the way to use them is very obscure.

look on the wiki for the keyboard script, that will show you how an attachment can go full alpha based on what the user is doing (the animation playing).

Basically the easiest to do is to make a function to go full alpha, a function to reverse, then you can call the function in your listen event, or on a timer, or when animation changes, etc.

Also . . . you'll probably want to use http://secondlife.com/badgeo/wakka.php?wakka=llSetLinkAlpha rather than llSetAlpha as llSetAlpha only works in the prim that the script is in. (I THINK llSetLinkAlpha works fine in attachments, but haven't tested yet)

Hmm, I've been trying both of those but it doesn't seem to be working for attachments, even a simple script like:

default
{
     touch_start(integer x)
    {
         llSetAlpha(0.0,ALL_SIDES);
    }
}

Doesn't seem to work on a basic attachment, there must be a way though because I've seen loads that can go visible/invisible just fine...

*pokes*

Can nobody show me an example script and describe a set-up for having an attachment change the model it uses? I know that there are objects out there that do what I'm trying to do (there are tails already out there, but the scripts are not modifiable which is no good for me), so it can't be impossible!
I've been trying everything I can think of and I'm getting nowhere, it's not like I've made a half-assed effort and just want everyone to do the work for me

The lack of response from functions that seem like they should happily do what I need is making it especially difficult, if llSetAlpha won't set transparency then what in the hell will?!

Rodrick pointed out what you need: llSetLinkAlpha (and its cousin, llSetLinkColor).

These set the alpha/color components of a linked set of prims. So, you build your tail as two positions, linked together. Tail up, tail down. Then, you just add a script on the root prim that loops through the linked set of prims and sets the alpha to 0.0/1.0 for whatever set of prims comprises the up/down position.

Here's a short snippet of script I used to do color changing on an object:

    for (i = 0; i < llGetListLength (primary_parts); i++)
        llSetLinkColor (llList2Integer (primary_parts, i), pcol, ALL_SIDES) ;
    

Where primary_parts is a list containing the link numbers of the appropriate prims.

Edit: llSetLinkColor, not llSetColorAlpha (?) LOL

w00t thanks! I think I've got the script all sorted now!

Next step though is modelling, are there any good guides for this? The tail is currently a load of spheres but for setting/unsetting transparency this is a bitch because you see each one appear/disappear as the loop goes through, it's also not as good looking as it could be.
I'd like to be able to model the tail is a single large primitive, it's a fox tail if that helps, any idea where/how I'd start modelling that? I can do it in other programs but there doesn't appear to be any import 3d model option.

To speed it up -- possibly unroll the loop a bit, by using multiple scripts to share the load of sending linked messages? Or have the tail prims with individual scripts that respond, instead of making a single script act as the load bearer?

In my case, I didn't mind that the object slowly changed color so that optimization wasn't that necessary.

In the main script:

llMessageLinked(LINK_SET, 0, "", NULL_KEY); // To turn off
llMessageLinked(LINK_SET, 1, "", NULL_KEY); // To turn on

And a script in each prim:

link_message(integer sender, integer num, string message, key id)
{
    if (num == 0)
    {
        llSetLinkAlpha(LINK_THIS, 0, ALL_SIDES);
    }
    else if (num == 1)
    {
        llSetLinkAlpha(LINK_THIS, 1, ALL_SIDES);
    }
}

That should go faster, because the link emssage is sent to every prim at the same time. But you're still not guaranteed perfect synchronization. I use something like this one something I make, and every now and then you'll see some prims lagging behind. If you want it perfect, I think you'll have to make it a single prim. If there is some other way, I don't know it, and would love to learn

Edit: You want some of the prims to go on and off, not all. So use the integer and the string to distinguish between them. So...

llMessageLinked(LINK_SET, 1, "tail up", NULL_KEY); // To move
llMessageLinked(LINK_SET, 0, "tail down", NULL_KEY); // tail up

llMessageLinked(LINK_SET, 0, "tail up", NULL_KEY); // To move
llMessageLinked(LINK_SET, 1, "tail down", NULL_KEY); // tail down

And then in the prims:

string myName = "tail up"; // Put this in every tail-up position prim

...

link_message(integer sender, integer num, string message, key id)
{
    if (string == myName)
    {
        // message is for me, and 'num' and the required alpha
        // value are the same, so just use num directly
        llSetLinkAlpha(LINK_THIS, num, ALL_SIDES);
    }
}

Same thing on the tail down prims, only myName is set to "tail down".

Just so this is known doing object animation by updating positions and rotations or changing alpha; contributes heavily to lag. Having lots of scripts with link message or listen contributes heavily to lag when crossing sim boarders.

My av has different states so i needed something for changing between them. And not wanting to have to do alot of work i wrote this simple script.

It uses prim names to decided if a prim should or shouldn't be effected. It's not very fast but its very easy to setup.

group(list c)
{
    integer a=llGetNumberOfPrims();
    vector color;
    integer b;
    while(a)
    {
        if(b = 1 + llListFindList(c, [llGetLinkName(a)]))
            llSetLinkAlpha(a,llList2Float(c, b),ALL_SIDES);
        --a;
    }
}

default
{
    state_entry()
    {
        llListen(1,"",llGetOwner(), "");
    }
    on_rez(integer a)
    {
        llResetScript();
    }
    listen(integer a, string b, key c, string d)
    {
        if((b = llToLower(d)) == "saddle show")
            group(["Saddle", 1.0]);
        else if(b == "saddle hide")
            group(["Saddle", 0.0]);
    }
}

I didn't know there was an llGetLinkName function. Thanks, this is a good tip to file away.

Ziggy: That's the command I use to build my list that I later use with the color changing. I do it as a seperate pass though, because I keep track of several types of prims as my object has multiple colors. Drop a script that scans links and matches their names by category, and builds a list definition I toss into the actual color changer script.

I figured that was faster in terms of having a bunch of scripts with link_message events that would fire whenever some other link message was sent, or doing as Strife does, asking the name for each link and doing a string comparison.

BTW, Strife, I can understand animated objects and such causing lag, but how do a bunch of prims with link_messages contribute to this? Do prims have to allocate some kind of extra channel to talk via a link message? I figured they came "for free" with the prims, as some kind of build-in IPC-like communication system between prims. The wiki says link messages are "%40 faster" than a listen or IM.

My object uses a listen to send a command to each linked set, which then distributes it via link messages to change the actual color. I really can't think of a faster way and less sim-impacting way to do this.

The sim lag in this case is caused by all the prim updates. It doesn't matter if you use llSetLinkAlpha or llSetAlpha with a link message; all the texture updates have to be sent to all clients within visual range. If they all come at the same time it will be a pocket of lag. Using this in a busy area as a looping animation can generate alot of lag. Object animation is one of the big negatives of SL. Till LL addresses this, object animation isn't viable for mass consumption.

Okay, you're talking about link messages firing prim-changing events (such as color/alpha changes), then? Not the actual link messages causing lag?

I figured link messages weren't replicated at all, and were just server-side. (ergo, free insofar as I am concerned.)

Doing setalpha/color in a loop as some sort of animation, yes I could see this being laggy. In fact, even worse than rotating something (assuming whole-primset rotate that is), as you're firing events for each individual prim.

heh, admittedly, when I saw "tail up/tail down" I thought the OP was asking how to make those changeable tails. And not something that is actually animated...

Personally, I'd just wait to 1.7, when llSetRot() (and I assume llSetLocalRot()) will work for attachments...

The linked message script looks very useful too actually, thanks Ziggy!
I also don't see why it would cause lag, surely the messaging of each primative is handled by Second Life rather than a script, so no listeners are required at all since the call to llMessageLinked() is what then looks to see what primatives we have and trigger any scripts they contain.
And yeah, I am going for a tail that changes position rather than animating, I just want it either up or down, in-between doesn't matter (though if 1.7 lets me move it with an animation then all the better!)

What I'm going for is to try and model the tail as two or three primatives rather than 14 that the original tail (freely copyable so useful as a proto-type) has, even one if I can model it as I require.
One thing about the alpha change system though, is that the other tail is still there but invisible, so it can still be clicked on by accident, is there a function for changing the scale of an object and would this solve the problem? ie after making it invisible I set it's scale to 0.0 (or just set the scale and leave it at that) then when I make it visible again reset its scale to 1.0?

1.7 does sound like it might be a good solution overall, but have we been given any indication as to when it will be released upon us? It sounds like it does what I wanted to do from the beginning but couldn't

If you had a tail like a dog or a fox you could just use llSetLocalRot (yes this funcition works on attachments in 1.7).

you could put this script in the root

//there is a strong posability i got the order of the rotation
//  multiplication wrong or that i have used the wrong axis for the rotation.

vector rot_offset_deg = <0.0,0.0,0.0>;
rotation rot_offset = ZERO_ROTATION;

float tailup_deg;
float taildown_deg;

default
{
    state_entry()
    {
        rot_offset *= llEuler2Rot(rot_offset_deg*DEG_TO_RAD);
        tailup_deg *= PI / 360; //since we make our own rotations we need to devide by 2
        taildown_deg *= PI / 360;
        llListen(1,"",llGetOwner(),"");
    }
    on_rez(integer a)
    {
        llResetScript();
    }
    listen(integer a, string b, key c, string d)
    {
        if("tail up" == b = llToLower(d))
            llSetLocalRot(rot_offset*<llSin(tailup_deg),0,0,llCos(tailup_deg)>);
        else if("tail up" == b)
            llSetLocalRot(rot_offset*<llSin(taildown_deg),0,0,llCos(taildown_deg)>);
    }
}