Opinion Sought on Sliding Window or Door Script

I cobbled the following script together from bits and pieces - the locking and unlocking functions owe a good deal to Seagel Neville's single prim double door script.

It seems to work fine (the example below allows me to slide a two-prim sash window up 1.4 metres). I was surprised that it worked on a linked object. Also it closes to its original position even if it has been left open in a previous session. I was expecting to have problems with both of those features.

However, I would appreciate any opinions that might optimise or improve it since there will be over a hundred mono compiled copies of it in my house - half of them sliding up and the other half sliding down.

Also, it would be good to file a tidy version somewhere for others to use if they find it useful.

         vector delta = <0.0, 0.0, 1.4>;
         vector closed_position;
         
         integer pitch = 5;
         integer TouchFlag;
         integer Holding;
         integer SecureFlag;
         
         Open()
         {
         	TouchFlag = TRUE;
         	integer i;
         	for(i = 0; i < pitch + 1; i++)
         	{
         		llSetPos(closed_position + delta);
         		}
         		}
         
         
         Close()
         {
         	TouchFlag = FALSE;
         	integer i;
         	for(i = pitch - 1; i >= 0 ; i--)
         	{
         		llSetPos(closed_position);
         		}
         		}
         
         
         TouchOpen()
         {
         	if(TouchFlag == FALSE)
         	{
         		Open();
         	}
         	else
         	{
         		Close();
         	}
         }
     
         
         Init()
         {
         		closed_position = llGetPos();
         		}
     
         
         default
         {
         	state_entry()
         	{
         		Init();
         	}
         	changed(integer change)
         	{
         		if(change & CHANGED_OWNER)
         		{
         			llResetScript();
         		}
         	}
         	touch(integer total_number)
         	{
         		if(llDetectedKey(0) == llGetOwner())
         		{
         			Holding++;
         			if(Holding == 50)
         			{
         				if(SecureFlag == FALSE)
         				{
         					llOwnerSay("Lock");
         					SecureFlag = TRUE;
         				}
         				else
         				{
         					llOwnerSay("Unlock");
         					SecureFlag = FALSE;
         				}
         			}
         		}
         	}
         	touch_end(integer total_number)
         	{
         		Holding = 0;
         		if(SecureFlag == FALSE)
         		{
         			TouchOpen();
         		}
         		else
         		{
         			if(llSameGroup(llDetectedKey(0)))
         			{
         				TouchOpen();
         			}
         			else
         			{
         				llWhisper(0, "The window is secured.");
         			 }
         		}
         	}
         }
         

Note: In fact there is a problem with holding to lock or unlock the window whereby the frame will slide up as soon as the left-click to hold action is completed. It has to be touched again to shut it properly.

Is there any way to differentiate touch from holding so this doesn't happen?

Here's an alternate method. Use the time functions along with touch_start/end() Downside is the owner doesn't get feedback until touch_end().

Also, I removed the Init() function. The problem with that is people will move the object after the "closed_position" has been set. That'll be a problem. So, replaced closed_position altogether with plain ol' llGetPos().

Also, modified the loops in the Open/Close functions. And thanks to Void below, I knew there was something fishy about those loops that didn't do anything. So combined into a single Action function.

vector delta = <0.0, 0.0, 1.4>;

integer isOpened;
integer isLocked;


Action()
{
if(!isOpened)
{
llSetPos(llGetPos() + delta);
}
else
{
llSetPos(llGetPos() - delta);
}
isOpened = !isOpened;
}


default
{
touch_start(integer total_number)
{
if(llDetectedKey(0) == llGetOwner())
{
llResetTime();
}
}
touch_end(integer total_number)
{
   key id = llDetectedKey(0);
   if (id == llGetOwner())
   {
      if (llGetTime() > 2.0)
      { 
         isLocked = !isLocked;
         llOwnerSay(llList2String(["Unlock","Lock"], isLocked));
      }
      else
      {
         Action();
      }
   }
   else if (!isLocked || llSameGroup(id))
   {
      Action();
   }
   else
   {
      llWhisper(0, "The window is secured.");
   }
}
}

Thanks for that, DoteDote. It appears to work beautifully now.

Would you like a set of six sculpted sash windows with atrociously weathered paintwork on the outside? If a good paint job is your bag, I can modify the textures so you don't get shamed in front of the neighbours.

The textures are sheeted - 3MB for two frames and four windows and two very small 64 x 64 sculpt meshes for the parts. The LOD is very high so they will look fine from the furthest side of the sim.

open() and Close() can both be collapsed into a single function and use a do-while or @-jump loop, (multiple delta by your touch flag, and use touchFlag = !touchFlag to switch) and you can probably inline it too. in fact it seems you were intending to use those loops to incrementally open and close the window, but don't use the counters for them, so they don't actually do that, and instead just open or close multiple times to the same position.

the reason it still opens after hold to secure is because the owner is in in the same group and thus gets ignored for security features and opens despite the secure flag being set.
you can either force an extra open logic swap (so that it closes in touch end) or use in owner as an addition text for both cases in the touch end event.

also, using just the boolean, or the not symbol with the boolean is faster and smaller than using a == comparison.

you also don't need to reset the script on changed owner, since you don't actually store it but rather check it every time.

so here's how I would modify it.
UPDATED!

vector  gOfsOpened = <0.0, 0.0, 1.4>;
integer gIntHeld;
integer gBooOpen;
integer gBooLock;
string  gStrStatus = "UnLocked"; 
//-- will be parsed as "Lock", "UnLock", "Locked", and "UnLocked" as needed

default{
    touch( integer vIntTotal ){
        //-- count for all holds to cut down on function calls/comparisons
        ++gIntHeld;
        if (50 == gIntHeld){
            //-- get sub string is just a fancy way of using the same data for different calls
            llWhisper( 0, llGetSubString( gStrStatus , 2 * (!gBooLock), -3 ) + " request registered." );
            //-- used whisper so other users don spam the owner
        }
    }

    touch_end( integer total_number ){
        key vKeyTest = llDetectedKey( 0 );
        //-- if (un)lock request triggered, and it's the owner letting off
        if (50 <= gIntHeld && llGetOwner() == vKeyTest){
            gBooLock = !gBooLock; //-- swap the boolean value
            //-- get sub string is just a fancy way of using the same data for different calls
            llOwnerSay( llGetSubString( gStrStatus , 2 * gBooLock, -1 ) );
        //-- if it's someone in the gorup, or the wind isn't locked
        }else if (llSameGroup( llDetectedKey( 0 ) ) || !gBooLock ){
            //-- ((gBooOpen = !gBooOpen) * 2 - 1) = 1 when opening, -1 when closing
            //-- extra * local rot is to fix the position for tilted windows
            llSetPos( llGetPos() + (((gBooOpen = !gBooOpen) * 2 - 1) * gOfsOpened * llGetLocalRot()) );
        //-- the window lock wasn't just changed, it's locked and you aren't in the same group
        }else{
            llWhisper( 0, "The window is secured." );
        }
        gIntHeld = 0;
    }
}

ETA:
there is an edge case where another user hay hold down and trigger the (un)lock request, and then the owner can set it by clicking to open/close while the other user is still holding down and complete the request, but I figured it was worth the slight chance to cut down on the amount of function calls and tests that are being repeated rapid fire.

Thanks for that, Void. I'm still trying to work out why it works because DoteDote's edit more closely resembles my OP, which I kind of understand.

There are a couple of typos ('Holding = 0' and 'gBooLocked') in your example but I got there in the end.

With this edit, I still have trouble when holding to lock or unlock: the window chats out a stream of locked, unlocked, locked, unlocked messages and depending on which it finishes on, it is then likely to slide up or down in the wrong direction:

      vector vOfsOpened = <0.0, 0.0, 1.4>;
     integer gIntHeld;
     integer gBooOpen;
     integer gBooLock;
     
     default
     {
     touch(integer vIntTotal)
     {
     if (50 == gIntHeld)
     {
     gBooLock = !gBooLock;
     gBooOpen = !gBooOpen;
     llOwnerSay("The window is " + llGetSubString("unlocked.", 2 * gBooLock, -1 ));
     }
     else if (llDetectedKey(0) == llGetOwner())
     {
     ++gIntHeld;
     }
     }
     
     touch_end(integer total_number)
     {
     gIntHeld = 0;
     if (llSameGroup(llDetectedKey(0)) || !gBooLock)
     {
     llSetPos(llGetPos() + (((gBooOpen = !gBooOpen) * 2 -1) * vOfsOpened * llGetLocalRot()))
     }
     else
     {
     llWhisper(0, "The window is secured.");
     }
     }
     }
      

Note: I also tested locked versions of my original, DoteDote's version and yours using an alt with his group disabled. The locking system only works on my version: the little smartass was able to the open and close the windows running DoteDote's and your scripts.

updated mine with the noticed goofs, and the capitalized if I caught.

sorry about the reverse shift, I was changing gears mid stream on the issue of using current position, (as I do in my simple door script) and not thinking about it.

I like DoteDote's touch and time( much more code efficient ), but left mine as is in case you wanted feedback to the locking mechanism triggering(although it may run a lot faster now so you might need a bigger number).

if there's a section you want broken down better, just shout, and I'll parse it all out.

PS both versions are allowing people outside the group to change after it's locked? they shouldn't from anything I see.

ETA:
just test my version, locking correctly ignored users without group tags on for open/close (including the owner) for objects set to a group

Thanks for that. Unfortunately it still refuses to validate on save. This line seems to be giving the problem:

 llSetPos( llGetPos() + (((gBooOpen = !gBooOpen) * 2 - 1) * gOfsOpened * llGetLocalRot()) );
 

I declared 'gfsOpened' at the outset since that was throwing up a 'Name not defined within scope' error and I figure it was probably just an oversight on your part. I also tried omitting llGetLocalRot() since it doesn't appear to be necessary and you already used llGetPos() so I didn't think to replace it with anything.

Still no joy though: the error warning on that was 'Type mismatch'.

did you copy it or just the newer parts? (I changed gOfsOpened from vOfsOpened to match the naming convention)

because I just double checked and it runs fine for me from c&p (though for some weird reason it inserts extra line breaks if I copy straight from the post)

running:
Second Life 1.21.6 (99587) Oct 14 2008 17:42:25 (Second Life Release)
Second Life Server 1.26.3.118673

Thanks again, Void. And thanks for including the notes, by the way, those will probably be just as useful to me as the working script itself.

This version works perfectly and the movement looks absolutely fine. I notice that an object will shoot to its new position real fast on the first open regardless of which script I've used. After that the movement is always smooth and easy for that session. Perhaps it's one of those little SL bugs?

I also tried a locked setting with the smartass alt and he couldn't get it to open without wearing the home group tag.

Note: I copied the earlier version straight the first time and made no changes, which I always refrain from doing until a script saves. Maybe it's one of those odd glitches: I've seen a word space added between the 'G's in GET_PERMISSION_TRIGGER_ANIMATION when I've posted scripts in the past.

It will be interesting to see what DoteDote has to say about the failure to lock if he/she is online anytime soon.

By the way, could you use a set of sculpted windows when I get the texturing done? At five prims each they look good, if a little dilapidated, on a Georgian style building or the Brownstone style favoured on the East Coast of Murka.

sure why not =)

honestly I can't see why Dote's would fail the group test either but :: shrug ::

mostly I did it as a fun one off, but also because the idea help with my own script sets when I set up a builders package (I'm going to try to do all the basics, all door variants, window variants, wallpaper swappers, color changers, light scripts, locks, auto config house-porters, rez boxing, etc ad nauseam) all black boxed and COPY TRANSFER taking link messages, with some basic control examples. all optimized to a tee, and set for low lag and minimal memory needs. (got any ideas for basic house scripts I missed?) sell it as a builders kit complete with instructions and help cards for end users. maybe throw in my 10 prim modable minimalist modern Grandfather clock for the heck of it =)

I think I got the SecureFlag reversed. I had:

llOwnerSay(llList2String(["Lock","Unlock"], SecureFlag));

So, it reported "Lock" when it was unlocked, and "Unlock" when locked. If that's not it, then I don't know. Don't have SL at RL work to troubleshoot. It should be:

llOwnerSay(llList2String(["UnLock","Lock"], SecureFlag));

Thanks for that, DoteDote. It's very late in my neck of the woods but I'm looking forward to trying that first thing. I truly appreciate your responses along with Void's. It's invaluable to compare the two very different approaches.

Copies to both of you sometime over the weekend then.


Now that I would go for. I don't see myself getting into selling building products but a full set of related scripts to use at home would be worth a good price.

I hope it isn't too far down your 'to do' list? The only thing I can think of would be an option to build a menu system for controlling everything from a single source. It's kind of obvious so I guess you probably didn't think to list it. Good options would be to change users between All, Group or Owner, build sets of 'looks' or states and a reset to put everything in order if someone makes a mess of the place.


A weird little coincidence is that I was thinking of making my own grandfather clock for the hallway. I don't know why I settled on that specific detail since I only need something to hold a menu of useful controls for the house: a painting, a bureau or even a coatstand would do just as well.

Thanks for that, DoteDote: it works! I had smartass check it with his group tag turned off and it foiled him.

Now I have two scripts to choose from, the only noticeable difference being that with yours, a group member can open and close the window regardless of whether or not it is locked. Void's script keeps the window firmly closed unless the group member unlocks it first.

I'll apply both versions to different doors and live with them for a bit to see which I feel most comfortable with using.

you can make either version do the other way by adjusting the if's in the touch end, the biggest differences will be in the script time, (mines gone to run fatter when used) and whether there's feedback doing the hold (Dote's won't)

I didn't test whether the lock unlock logic is faster for one or the other (offhand I'll guess mine is smaller, Dote's is faster) we both chose a similar way of doing that, just different datatypes to use.

So I figured it would be useful to modify DoteDote and Void's solutions to get a swing instead of a slide.

I managed to modify DoteDote's solution relatively easily with the example of the rotating door script in the Wiki (http://wiki.secondlife.com/wiki/LlGetLocalRot) like so:

     integer Swing = -80;
     rotation Rotate;
     integer isOpened;
     integer isLocked;
     
     Action()
     {
     Rotate = llEuler2Rot(<0.0, 0.0, Swing> * DEG_TO_RAD);
     if(!isOpened)
     {
     llSetLocalRot(Rotate * llGetLocalRot());
     }
     else
     {
     Rotate.s *= -1;
     llSetLocalRot(Rotate * llGetLocalRot());
     }
     isOpened = !isOpened;
     }
     

This seems to work fine although I wonder if it could it be cleaner?

Void's solution is proving much more difficult. Although I already have a working script in my modified version of DoteDote's solution, I'm trying to understand how Void's original script does what it does.

I suspect I can't get the same example from the Wiki to work in Void's script because vfsOpened is a vector and Rotate, which replaces it here, is a rotation. I tried converting the rotation back to a vector using llRot2Euler but that didn't work. In either case I just get a type mismatch error on this line:

     llSetRot( llGetRot() + (((gBooOpen = !gBooOpen) * 2 - 1) * Rotate * llGetLocalRot()) );
     

.

This is the complete example of how I tried to modify Void's script:

     integer Swing = -80;
     rotation Rotate;
     integer gIntHeld;
     integer gBooOpen;
     integer gBooLock;
     string gStrStatus = "unlocked";
     
     default
  {
     touch(integer vIntTotal)
     {
     Rotate = llEuler2Rot( <.0, .0, (float)Swing> * DEG_TO_RAD );
     ++gIntHeld;
     if (10 == gIntHeld)
     {
     llWhisper(0, llGetSubString( gStrStatus , 2 * (!gBooLock), -3 ) + " request registered.");
     }
     }
     
     touch_end(integer total_number)
     {
     key vKeyTest = llDetectedKey(0);
     if (10 <= gIntHeld && llGetOwner() == vKeyTest)
     {
     gBooLock = !gBooLock;
     llOwnerSay(llGetSubString( gStrStatus , 2 * gBooLock, -1));
     }
     else if (llSameGroup( llDetectedKey( 0 ) ) || !gBooLock)
     {
     Rotate.s *= -1;
     llSetRot( llGetRot() + (((gBooOpen = !gBooOpen) * 2 - 1) * Rotate * llGetLocalRot()) );
     }
     else
     {
     llWhisper(0, "The door is locked.");
     }
     gIntHeld = 0;
     }
     }
     

Any ideas?

I don't think it'll let you multiply a rotation by an integer (the source of the type mismatch)... but that's ok, because we don't need to track open anymore, since the rotation will do it for us.... (techinally we could have pulled this trick before with the sliding window offset, using getPos and multiplying the offset vector time -1 each time, but it'd need to start out open, or have the vector reversed)

just discard the gBooOpen variable, and use either the rot.s*=-1, or within the function call you can do
llSetRot( (rot = ZERO_ROTATION / Rot) * llGetRot() );
presuming you have a halfcut swing door.

(oddly enough the example you sited is the one I posted to the wiki)

the one caveat is that the script treats it's starting position on rez (or script compiled and running) as the closed state... so if it's reset while open.... but you'd have a similar problem already in the previous slide script.

in fact my previous example SHOULD have used the negation logic, since the open status was only tracked within the call to change it.

so the variations of the call SHOULD look like
llSetPos( llGetPos() + ( offset = -offset ) * llGetLocalRot() );
and
llSetRot( (swing = ZERO_ROTATION / swing) * llGetRot() );

if the reversed starting logic bothers you you can either start with them open, or reverse them once in advance on state entry.

if you absolutely MUST track the open status across script resets, llSetAlpha on a hidden face is a good fast choice, I like using 1.0 and .999 and tracking against = 1.0.

Void, the call using negation logic works fine in the sliding window, like so:

   llSetPos( llGetPos() + ( gOfsOpened = -gOfsOpened ) * llGetLocalRot() );
   

But the call for the rotating version doesn't reverse direction at all so the door keeps moving around in increments of 80 degrees. This is how I used it in the script:

   llSetRot( (Rotate = ZERO_ROTATION / Rotate) * llGetRot() );
   

I also tried just dropping the gBooOpen variable as you suggested like so:

   Rotate.s *= -1;
   llSetLocalRot( Rotate * llGetLocalRot() );
   

But the result is the same. I'm missing something here because I can't see how this is supposed to work unless it uses an 'else' multiplying the offset as in DoteDote's solution.

here's the modified version of the original, with comments after the parts to remove, and before the parts to add to convert it to the rotation version ( I'm pretty sure there are no typos.? )

//--vector   gOfsOpen = <0.0, 0.0, -1.4>;
vector   gDegOpen = <0.0, 0.0, -80.0>; //-- new line
rotation gRotOpen;                     //-- new line
integer  gIntHeld;
integer  gBooLock;
string   gStrStatus = "UnLocked"; 

default{
    state_entry(){                                       //-- new line
        gRotOpen = llEuler2Rot( gDegOpen * DEG_TO_RAD ); //-- new line
    }                                                    //-- new line
    
    touch( integer vIntTotal ){
        ++gIntHeld;
        if (50 == gIntHeld){
            llWhisper( 0, llGetSubString( gStrStatus , 2 * (!gBooLock), -3 ) + " request registered." );
        }
    }
    
    touch_end( integer total_number ){
        key vKeyTest = llDetectedKey( 0 );
        if (50 <= gIntHeld && llGetOwner() == vKeyTest){
            gBooLock = !gBooLock;
            llOwnerSay( llGetSubString( gStrStatus , 2 * gBooLock, -1 ) );
        }else if (llSameGroup( llDetectedKey( 0 ) ) || !gBooLock ){
//--            llSetPos( llGetPos() + (gOfsOpen = -gOfsOpen)* llGetLocalRot()) );
            llSetLocalRot( (gRotOpen = ZERO_ROTATION / gRotOpen) * llGetLocalRot() ); //-- new line
        }else{
            llWhisper( 0, "The door is secured." );
        }
        gIntHeld = 0;
    }
}

EDIT:
fixed for my goofy mistake

Hi, Void. With the exception of setting the negative directly on the float value (setting it outside the vector resulted in a syntax error) and defining Rotate inside the state_entry function, which I originally had in the touch function, this is more or less what I did.

I tried an uncommented version of the code above just to be sure I hadn't overlooked something in my own attempt (and, yep, I was careful to remove the lines they're meant to replace) but the door continues to rotate in the same direction.

I considered messing around with an 'else if' thing but I understand the whole point of this is to cut down on code.

ok I'm an idiot, you can't update a value if you don't save the change to it (ker-duh) otherwise it's the same change being applied to the the same value (with the same result)

llSetLocalRot( (gRotOpen = ZERO_ROTATION / gRotOpen) * llGetLocalRot() );


ETA:
are you sure you wrote:

llSetRot( (Rotate = ZERO_ROTATION / Rotate) * llGetRot() );

and not

llSetRot( (ZERO_ROTATION / Rotate) * llGetRot() );

like I did? because that's the behavior I got when I did; continuous turning.

Ephraim Kappler roars laughing: you can't appreciate how much that admission means to a real idiot!

Thanks. It works perfectly now.

Yep. This is the version that works. I tried it in an earlier version of the script as you suggested in your post #17. You used 'swing' in that example which confusion is understandable: I changed 'vgVecDoorSwing' from the Wiki example to 'Swing' and 'vgRotDoorSwing' to 'Rotate' in my original version to help me understand what I was doing but I guess that wasn't very helpful from the posting point-of-view. Nevertheless I picked up on that and set the line exactly as you have it above.


I did that too, following your full code example in #19 (which you have now corrected). I think the problem was that I didn't understand enough to to define gRotOpen in the state_entry function when I tried to implement your suggestion in #17.

Naturally that's why it wouldn't work.

Of course llSetRot had changed again when you originally posted #19 and I followed suit like a good boy, which didn't help matters either.