Dont understand timers

[Max Pitre]

So I hate scripting but sometimes I can butcher simple scripts to meet my needs. 

I have mesh furniture with opening drawers as part of the furniture linkset. I have a real simple script that does a great job opening and closing the drawers on touch. Wish I had the original author for a shout out but I don't. Most drawer scripts don't work for me in this way.

All I want is a simple timer so the drawers do not have to be touched to close but can be if desired. So open on touch but close on either touch or timer. I'm pulling my hair figuring this out. I need help please.

 

integer is_open = FALSE; // assume the drawer starts out closed

default
{
    state_entry()
    {
    }

    touch_start(integer total_number)
    {
        if ( is_open )
        {   // then close the drawer
            llSetPos(<-0.0, 0.0, -0.5> + llGetLocalPos());
            is_open = FALSE;
        }
        else
        {   // open the drawer
            llSetPos(<0.0, 0.0, 0.5> + llGetLocalPos());
            is_open = TRUE;
        }
    }
}

[Innula Zenovka]

Timers are pretty simple, really.   The call llSetTimerEvent(n) means "Set an alarm to go off every n seconds and, when it does, carry out the instructions in the timer() event handler.

So, schematically, your script needs to look something like

touch_start(integer total_number)
{
		
		if(is_open){
			//do stuff to close the drawer
			llSetTimerEvent(0.0);//and turn off the timer if it's running
		}
		else{
			//do stuff to open the drawer
			llSetTimerEvent(5.0);//set a timer to go off in 5 seconds' time
		}
		is_open = !is_open;//switch the value of is_open
}

timer()
	{
		if(is_open){
			//do stuff to close the drawer;
			llSetTimerEvent(0.0);//and turn off the timer, since it's no longer needed
		}
	}

 

[Rolig Loon]

It's not hard ....

 

integer is_open = FALSE; // assume the drawer starts out closed
default
{
    touch_start(integer total_number)
    {
        if ( is_open )
        {   // then close the drawer
            llSetPos(<-0.0, 0.0, -0.5> + llGetLocalPos());
            is_open = FALSE;
            llSetTimerEvent(0.0);  // Turn the timer off, since you don't need it now
        }
        else
        {   // open the drawer
            llSetTimerEvent(4.0);  // Start the timer, ready to close in 4 seconds
            llSetPos(<0.0, 0.0, 0.5> + llGetLocalPos());
            is_open = TRUE;
        }
    }
    timer()
    {
        llSetPos(<-0.0, 0.0, -0.5> + llGetLocalPos());
        is_open = FALSE;
       llSetTimerEvent(0.0);    // All done. Turn off the timer
    }       
}

It's just a matter of thinking through what actions should start and stop the timer.

Aside from the business of the timer, I suggest taking another look at the way you open and close the drawer. You are always using the drawer's current local position as the starting point for movement, and the applying an offset to it.  It's much safer to establish a fixed position that is closed (and probably a fixed position that is open too) instead of calculating it each time. Not only is that more efficient, it also avoids the problem of drift, which will eventually make your calculations wrong.

EDIT:  HAH!  Innula got here a hair ahead of me with the same response. 

Edited September 7, 2017 by Rolig Loon

[Max Pitre]

"pretty simple" and "not hard" are relative terms.

 

Thanks so much you two. I see what I was doing wrong the whole time was not adding in the additional close. Now it does seem "simple" and "not hard" 

Rolig, what do you mean  by drift, I have never had an issue with this script other than the timer. I can move the whole linksets around, rerez, copy or whatever and the drawers always open and close correctly as long as the drawers are child prims. 

[Rolig Loon]

Prim drift is a very common problem in SL. Basically, it means that prims don't stay put over time unless they are locked (and sometimes not even then). Remember, all of these objects that we "see" are really numerical constructions in servers. As things change in a region,  a certain amount of error gradually creeps in, so that prims don't necessarily stay where you left them.  Builders curse at this all the time. As a scripter, you learn to compensate by providing some fixed values that you can use to force things back to known positions every once in a while.  For something as small as a drawer, prim drift is likely to be small enough that you can ignore it most of the time. If you're building larger things like houses or bridges, it's something to worry about.  In any case, it's good practice to provide fixed points where you can, rather than letting object positions float.

[Max Pitre]

Interesting...a glitch in the Matrix so to speak

 

[Rolig Loon]

Quite.

[Innula Zenovka]

Prim drift apart, I was a bit surprised by the contents of the llSetPos() calls.     They work for you because of your build's particular construction --telling a regular prim to execute llSetPos(<0.0, 0.0, 0.5> + llGetLocalPos()); will normally make it rise 0.5 metres up in the air.

If I were making something like this using conventionally rotated box prims -- that is, I want the drawer to open by moving forwards on its own positive x axis -- I might use something like this,  if I wanted to have the script in the drawer prim rather than the root:

integer iOpen;
vector vClosed;
vector vOpen;
default
{
    state_entry()
    {
       vClosed = llList2Vector(llGetLinkPrimitiveParams(LINK_THIS,[PRIM_POS_LOCAL]),0);
       vOpen = vClosed +<0.25,0.0,0.0>;//move 0.25 metres on my positive x axis
    }

    touch_start(integer total_number)
    {
        
        if(iOpen){
            llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_POS_LOCAL,vClosed]);
        }
        else{
             llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_POS_LOCAL,vOpen]);  
        }
        iOpen = !iOpen;
    }
}

Since yours works, though, I think it's best to leave well alone -- I'm a great believer in "if it ain't broke, don't fix it, and particularly not if you're not sure what you're doing." but I would stress that your script works for your particular set-up and probably won't transfer well to another build of a different design.

Edited September 7, 2017 by Innula Zenovka

[Max Pitre]

I think it works because it's all mesh and I find mesh doesn't always act like a regular prim.  On some mesh builds I do need to change it to the X axis. Not sure why to any of it as I use only one program to build and build everything within that program the same way. 

[arton Rotaru]

2 hours ago, Max Pitre said:

I think it works because it's all mesh and I find mesh doesn't always act like a regular prim.  On some mesh builds I do need to change it to the X axis. Not sure why to any of it as I use only one program to build and build everything within that program the same way. 

With mesh it's up to you how your mesh is orientated indeed. If it imports with an undesired axis alignment, you haven't paid enough attention while creating it.

[Rolig Loon]

13 minutes ago, arton Rotaru said:

If it imports with an undesired axis alignment, you haven't paid enough attention while creating it.

Indeed.  In this case, it looks as if the local Z axis of the drawer must be horizontal instead of vertical. You should be able to check that if you open your editor and set it to show orientations in the LOCAL framework instead of the GLOBAL one.  I find that creators who use Maya tend to build mesh with the Y axis vertical, which forces me to think twice as I'm scripting their stuff.

[Max Pitre]

19 hours ago, arton Rotaru said:

With mesh it's up to you how your mesh is orientated indeed. If it imports with an undesired axis alignment, you haven't paid enough attention while creating it.

Good point. Just checked my program and I probably was not paying attention. 

19 hours ago, Rolig Loon said:

Indeed.  In this case, it looks as if the local Z axis of the drawer must be horizontal instead of vertical. You should be able to check that if you open your editor and set it to show orientations in the LOCAL framework instead of the GLOBAL one.  I find that creators who use Maya tend to build mesh with the Y axis vertical, which forces me to think twice as I'm scripting their stuff.

In C4D the Y axis is vertical too. I don't see anyway to change that or any mention of LOCAL and GLOBAL within the preferences. No worries, I've learned much, thank you all.

[Rolig Loon]

You'd have to change it in C4D.  There must be a way.  There is one in Blender, and I know you can do it in Maya. (Not being a Maya user, I can't tell you what it is, though.)