how do i script a garage door and a locking access list together?

hi im a noob scripter but i need a script that acts like a garage door but can lock aswell. please help me . thanks.

this isn't a free script forum, it's a script help forum. if you want someone to write one for you, go to the products wanted forum, or check out xstreetsl.com

/147/1.html

however, similar topics have been covered many times before, have you tried searching for it?

You can do a garage door a few different ways (scaling, moving prims, cutting). Nerolus Mosienko recently posted a scaling garage door script that you may find useful. You can find it here /54/47/277526/1.html.

As for locking the door... keep in mind that anyone can sit on a prim and slide right into the garage, bypassing the lock altogether. To lock the garage you could do it one of two ways... either specify a list of avatars and compare the list to the avatar touching the door or check the active group of the prim the script is in with that of the avatar trying to open the door. Below are some examples. If you plan on having a user list, it may be easier to add notecard reading code to your script and load the user names from the notecard.

Check a user list using name:

list users;

defaults()
{
    users = ["Yingzi Xue", "farrier Felisimo"];
}

default
{
    state_entry()
    {
        defaults();
    }
    
    touch_start(integer touches)
    {
        //see if the avatar touching the door is in the list
        if (llListFindList(users,[llDetectedName(0)]) >=0)
        {
            //open the door
        } else 
        { 
            //sorry, you're not in the user list
        }
    }
}
CODE


Compare avatar's active group to the prim's set group:

CODE

default
{
    touch_start(integer touches)
    {
        //see if the avatar touching the door is in the list
        if (llSameGroup(llDetectedKey(0)))
        {
            //open the door
        } else 
        { 
            //sorry, group doesn't match
        }
    }
}

llDetectedOwner? shouldn't that be llDetectedKey? i guess it wouldn't matter for touch since avatars own themselves though right?

would you be able to check if the owner of a detected object has the same group active?

EDIT: Doh, you're right. Bad habit of mine. I corrected it.

hmm, tried, it, seems ok to me, lol

I found a few blaring errors. That's what I get for writing it in the forum post box. Added a state_entry that loads the list.

read up on that some, i guess only if the owner is in the same sim. llSameGroup will check no matter how the key is passed to it, and like i said above, llDetectedOwner will respond the same as llDetectedKey in a touch event since avatars own themselves lol. as for sensors or collisions, it could detect an object that's set(not deeded) to a different group, but if the owner is in the sim with the same group llSameGroup(llDetectedOwner(0)) will still return true

That's how I saw it too, so I never got in the habit of using llDetectedKey(). I guess it's a bad habit really. I'll probably start using llDetectedKey() instead.

if (llListFindList(users,[llKey2Name(llDetectedKey(0))]) >=0)

does ">= 0" include 0? if not it will return false for the first index wouldn't it?

and llDetectedName returns the same thing as llKey2Name(llDetectedKey in a touch event

edit: hmm, you must have changed it after i started replying lol

Yes... >=0 means greater than or equal to zero, so it will include anything zero and above. I know (llDetectedName(0)) that's why I changed it. I don't know if there is a memory savings or not. I would assume saving an extra conversion (llKey2Name()) might help a tad, but in the grand scheme of things probably isn't much difference.

ah ok, i'm not a big math person lol, i never got deep into using the <> symbols

so now i know: "> 0" is only if it's more than 0, and ">=0" is if it's 0 and a above, same for less than. probably why i was pulling my hair out over some scripts that i thought should have worked lol, i was using "scale.z <=10" when it should have been "scale.z < 10" it didn't even occur to me that it was a math error on my part

The easiest way I found to figure out those operators is to just put them into words by reading the statement. if (x > 10) would be "if x is greater than 10". if (x >= 10) would be "if x is greater than or equal to 10". What makes me pull my hair out is some indexes start at 1 and some at 0. Keeping track of them is sometimes frustrating. That's why I keep code snippets and go back to them for reference. When you start using some of the functions a lot you get it in your memory and it becomes second nature. Then if you don't use them for awhile you forget. lol

as far as i know, the only index that starts at 1 is the link number right?

any loops i use that involve links i start at the last one and decrement

integer num - llGetNumberOfPrims();
for(num;num>0;num--)

anything else i start at 0 and increment

integer i;
integer len = llGetListLength(listofstuff);
for(i = 0;i<len;i++)

The other one that I'm aware of really isn't an index per se... it's llGetListLength(my_list)... which returns 1 if the list has one element, even though you access that first element by using 0 instead of 1.

I do this slightly differently, with

list authorized;
      integer index;
      
      integer HaveAccess(string name)
      {
      	for(index=0;index<llGetListLength(authorized);index++)
      	{
      		if (llList2String(authorized,index)==name)
      		{
      			return TRUE;
      		}
      	}
      	return FALSE;	
      }
      

and then,

  touch_start(integer total_number)
      	{ string name = llDetectedName(0);
 	   key av = llDetectedKey(0);
      		  if (HaveAccess(name)==FALSE)
      		  {
      			  llInstantMessage(av, "Sorry, " + name + ", but the door's locked");
      		return;
      		}
      		
      		else
      	   // do stuff
      }
      

That assumes you've put the owner on the access list in state_entry(), of course.

aah, interesting. i've never used return in any of my scripts. haven't read into it enough to understand it. i'm assuming it kills the for loop if it does find the name and never gets to return FALSE?

I did something similar with my permissions snippets for my scripts. Works great and you can use it repeatedly in your code without using extra memory. Kudos.

I would highly recommend llListFindList() above an explicit loop if all you are doing is looking for an exact value in a list. It's concise and most likely a lot faster. There are plenty of times you can't do this (like if you need to find an element that PARTLY matches something or do whatever other processing on the list elements), but for exact value comparison, it's a little silly not to use an API function to do it for you.

The other thing I'd like to point out is that 'llDetectedName(i)' and 'llKey2NamellDetectedKey(i))' aren't QUITE the same. If the detected object or avatar is in a different sim, the former will work fine but llKey2Name() will probably return an empty string.

i didn't even think of that. i know sensors don't cross sim bounderies right? will a prim with a collision event be triggered if the prim is centered on a different sim from where it was hit? and obviously you can touch something across the boundery

Yep. llSensor() won't cross region boundaries (I don't think), but llSensorRepeat() will on a periodic basis (but not every execution) if the period is setup right. I think it has to be less than 5 seconds or something like that. At least, that's the way it used to work. I doubt it has changed much, but who knows. Might be worth testing.

I tried to put a sliding door script on a sim boundary with half of a collision detector (llVolumeDetect) on one side, half on the other. It only works for one half. The other half does not work.

For a 0-index based decrement loop I usually use while( --num + 1 ) , where num was the number of elements in a list via num = (list != []);

On a link-number loop while avoiding the root I usually also do while( --Prims - 1 ) and Prims = llGetNumberOfPrims() + 1;

Regarding collisions on sim boundaries, all the physics calculations are only handled in the sim they are in, in fact the sim doesn't really know anything about the prims in the neighbouring sims.

Thanks. I quite see, now it's pointed out, that

if (llListFindList(authorized, [name]==-1) 

says the same thing only better and with no need for the loop.

I hadn't realised that llDetectedName() and llDetectedKey() worked differently. In practice, I don't know how often the door would be on one side of a sim boundary and the avatar seeking entry on the other -- no way i would build like that -- but it's good to know in other circumstances, certainly.

I believe they used to have an overlap region of about 10m on each side of the border where the sims would hand over data and coordinate with each other, so it may well be possible to collide with something that is technically being handled by another simulator. Might be worth doing some testing though. No idea about the corners, but I think corners have always presented problems of various kinds.