Jump to content

scripting a door inside linked prims


Sartek Rosca
 Share

You are about to reply to a thread that has been inactive for 3206 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Warning: I'm quite new to LSL scripting.

 

I created a simple sliding door script, that does exactly what I want and uses the llGetLocalPos and llSetPos functions to change it's position. This door is part of a little cabin i'm creating. The door operates on a simple touch, nothing fancy.

However, when I link the door with the cabin, the script doesn't work and my door doesn't move. The door is NOT the root prim of the cabin.

I notice that when I hover my mouse cursor of the door, it changes to the "hand" icon, which is typical for objects that can be touched. So the script is somehow active.

As soon as I unlink the cabin, I can click the door and it slides again.

Also, the door is a single prim, so don't point me to scripts for "multiprim doors", as this is something different from my issue.

 

I hope someone here can shed some light on how to do this. I tried Google, but I get a lot of references to the lsl wiki about the different ll-functions, but not a single introduction on how it all fits together.

 

Thanks for any assistance.

 

 

 

Link to comment
Share on other sites

It doesn't make any difference whether the door is a single prim or has multiple prims.  For a multiprim door script, a single prim is just an easy simple case.  Take a good look at https://community.secondlife.com/t5/LSL-Library/Linkable-Multiprim-Sliding-Door/m-p/722649 , which is about as simple as a sliding door script can be.  If there's only one prim named "DOOR", that's all it will move.  If you never expect to have more than one prim in a door, you can simplify the script by removing the for loop, but that's not really necessary.

Link to comment
Share on other sites

The usual reason llSetPos would silently fail is that you're trying to move the prim more than 10 metres (though you may well not realise that's what you're trying to do).    While I can think of several ways a a sliding door script that works well unlinked might go wrong when you link it to the build, I'd normally expect it to move, though probably not where you expect it to go.   

Without seeing your script it's impossible to guess what's going wrong.    If you want to post it here, we can help.   Otherwise, when I am trying to debug this sort of thing, I find it helpful to put lots of llOwnerSay()'s to tell me where the script thinks I'm telling it move the uncooperative prim.

Link to comment
Share on other sites

Hi,

 

Here is the door script. Like I said, it works just fine as long as the door is not linked into the cabin structure.

float  delay = 3.0;                         // time to wait before                                             // automatically closing door                                           vector delta = <0.0, -0.8, 0.0>;             // amount to move door                                             // when we open it// Variables you will most likely leave the samevector closed_position;                     // original position of the                                             // door when closed// Processing for the script when it first starts updefault {    // What we do when we first enter this state    state_entry() {        closed_position = llGetPos();      // Save position when door is closed        state closed;                      // Move to the closed state    }}// Processing for the script when it is in the closed statestate closed {    // What we do when we first enter this state    state_entry() {        llSetPos(closed_position);           // Move door to closed position    }    // What we do when the door is clicked ("touched") with the mouse    touch_start(integer total_number) {        state open;                        // Move to the open state    }    // What to do when the timer goes off    timer()    {        llSetTimerEvent(0.0);              // Set the timer to 0.0 to turn it off    }}// Processing for the script when it is in the open statestate open {    // What we do when we first enter this state    state_entry() {        llSetPos(closed_position + delta); // Move door to open position        llSetTimerEvent(delay);            // Set the timer to automatically close it    }    // What we do when the door is clicked ("touched") with the mouse    touch_start(integer total_number) {        state closed;                      // Move to the closed state    }    // What to do when the timer goes off    timer()    {        llSetTimerEvent(0.0);             // Set the timer to 0.0 to turn it off        state closed;                     // Move to the closed state    }}

Also, replacing llGetPos with llGetLocalPos doesn't solve it.

 

 

Link to comment
Share on other sites

I can't come in yet to test it, but I think it needs a changed event in state open and (more importantly) in state closed, to reset the script and re-read vector delta closed_position when you link the door to the build.  

As it is, I think what's happening is that you're putting the script into the unllinked door prim, and it's reading either llGetPos or llGetLocalPos and setting a region position as vector closed_position.  It then goes into state closed and stays there, so that when you link the prim to the main build it thinks the region position is the distance you want it to move from the root prim.   That's almost always going to be more than 10 metres (depending where you were on the region when you put the script into the door in the first place), so it fails silently.

Anyway, try this slight revision of your script.

   
float  delay = 3.0;                         // time to wait before// automatically closing doorvector delta = <0.0, -0.8, 0.0>;             // amount to move door// when we open it// Variables you will most likely leave the samevector closed_position;                     // original position of the// door when closed// Processing for the script when it first starts updefault {    // What we do when we first enter this state    state_entry() {        closed_position = llGetLocalPos();      // Save position when door is closed        state closed;                      // Move to the closed state    }}// Processing for the script when it is in the closed statestate closed {    // What we do when we first enter this state    state_entry() {        llSetPos(closed_position);           // Move door to closed position    }    // What we do when the door is clicked ("touched") with the mouse    touch_start(integer total_number) {        state open;                        // Move to the open state    }    changed(integer change){   //<= add this new  event        if(change & CHANGED_LINK){            llResetScript();        }    }  // end add this new  event    // What to do when the timer goes off    timer()    {        llSetTimerEvent(0.0);              // Set the timer to 0.0 to turn it off    }}// Processing for the script when it is in the open statestate open {    // What we do when we first enter this state    state_entry() {        llSetPos(closed_position + delta); // Move door to open position        llSetTimerEvent(delay);            // Set the timer to automatically close it    }    // What we do when the door is clicked ("touched") with the mouse    touch_start(integer total_number) {        state closed;                      // Move to the closed state    }    changed(integer change){   //<= add this new  event        if(change & CHANGED_LINK){            llResetScript();        }    }  // end add this new  event    // What to do when the timer goes off    timer()    {        llSetTimerEvent(0.0);             // Set the timer to 0.0 to turn it off        state closed;                     // Move to the closed state    }}

That should fix it, I think.

ETA:   If you'd put the script into the door prim after it was linked to the build, I think it would have worked.  

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3206 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...