sliding door script- adding auto close

[Annabell Wandsworth]

Hi all

I found a script that works great with linked prims, but there is no auto close. I have tried to paste in elements from other scripts for the auto close function, but I'm not a scripter so I'm missing something. I would appreciate any guidance, and thanks for your time.

Here is the script:

integer isOpen = FALSE;
vector originalPos;
float slideBy = 1.5;
init()
{
    originalPos = llGetLocalPos();
    vector size = llGetScale();
    // Set up the amount to move by. Use size.y instead of size.x
    // if you want to slide along the y-axis.
    slideBy = size.x - 0.2;
}
openclose()
{
  if (isOpen)
  {
    llSetPos(originalPos);
    isOpen = FALSE;
  }
  else
  {
    llSetPos(<originalPos.x + slideBy, originalPos.y, originalPos.z>);
    // To move alon the y-axis, use this instead:
    // llSetPos();
    isOpen = TRUE;
  }
}
default
{
    state_entry()
    {
        init();
    }
    on_rez(integer param)
    {
        init();
    }
    touch_start(integer total_number)
    {
        openclose();
    }
    changed(integer change)
    {
        // When the links change, reset the script
        // so that we pick up the changes.
        if (change & CHANGED_LINK)
        {
            llResetScript();
        }
    }
}

[Love Zhaoying]

Where you set isOpen=true, set a timer. In the timer event, turn off the timer and call OpenClose() again.

[Annabell Wandsworth]

Awesome I'll try that. Thanks!

 

[Rolig Loon]

And don't forget to turn the timer off again, or the door will keep opening and closing until the end of time.

[Love Zhaoying]

18 minutes ago, Rolig Loon said:

And don't forget to turn the timer off again, or the door will keep opening and closing until the end of time.

I should have numbered my points to miss that one!

[Annabell Wandsworth]

I've been reading some tutorials trying to understand how scripts are composed, so hopefully I can get a little farther now.

You said "Where you set isOpen=true, set a timer. In the timer event, turn off the timer and call OpenClose() again."

Do I put the timer event inside that event, or do I make a new event for the timer? Sorry if I am not saying this right. I appreciate your help and am really trying to learn and not just ask for a complete fix.

For example, can it be this?

if (isOpen)
  {
    llSetPos(originalPos);
    isOpen = FALSE;

    llSetTimerEvent(AUTO_CLOSE_TIME); 

  }

 

(when I define the auto close time at the top of the script)

Edited February 16, 2018 by Annabell Wandsworth

[Annabell Wandsworth]

sorry I'm confused!

[Rolig Loon]

Exactly. That will trigger a timer event. Then you need to actually write the timer event itself. In that event  you only need two things. One is the call to your closing door function. The other is simply a statement to stop thw timer.

Edited February 16, 2018 by Rolig Loon

[Annabell Wandsworth]

Ok, so I add the timer event inside if (isOpen) as I wrote before, but I need to create a timer event also?

[Rolig Loon]

Yes. You have llSetTimerEvent correctly but now you neef to write the event.

[Annabell Wandsworth]

great, thanks. i will try to make that.

[Love Zhaoying]

timer() {

  llSetTimerEvent(0.0);

  OpenClose();

}

[Annabell Wandsworth]

Ok, I added Love's timer event with the stuff I listed before, but I must have put (maybe the timer event) in the wrong place or way because I got a syntax error at 14,0

integer isOpen = FALSE;
vector originalPos;
float slideBy = 1.5;
integer    AUTO_CLOSE_TIME = 8;         // Can be zero if no auto-close is desired

init()
{
    originalPos = llGetLocalPos();
    vector size = llGetScale();
    // Set up the amount to move by. Use size.y instead of size.x
    // if you want to slide along the y-axis.
    slideBy = size.x - 0.2;
}

timer() 
{

  llSetTimerEvent(0.0);

  OpenClose();

}

openclose()
{
  if (isOpen)
  {
    llSetPos(originalPos);
    isOpen = FALSE;
     llSetTimerEvent(AUTO_CLOSE_TIME); 
  }
  else
  {
    llSetPos(<originalPos.x + slideBy, originalPos.y, originalPos.z>);
    // To move alon the y-axis, use this instead:
    // llSetPos();
    isOpen = TRUE;
  }
}
default
{
    state_entry()
    {
        init();
    }
    on_rez(integer param)
    {
        init();
    }
    touch_start(integer total_number)
    {
        openclose();
    }
    changed(integer change)
    {
        // When the links change, reset the script
        // so that we pick up the changes.
        if (change & CHANGED_LINK)
        {
            llResetScript();
        }
    }
}

[Love Zhaoying]

Since timer() is an event, it goes inside the state. Put it somewhere under “state default {“ - those other functions inside the state are events, too. You could put it at the very end right before the last closing “}”.

[Annabell Wandsworth]

so inside state default but outside state entry?

[Rolig Loon]

Yes. Study the structure of LSL.  A script must have at least one state, called default, which is a container for the events in which all the work is done. An event, like a timer or a touch_start,  contains statements that will all be executed in response to a specific trigger in the environment. The timer event is a block of commands triggered by the passage of time ... the time that you set with the llSetTimerEvent statement. So, that event that Love wrote out for you is an independent block within state default, just like the touch_start event.

Edited February 16, 2018 by Rolig Loon

[Annabell Wandsworth]

Yes, I think I understand about default state, but there can also be different states, so I'm still a little confused and trying to learn.

I do appreciate the help of everyone here. I have noticed in other posts while searching that some seem to say "just fix it!" instead of trying to understand, and I don't want to be like that.

[Rolig Loon]

You are doing fine. I just hope that Iam being helpful enough. It is frustrating to type meaningful responses on a smart phone when I am away fom my computer. ?

[Rolig Loon]

I suggest going to the Tutorials tab at  the top of the LSL wiki and looking for a basic LSL tutorial so that you see how the structure of states and events works. It's the heart of LSL. I would give yiu a specific URL, but that is beyond my phone's ability. Or mine anyway.

[Annabell Wandsworth]

I have been using those, or I would not have gotten this far (far?? lol)

[Love Zhaoying]

1 hour ago, Annabell Wandsworth said:

Yes, I think I understand about default state, but there can also be different states, so I'm still a little confused and trying to learn.

I do appreciate the help of everyone here. I have noticed in other posts while searching that some seem to say "just fix it!" instead of trying to understand, and I don't want to be like that.

I suggest you don’t worry about states besides “default” until you need to. I rarely, rarely use any states but default.

[Rolig Loon]

43 minutes ago, Love Zhaoying said:

I suggest you don’t worry about states besides “default” until you need to. I rarely, rarely use any states but default.

I agree that most scripts that use multiple states could be written much more simply with one.  There are, however, some good excuses for having several states.  Among them:

1. Keeping all one-time "startup" operations in a single state that you never visit again unless the script restarts.  This can be particularly helpful, for example, in a vendor script that must first get PERMISSION_DEBIT from the owner.

2. Preventing users from spam-clicking your object, by switching to a second state that has no touch* event.

3. Separating unrelated operations such as landing or launching a vehicle from the major functions involved in moving the vehicle in regular flight.

4. Isolating operations that should only be accessible to one user (or group of users) from the others.

5. Making it easier to see script logic by treating blocks or modules of code separately.

There are of course downsides to having multiple states as well, so there can be no firm rules about how one scripter's use of states is "better" than another's.

[Rolig Loon]

1 hour ago, Annabell Wandsworth said:

I have been using those, or I would not have gotten this far (far?? lol)

That's great.  I thought maybe you had been, but I wanted to be sure that you didn't miss an obvious resource.

OK, so the schematic structure for a basic LSL script like yours would look like this
 

// Global variables, which will be accessible in ALL parts of your script (states and events)

// User defined functions ( like your openclose() function )

default
{
    state_entry()
    {
        //Operations that will be executed when the script restarts or when execution enters this state
    }

    touch_start(integer num)
    {
        // Operations that will be triggered if someone left-clicks on yhe object
    }

    changed (integer change)
    {
        // Operations that will be triggered by specific changes in the object (color, inventory contents, ownership ... )
    }

    timer()
    {
        // Operations that will be triggered whenever the "stopwatch" time established in a llSetTimerEvent statement runs out
    }

   other events
}

Notice that each state and each event is a self-contained block of statements, bounded by {curly brackets} that define the scope of the state or event.  Anything that happens within a scope must be executed completely before the script moves on to do something else.  That is, you cannot jump into and out of any event or state until the script has finished doing whatever triggered the events in its scope.  Most of the time, any script is doing absolutely nothing at all --- just waiting for some triggering change in the environment to start executing the statements in one or another of its events.

I hope that helps a little. 

 

 

[Annabell Wandsworth]

I hear what you are saying about states, but I'm just trying to understand it.

[Rolig Loon]

Tell me what's confusing you.

If it helps, think of states by analogy with geography, where the word "state" has a different meaning but shares some similarities.  You write your script to always start in state default (say, New York).  As long as you never leave that state, any operations that take place in events (operas, baseball games ... ) only affect that state.  If you cross state lines, you may have a totally separate set of rules and potential events in the  new state.  So, the scope of each state is isolated from the scope of each other state, just as the states in the US are isolated from each other.  For purposes of this analogy, the only thing that makes the default state special is that default will always be "square one", where the script wakes up if you restart it.  As Love points out, you may rarely need to consider the possibility of other states at all.  As I said above, though, it can be handy sometimes to divide your script's work among multiple states if you feel the need.