Teleport problems

Hi,

I am having a teleport script that when you touch it you can select the destination.
I want to use it to teleport from 1 location to another location in the same sim.
This script works with a ball where you sit on then teleport and than the ball goes back to the start location.

The teleport it self works fine but the ball can't return to start location because it cross a land where 'create object', 'object entry' and 'run scripts' are diabled.

Does anyone know how to solve this or does anybody knows on which height i can cross this land with the diabled options?


Thanks

A recent thread (/54/84/192445/1.html) seems to have given up on being able to cross "no object entry" parcels. So I think there are tthree possible work-arounds:

If the TP destination is less than 300m from the origin, use a different teleporter that's based on llSitTarget() instead of warpPos.

If the distance is greater than 300m but you can plot a route around the obstacle, use a sequence of warpPos calls in the teleport, passing through waypoints in that route.

If > 300 and no such route exists, use llMapDestination() to have the user invoke the built-in SL teleport from the Map. (This is only slightly more intuitive than just giving them a landmark, though.)

Rather than trying to return, you could have the original location teleport object clone a new copy of itself and leave it behind for the next person. Then once the original moves to the new location and unsits the AV, it could just die.

(Assuming the object has the sim perms to do that, of course.)

Thanks Oie and RJ,

I am a newbie at scripting in SL and don't know which command i can use.

Can you tell me which command i can use to clone the teleport?


Thanks

If you go the cloning route (which is more complicated than than the returning-object method), you'll put a copy of the teleport object into the inventory of the teleport object. It will then use llRezObject to rez that object (a copy of itself) before it warps away. Since this is sort of a recursive operation, once you rez the object, you'll need to drop in any scripts or things the objects also needs. You can do that with llGiveInventory.

The systems that I have seen that seem to work the best do this.

1. Have a signpost or another object that the user clicks and selects their target.
2. The sign then Rezzes a teleport object (they usually look like a chair or some sort).
3. User sits on the teleporter.
4. Teleporter starts moving, and the sign is left behind for future users.
5. When you reach the desitnation, llUnsit the user and llDie the teleporter.

Reflecting a bit on the original posting, the conditions under which a path is clear from origin to destination, but not back, seem a bit special. The situation that comes to mind is if the path traverses a fairly small corner of a hostile parcel, which is spanned in one 10m "hop" of the llSetPrimitiveParams ruleset outbound, but the return path lands a hop within it. If that's the case, it seems like it would be avoidable by a single waypoint on the path (that is, just two warpPos calls in each direction). It also seems like the margin of error for that outbound path might be quite small and likely very sensitive to slight changes in the origin or destination.

There are several ways to be able to let the teleporter llDie() at destination, as illustrated by the suggestions. Some approaches have the teleporting object already rezzed and waiting for an avatar to "sit" on it. The problem then becomes how to replace that object so there's one ready for the next rider. One approach described above has the teleporter itself rez a clone before departing, populating it with the necessary stuff for the clone to be able to clone itself in turn, ad infinitum. A variant (that I find simpler) has some other prim rez a replacement when the teleporter departs. The other approach described above has that other prim rez the teleporter upon selection of destination, before the avatar sits on it.

The problem is likely that it succeeds on the way out and fails on the way back, even landing on the exact same hop points, because it is occupied on the way out and not occupied on the way back. I don't know how many situations will do that, but at least one I've seen is a vehicle skirting an edge-of-world sim. When ridden, it makes it. When not, it fails.