Please help with timer

[Nicole Hansome]

Hello i'm newbie in lsl :catvery-happy:Working on a very simple security device but i don't know how and where to insert a time event ?

Here is the code:

default
{
	state_entry()
	{
		llSetText("So far and not further", <1,0,0>, 5.0);
	}
	collision_start(integer total_number)
	{
		llTeleportAgentHome(llDetectedKey(0)); 
	}
}

 how can i make it that it teleports the agent home in about 20 seconds and not immediatelly he collides with the object?

 

Thanks very much :matte-motes-kiss:

[Rolig Loon]

Use logic.  When do you want a timer to start? When someone collides with your scripted object, right?  So that's where you put the trigger to start the timer event.  When do you want it to fire?  Twenty seconds after someone collides?  Use llSetTimerEvent(20.0).  You want to teleport the person home when the timer fires?  Put that statement in the timer event. The only other thing to remember is cleanup. Turn off the timer event (llSetTimerEvent(0.0) ) when you are done with it.

key gAv;default{	state_entry()	{		llSetText("So far and not further", <1.0,0.0,0.0>, 1.0); //Alpha cannot be greater than 1.0	}	collision_start(integer total_number)	{                      gAv = llDetectedKey(0);                llSetTimerEvent(20.0);        }        timer()        {		llTeleportAgentHome(gAv);                llSetTimerEvent(0.0); 	}}

 BTW, it's polite to give a warning before you eject someone, so they have time to back up and reconsider.  You can figure out where to give that warning.

ETA:  Ooops!  Innula's right.  llDetectedKey needs to know who you are teleporting, and that information is lost as soon as you step out of the collision_start event.  So make it global.  I corrected my original post to do that, above.

[Nicole Hansome]

wow thanks very much

yes cause currently it's teleporting the agent immediately when he collides. Just wanted to give them more time to reconsider and if he is still there in 20 seconds then to teleport him home. I want to do a message in local chat and as dialog window as well, but i think i will figure that out :-)

Just had problems with the time.. tried it a few hours and still not working .. so im very thanful now :matte-motes-kiss:

[Innula Zenovka]

Since the script only knows who llDetectedKey(0) is inside the event where the key is detected, you need to start by declaring a global variable that stores the key for use outside the event.    Something like this.

However, while I applaud your desire to keep it simple, I think you do need to make it a bit more complicated.   As things stand, if more than one avatar collides with the item within 20 seconds, only the last one to collide with it will be sent home.   Also, you might not want to teleport the owner (or the owner's friends?) home.

 

key intruder;default{	state_entry()	{		//stuff	}	collision_start(integer total_number)	{		intruder = llDetectedKey(0);		llRegionSayTo(intruder,0,"You will be teleported home in 20 seconds if you don't leave voluntarily");		llSetTimerEvent(20.0);	}	timer()	{		llSetTimerEvent(0.0);//stop the timer		if (llOverMyLand(intruder)){//if the intruder is still here			llTeleportAgentHome(intruder);		}		intruder="";	}}

 

 ETA Rolig got there first!

[Nicole Hansome]

They are working both :-)

But a little further question came up for me. Right now when someone collides with the prim and leaves the prim again then he will be teleported home anyway.. how can i make that when he leaves the Prim that he may stay ? Do i have to use something like end collission or so ?

[Rolig Loon]

That's what Innula's bit of code does ...

if (llOverMyLand(intruder)){//if the intruder is still here			llTeleportAgentHome(intruder);

If the intruder is not llOverMyLand, he's not ejected.

[Nicole Hansome]

ah ok.. But when he leaves the scripted prim he is still over my land or did i misunderstand it ?

 

[Innula Zenovka]

Or, if you want to refine it a bit, you can test where the intruder actually is, just before you decide whether to eject or not.

This tests to see if the intruder is within 10 metres:

	timer()	{		llSetTimerEvent(0.0);//stop the timer		if (llOverMyLand(intruder)){//if the intruder is still here			vector pos = llList2Vector(llGetObjectDetails(intruder,[OBJECT_POS]),0);//intruder's position now			if(llVecDist(pos,llGetPos())<10.0){//if the intruder is less than 10 metres away				llTeleportAgentHome(intruder);			}		}		intruder="";	}

 

[Nicole Hansome]

Thanks That did the trick .

[Rolig Loon]

The llOverMyLand function returns a value of TRUE if the person is over the owner's land or FALSE if he's not.  The test is not about where the scripted detector is.  It's about where the avatar is. So yes, if he's still over your land when the timer fires, he would be ejected.

[Perrie Juran]

I know this is  a side subject but I have been doing a little bit of testing.  Short fuses on Security Devices has been a sore topic for as long as Security devices have been around.  So here was my test.

I set a long fuse (60 Seconds) on my security device.

When I TP'd a friend I waited to see how long it would take them to IM me that they were about to get ejected.  It was taking 20 seconds minimum / 30 seconds maximum for them to IM me. 

My security device was on the opposite end of my parcel (a 4096) from the TP point. Adding in the time it would take me to Cam over to the device and turn it off I am finding 45 Seconds is a very fair time for the fuse.

I haven't dug in to doing it yet, but I am thinking of adding a chat command to my device so I don't have to Cam to it.

 

 

[Qie Niangao]

Ummm. It's really very mean to use llTeleportAgentHome(), compared to llEjectFromLand(). Especially for newbies--the most likely to stray into a secured area anyway--it's very disorienting.

Also, neither function works unless the "intruder" is on land controlled by the owner of the scripted device; llOverMyLand() is important for issuing warnings (it's very bad to send warnings to people on somebody else's land), but it's not really necessary to check before trying to eject them.

[Innula Zenovka]

Don't you get a script error if you try to eject (by whatever means) someone who isn't over your land?  I was under the impression you do, but I've never tested it, so I may well be mistaken.

[Jenni Darkwatch]

Security devices are a rather interesting subject - from a programmatic point of view.

The simple method with collision works. In theory, you can also use collision_start and collision_end to detect when someone collides and when someone leaves. This allows you to track multiple avis: Similar, a list of "friendly" avis allows you to check whether someone is allowed to be in that area or not.

In the collision_start event add the avi key to a list. In the collision_end event remove the avi from the list.

It quickly gets very complicated if you do indeed want to give _every_ avi 20s grace for leaving: Then you'll also have to store the time the avi first collided with the prim (you could use a strided list for that) and make sure the timer fires at the appropriate intervals. Not trivial.

On the plus side, your approach might be less laggy than a sensor event. Depends on what else is colliding with that prim.

[Qie Niangao]

---

Innula Zenovka wrote:

Don't you get a script error if you try to eject (by whatever means) someone who isn't over your land? 

---

Not that I can tell. You had me worried there for a moment. I realized that the only scripts I have running that might ever call those functions are deeded to group, being on group-owned land, and stuck away where I rarely see them, so I decided I better test it. Didn't see any errors.

Of course, there's nothing wrong with using the llOverMyLand() test anyway.

(Also, I realize that here we're using collision to detect intruders so it shouldn't be necessary to check llOverMyLand() before sending the warning, assuming the collision volume doesn't encroach on anybody else's land. Security systems using sensors that range into neighboring parcels, however, really need to be careful about who they spam.)