So what happened to llTeleportAgent?

Agreed. Personally I dislike the idea of requesting permission solely for the purpose of making an infinite hallway work (or walk on telepads, which I've tried replicating with physics with poor results). Requesting permissions is safer in the respect that it prevents griefing, but there's a lot that it would stop simply because you can say no and walk to the end of the optical illusion.

An enforced, and gradually larger teleport delay for an individual against an individual would be perfect in my opinion. For example, Griefer Bob pulls out his tele-pistol and shoots Jonny, making him teleport back 10m and into his waiting teleporter trap. Initially Jonny won't be affected by another llTeleportAgent command for 2 seconds, but the trap is spamming teleport requests. Each request extends the period of disabled teleporting by 1 second. So Jonny gets forced backwards into a box that has a volume detect teleport command in it, however the script will never work on the poor trapped Jonny because he was teleported by Bob within the past 2 seconds.


However this delay would allow legitimate teleport calls to work. Builder Joe saves Jonny from the trap by warping him to his new building to show off his telepad elevator system. Jonny walks onto the pad for the next level up and appears several meters away from the teleporters on the next level up. After getting his bearings, Jonny walks to the next "Up" telepad giving the count down timer a chance to work itself out. End result, functioning and easy to use teleporting system.


Now to be fair, it's possible that griefers could time the teleporting and force individuals to warp back and forth between a few areas, but this can be partially prevented by requiring collision to occur, or for the avatar being teleported to be attached to the object (as either an attachment or by sitting). This stops scanner teleporters. Teleport bullets can be prevented (partially, as much as any bullets can) by shielding or anti-physics systems. Volume detect traps are a little harder to regulate though because there's as many valid reasons to use volume detect as there are griefing reasons. In the end though, it's not much more dangerous than llPushObject. If anything it's less so because of the delay period.

Given that LL doesn't even bother to implement backoff in their TCP-subset-on-top-of-UDP, instead forcing you to tell them how much bandwidth you think you have and losing packets if you guess wrong, I think that's far too sophisticated an algorithm for them.

That would be a nice touch, because it would allow you to implement flicker techniques (see The Peace War by Vinge) for protective teleport in combat, but a fixed short timeout after EVERY teleport would do the job just as well.

Well the problem with a fixed short teleport for the script in general is that it can cause traffic delays or inconsistant performance (re: tele-pistol, which I can think of several non-grief or anti-grief uses for). If the delay on the call is per individual then others can follow after you into a teleporter. For instance, going back to the infinite hallway idea, if there was a fixed delay on the script for teleporting then your friends could keep walking to the end while you get stuck in the loop. On the other hand, on a per person case everyone would get teleported backwards. You'd just have to ensure they can't get back in time to trigger the teleporter before it's reset for them.

The delay wouldn't be on the script, it would be a blanket "teleports don't effect me" for (say) 5 seconds after arriving via teleport.

This wouldn't hurt the "infinite corridoor" unless the segment was so short it took less than 5 seconds to get from one end to the other. And even then, you wouldn't get stuck if the code looked like this:

string TARGETSIM = "Ahern";
string TARGETPOS = <0,0,21>;

default
{
  collision_start(integer n)
  {
    state active;
  }
}

state active
{
  state_entry()
  {
    llSensorRepeat("","",AGENT,2,PI,1);
  }
  no_sensor()
  {
    llSensorRemove();
    state default;
  }
  sensor(integer n)
  {
    integer i;
    for(i = 0; i < n; i++)
    {
      llTeleportAgent(
        llDetectedKey(i),
        TARGETSIM,
        TARGETPOS+llDetectedPos(i)-llGetPos()
      );
    }
  }
}

That would work out well then, if it's on a per case instance rather than per script. I'm still wary of teleporting by sensor due to griefing. I feel that requiring collision or volume detect gives a certain level of protection against misuse, but I suppose if you really wanted you could just fire teleport bullets at scanned people anyways. It's just there's a defense against projectiles, there's no defense against a scanner.

Well you could have the delay cause a teleport queue perhaps, so if you send a teleport request it WILL take effect, but only after the target's delay has expired. This way the script can forget about it, and repeat requests onto the queue would replace old ones (in case the destination changes slightly).

Or an alternative maybe, what about a throttling system? ie, every time an av is teleported they have a "teleport" count incremented, which goes down every few seconds (like a delay). If the count gets too high then the avatar can't be teleported anymore, possibly even giving them a dialogue or script error message or something so they know what's happened. Possibly connected with a return value for llTeleportAgent to report TRUE on success or FALSE on failure.

The throttling system you describe is something like what I mentioned, only mine has a lower tolerance for teleport spamming. The queue idea is an interesting prospect though, if a script can only successfully teleport X times per X seconds (say 5 people per 3 seconds), further calls will add only the last target to a queue for the next second. That would help stem mass area teleporting via sensors.

Yeh, but it'd be insanely more complex to implement and trivial to workaround: you just rez a nonphys hollow sphere with volume-detect and warp-move it around the target and turn it physical.

And, you know, having the teleport just ignored rather than queued is a more effective defence against griefing than delaying the script (just run 30 scripts!) or queuing the teleport, plus it lets you do things like staged stepping disks and optional teleports. Like, for a warp gate you'd just teleport everyone you sense... *once*. If they gate in, they get ignored by the teleport and go on their way. You don't have to have the warp-gates communicate so they don't reteleport people who get bumped the wrong direction after arrival.

What about limit teleporting to script that is owned by the owner of the land, or one of the officers for group land? That would eliminate teleporter-bomb and prevent lots of griefing as well. Then use method as Argent said, teleporting command will ignore person that just be teleported for a short while ;p And maybe limit number of teleports per seconds per script too.

How's that?

In my original comment about permissions I said that teleporting *without a dialog* should be restricted to scripts owned by the landowner or officers of the landowner group.
If there's a rate limit per avatar, then there's no reason to rate limit it per script as well, and that would prevent things like mass teleports ("I got a Body Debit card for The Restaurant at the End of the Universe, everyone stand close to me, it's got a range limit of 10 meters"... *blip*).

Heh, silly restaurant goers. ^.^;

I don't feel that it should be limited to only land you own, I'd like to use it to expand the influence of my glasses of town portal so they can make a portal to anywhere I've been, not just somewhere in the sim I'm in. That way I can easily invite people back to my apartment, give newbies a ride straight to TeaZer University, or bring a full team of people with me to play in the Arcadia sims.

Of course you should! The only question is when you should have "An object 'portal' owned by Feyn Minstral wants to teleport you. (OK) (cancel)" show up. A lot of people want that to happen even for internal teleports in builds, and that's what led to this discussion.

By extension of that thought, llPushObject should have such a dialog since it's possible with enough force and enough scripts calling it at the same time to simulate teleporting across vast distances in an instant (albeit in a manner likely to crash your client and screw up your character). ^.^;

I don't feel that llTeleportAgent should require permission, but again suggest that the fault would be allowing it to function via sensors which could basically BFG10k teleport everyone (one slow moving orb flying through a sim, teleporting everyone it sees). At least with a collision requirement you have a chance to evade or repel.

Red herring. llPushObject is being limited in 1.11 and it's likely that shortly after it finally goes up pretty much every parcel will be push-for-owner-only.

This is no restriction at all. If you can sense someone you can engineer a collision with them, and there's no way to block or even detect a warp-moved nonphysical object.

"Raise the shield! Move power to the booster! We may be able to get away from their teleportation beam!"

It's possible to stop all BUT the llSetPos bullet through physics rebounders and shields. I suppose as a compromise of our ideas having it restricted by group would be more acceptable. If you're on group owned land, you have to be a part of that group or else you need permission to teleport. Or perhaps an expansion to the multiple group titles coming soon, certain LSL commands can be performed by members of a particular role without permission (such as llPushObject or llTeleportAgent).

Or another option, make it a user decision in the preferences:

Allow llTeleportAgent()?   O  Always      *  Ask Permission      O   Never

... Again, with the expansion idea that it could be "always" to a particular group (so you can be warped around by group owned objects, usually meaning they're permanent sim installations) and "never" to anyone not in a group. Or "always to people on my buddy list"

Hey, I'd be happy having it unrestricted with a delay on re-teleporting and a report on who teleported you in the abuse menu.

I believe that any broader default than "landowner (including deeded to landowning group) or officer in landowning group, or object linked to you (attachment or seat)" is likely to get major knockback. There's too many groups with zillions of random rats as members... look at all the group-restricted-access parcels out there. And I think that default is what you're actually asking for anyway, no? Do you really think just being a group member should be enough?

Hell, I'd love to be able to automatically grant camera controls to attachments, I think it'd be great to have ALL permissions dialogs bypassable in prefs.

Then really my initial suggestion for a compounding delay would be ideal. The question is whether someone could/would do it. I feel it'd solve the problem expertly, no automated scripted object (or set of objects) owned by a single person could teleport trap an individual. Group griefing is, thankfully, a rare event.

I do, really. Not everyone has maxed out their group list and while I can't speak for everyone in SL, I personally don't accept random group invites. I'm a member of every group I'm in for a reason, and I can trust that all members of those groups wouldn't not teleport me without just cause (lest they be banished from the group and their rented spaces "generously donated".

Cameras in attachments do have permission automatically, don't they? I know sitting does. <shrugs>
But yes, that would be great. An option tab in preferences to set each permission based on condition. So you could turn on camera, teleport, and push permissions for stuff attached to you, and ask for the rest.

Why? Your idea is much more complex and could be bypassed just by having the the griefer use *two* free alts instead of just one. What advantage does it have over a short period (even just ten seconds) of ignoring teleports after you've been teleported?
The main reason (the only one I can think of, really) to set a fee on joining a group is to use the group for access control, which means that having an alt join a landholding group as a member is cheap and easy.

No, and neither does sitting. You're confusing the old vehicle camera with the new camera controls.

Ok, hate to say it but we are going to need some form of rate-throttling on teleports, for there will be cases where you want to allow a few teleports, but not constant teleporting.

Further, you don't want the server to have to do a lot of keeping track of this.

So, I propose that the 'num lock' key be used as a 'if this is on, NOTHING can teleport me' key. It lights up, so you know it's in use, and you can engage it as soon as someone goes teleport-nuts on you. Just hit it, and you can't be teleported.

This is preferable to a rolling counter on the server, as it uses less resources (static flag only).

llTeleportAgent should succeede if the flag is not set, if it is set, the teleport should fail with a script error, and sleep the script for 15 seconds.
Further, llGetAgentSettings or whatever command does that function should be able to tell if someone is teleport locked or not.
This will force teleporting objects to check for permission before trying to teleport someone.

Even when numlock (teleportlock) is *off*, there are settings in preferences about who can TP you, a series of checkboxes checked from the top down - if you match a checked one, you can TP the person.
* objects you own
* objects owned by land owner
* objects owned by friends
* objects owned by people in the same groups as you (NOT CHECKED by default, maybe omit if you have issues with it).
* objects which themselves AND their owners are not muted by the target av.

That scripts can detect if you're teleportable or not is important - they can IM you and ask you to turn TP on to experience their build, for example. Or maybe they can request teleport permissions from you (options : yes, no, mute object), but it sleeps their script for 10 seconds to do so.
With detection, they can find out you're not portable and make allowances so builds work.


Walk into a funny build, bounce around as long as you like till you feel like stopping.
Don't want to be TPed at all by random people - uncheck the boxes.
The first 2 boxes should be checked by default.
The first 5 times you get TPed, it should sleep the TPing script for 5 seconds and a box pop up on your screen : "you have been TPed by _____ to _____. This was allowed because you allow teleports by ______. To change this, go to Preferences->Teleport options. To stop ALL teleports in an emergency, use the "NUM LOCK" key on your keyboard".
Yes, it should be the first 5 times someone is TPed, so it is drilled into their heads.
If someone griefs you, hit numlock when you're bored. Most griefer objects won't be complex enough to check perm before trying to TP you, and so they get slept for awhile (useful if they try to TP everyone in an area without checking perms first). Once you hit numlock, you're unteleportable, PERIOD (even by attached objects you own, to prevent trojan objs locking you in TP limbo). Then you adjust your settings if needed.

Oh, and records of TPs should be kept. Anyone TPing other people abusively, even if their settings permit it, should be hauled before the AR team.

Have you read the thread?

Rate limiting is most of what we've been talking about.

And the server has nothing to do with it. The client is what initiates the actual teleport, and the client that would implement the "ignore teleport requests for 10 seconds after teleporting" code.

Num lock? Apart from the question of what makes teleporting so special it gets the key, a lot of compact keyboards don't have a numeric keypad OR a num-lock key. Mine doesn't.

Mmm...what about a menu command and a key combination? Like Ctrl-Alt-Shift-T or something...

*grin* CTRL-ALT-SHIFT-T is already taken, I think - show texture info for select object.

would be nice to have a key combination to toggle behaviours though

So how about a gradually increasing timer on the individual then? For 2 seconds they can't be reteleported, and for every attempt made in the disabled period the timer is extended 1 second. When it reaches 30 seconds a notice is made to the user about a possible griefing attempt with all the parties involved. This would solve the multiple griefer syndrome while allowing fast teleporters to be made (so long as the individual doesn't try hopping back into a teleporter too soon). Naturally this gradually increasing delay would be excluded on attachments and objects you own, as one would assume you WANT to teleport yourself in those cases.

I still feel though that having an "always allow" option for group owned objects would be a good idea. As a corollary, there could be a group role option to basically set a flag as to whether the individual is a "trusted teleporter." This would naturally be excluded from entry level roles (meaning even open groups could be safe), but people in roles like "sim builder", "security", or "admin" would likely have this option enabled.

Why?

Seriously. Why do you think an increasing timer is important? What's the problem with a 10s "ignore teleports" period after teleporting?