• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: SVC-3546
Type: New Feature New Feature
Status: Open Open
Priority: Normal Normal
Assignee: Unassigned
Reporter: Kagehi Kohn
Votes: 1
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
2. Second Life Service - SVC

llOfferTeleport (list Destinations, key Agent[, key Group])

Created: 17/Dec/08 06:58 PM   Updated: 18/Dec/08 03:00 PM
Return to search
Component/s: Scripts
Affects Version/s: None
Fix Version/s: None

Issue Links:
Relates
 


 Description  « Hide
Been thinking a lot about the issues of teleport in SL. One issue people are having is that any sort of system that requires user action tends to break the narrative of an area, and it only gets worse if you need to move between sims (especially non-sequential sims). However, a more interesting problem involves teleport hubs and the need to, on one hand, limit new entrants to an area to a single point of entry, while giving "other" people more places they can teleport to. Note, not "give them free reign to teleport everyplace", but just give them more places they "can" go.

After some thought and discussion on this, I came up with this idea. llOfferTeleport would work like this:

1. An object in the sim that you want to teleport to must "originate" the teleport offer.

2. This teleport will be from a list. This means either:
--a) If the list has more than one item in it, you get the option of picking "which" place in that list you want to go to.
--b) If the list has "only" one item, then you can only teleport to that location.

3. Permissions for automatic teleport would be handled like a group. Anyone "in" the list of people who have allowed it will teleport "without" being asked anything.
--3a. NOTE: This group like system would need to allow an object owned by someone "in" the group to work for anyone in it, but it needs to work even if the object itself isn't "assigned" to a group, or on group land, since its the land + object permission that needs to determine this (making it group owned object + land would undermine 90% of the uses for the function. One solution is the optional ', key Group' parameter. This would basically say, "Send an offer to teleport 'Agent', to 'Destination', if they are in group 'Group', otherwise, ask them if they want to be teleported."

4. People not "in" the automatic group will see something similar to the existing offer teleport from profiles. A simple, "Yes, No, or Mute".

5. This also functions like a sub-hub. I.e., unlike a normal teleport via a landmark or map, it can redirect someone to a point other than the main hub in the region. This would be limited:
--a) If a parcel/sim owner (or group) has set up the object containing this function, then any location within the sim/parcel is usable as a destination.
--b) If the object is "not" owned by the parcel's owner (or by someone with permissions to allow this function), then it is limited to 10 meters around the object, but only in the same parcel (i.e., it can't teleport someone to any property in range that isn't in the same parcel). This means that, even if someone owned two distinct parcels, one open to the public, but the other restricted, someone can't drop such an item next to the restricted parcel, set the destination to inside that restricted area, then have themselves, or someone else, teleport into it.
--c) An object containing the function can "never" teleport to another parcel, unless the parcel is owned by the same person, and they are the object owner, or the object was set up by the sim owner. I.e., you buy Mainland land, then set up a teleporter to drop someone in adjacent parcel, which someone else owns. Though, they could create one that can teleport you into their parcel, then you could make yours ask their object to send you an offer.

The idea is to allow for control, but also allow flexibility. If someone is renting space and has permission to the parcel they are in, then some device like a Stargate should continue to function, within that "same" parcel, even if the main sim owner changes and the new owner sets a hub. However, the fact that they do not "own" the parcel means they are restricted to teleport only within that parcel, or others you own in the same sim, and within a set range from the device, if you don't own the parcel/sim. Your gate would still work, no matter what the sim owner did (short of evicting you), as would teleporters "in" your rented parcel, but you couldn't bypass anyone else's ownership/restrictions, to teleport into places you should be allowed to.

And, for those people that have things like RP areas, where there are a dozen separate sims, all of them with hubs, you can create semi-secure ways to allow people limited teleportation, even between widely separated sims. In other words, new people can't teleport any place they want, and general players are given more options as to where to go, but are still prevented from just teleporting any place they like. And, since a rezzed object has the "same" restrictions as a teleport offer from someone's profile, there are limitations on what sort of mischief you can manage. You could teleport yourself, or someone else, who knows how to talk to it, to a location you "placed" such an item earlier, but you can't just teleport to any place you like with it (it would be restricted to 10 meters from the object, in the same "parcel", as per 5b.

This system would have the same "basic" result as llTeleportAgent, when rules 2b, 3 and 5a apply, since it would both teleport to any single point given (rule 2b), do so with the auto-teleport permission of rule 3, and to any point the object wanted within the parcel (which one presumes might be an entire build), as per rule 5. But, it would be driven by the listed location(s) in the object itself, so not "editable" by any but the objects owner (or the script, in the case where it looks up its own location and sets that as the "list", like a Stargate would, or provide more range of options, such as in a case where your build has something like a teleport room, with multiple destinations, while limiting the griefer potential. A griefer would need to a) have a lot of objects around to teleport you to, b) have them all talk to each other, so they can pass you off to the next location object, c) limit them, since they don't own the parcel, to a few meters, and even then, there is no way they could make you teleport, unless you joined the auto-teleport permission group as well. In other words, they would have to go through a lot of effort to mess with you, and its a lot easier to do other things to you, including just teleporting you home.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Kagehi Kohn added a comment - 17/Dec/08 07:00 PM
Alternative, with more control on what can and can't be done, but which can work "exactly" like llTeleportAgent, when certain criteria are met.

TigroSpottystripes Katsu added a comment - 18/Dec/08 03:00 PM
like I said on my other comment (repeating it here just so people don't have to read all the comments on another jira entry for somthing important to this one)

this doesn't completly overlap with llTeleportAgent, for certain purposes that function got advantages, for others this one does

my vote here is not a vote against that other function, ideally both would be implemented (or perhaps a third one that would cover the benefits and skip the undesirable limitations of both would instead)