Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

locket script doesn't work when on AV

Valentina Kendal
Registered User
Join date: 6 Oct 2007
Posts: 4
04-17-2008 12:26
I wanted to make a locket that would open while on an AV, no matter the orientation of the AV relative to the world axes. I used the rotation script by Sue Stonebender posted here, that rotates a child prim versus the parnet:

/15/e4/138010/1.html

Everything works great - I can rotate the locket any way and it still open fine. However, as soon as I attach to my AV, the locket opens incorrectly, even if I reset the script while wearing it. I am not much of a scripter, just make pretty shiny things. Can anyone help?

Val Kendal
Qie Niangao
Coin-operated
Join date: 24 May 2006
Posts: 7,138
04-17-2008 14:07
I think the simple fix is to just remove the definition of the LocalRot function altogether, and replace open() and close() as follows:

open(string door)
{
llSetLocalRot(llEuler2Rot(r_open * DEG_TO_RAD));
}

close(string door)
{
llSetLocalRot(llEuler2Rot(r_closed * DEG_TO_RAD));
}

(What I'm a little puzzled by, though, is why the script was written the way it was, inasmuch as llSetLocalRot() has been around since 1.5.4... so maybe there's something subtle.)

Why the problem, Part 1: When run in an attachment, llGetRot() returns the rotation of the *avatar*, not of the root prim of the attachment.

Why the problem, Part 2: So, one might be tempted to use llGetRootRotation() which does get the rotation of that root prim (relative to the attachment point).
  • But the original code used llSetPrimitiveParams() which, like llSetRot() in a child prim is subject to http://jira.secondlife.com/browse/SVC-93. Now, one could correct for that bug, but there's the much simpler llSetLocalRot() built in already, and since we're not doing anything else in llSetPrimitiveParams(), I don't think we benefit from the added complexity.

    For someone more patient: Probably the script doesn't belong in the child prim at all, but should be done with an llSetLinkPrimitiveParams() from the root, assuming there's other stuff happening in the root object, and assuming the 0.2sec delay per call isn't a problem. But then one really would have to use the workaround to SVC-93, I think.
    _________
    * EDIT: Oops. Guess it doesn't, contract notwithstanding. Per SVC-93: "llGetRootRotation does not return a meaningful result for child prims in attachments."
  • Valentina Kendal
    Registered User
    Join date: 6 Oct 2007
    Posts: 4
    04-18-2008 05:16
    thanks Qie!

    >Why the problem, Part 1: When run in an attachment, llGetRot() returns the rotation of the >*avatar*, not of the root prim of the attachment.

    That certainly explains the child's behavior. I will try what you suggest, keeping my amateur fingers crossed. I haven't found a simple script yet that does what I want - there are lockets for sale out there, but they are no MOD, which means I can't see how they implemented the action.

    Update: Thanks! It worked! you saved my ass - now I can deliver this wedding present on time! - Val
    Tecak Oyen
    Registered User
    Join date: 13 Jun 2007
    Posts: 18
    04-18-2008 08:26
    The way I got around this problem in a pocket watch that had many prims was to send the root's rotation to the child prims in a linked message when the object was attached and use that instead of llGetRootRotation, which is broken for attachments.

    This solution worked for me.

    I used llSetPrimitiveParams in the child prims because I was changing the rotation and position of several prims at once and wanted a smooth effect without the 0.2 second delay.