Discussion: llTeleportAgent (some thoughts on the matter)

Lets just rephrase the concept a bit..., coming from some of the comments going back and forth on this thread:

/352/6f/293887/31.html

As it exist, the llTeleportAgent 'concept' solves one problem, but ignores another. Mainly, it is possible for someone to own land "in" a sim, but not the sim itself, like Mainland, or to rent in one, but not own it, and nothing at all currently prevents the owner from "breaking" existing objects that use "teleport via landmark", which is the current method some systems do use (like the attachments that listen for the Alteran gates connecting outgoing, get the coordinates, then generate a landmark, when you "step through" the horizon). So...

1. The feature needs to be usable every place, it needs some way where you can give permission, which is easily revoked (currently, once script has such permissions with anything, like animations, you can't decide after that you don't want it to be allowed to any more, at least not without logging out, or something. This is why there is even a problem in the first place that makes Linden reluctant to implement it).

2. It needs more granularity. What does that mean? Well... I would suggest this:

a) If its used in an attachment, then it either "can't" teleport you to any place other than a sim with no teleport limits, *or* to the hub in one that limits you to that entry point. Some way that this "might" be overridden could be useful, but its not strictly necessary.

b) If you are in a sim and an object owned by the "parcel owner" is used, then the effect is based on that ownership. Basically, if the sim = parcel, then it can teleport you to "any point" in the sim, even if there is a hub. If the object belongs to an AV or group that owns "part" of the sim, then any parcels they own can be used as destinations, even if the sim owner themselves has (usually after the fact) placed a hub on "their" part of the land. This object cannot TP you to some part of the sim that "isn't" in the group/land owner's property.

c) Such an object could TP someone between points in the same sim, even if the sim has TP entry locked out, so long as the destination is "owned" by the same person or group as the object using the function.

This, I think, would basically cover all the problems. It still means someone teleporting "into" the sim has to land on the hub, people in the sim can however be teleported any place the land owner "allows" by providing the scripted objects needed to do it. Attachments are seriously restricted, preventing someone using them to "bypass" lockouts, since it would only work for the people that could get there anyway (as group members/owners), and you could even lock out access entirely for outside teleports, but allow objects owned by the same group or person to bypass that lock (like if you wanted a big maze, with several ways in, but only people from an "unconnected" sim to get in and out of it. You could TP in from the sim that has the object, but any other attempts to TP in direct would get "permission denied".

The only other possible thing I can think of is range.. Its likely to be limited to like 20 meters or something, which is fine, for "static" objects, but... there might be some cases where you want "some" teleports to be possible from "any" point in the sim, which means either some way for the function to work sim wide (bad idea imho), or some way to give specific AVs, using the "right" rezzable/attached objects, the same permissions, within some predetermined limitations.

Mind, one "huge" problem is still that since scripts can't check against a list of groups, its kind of hard to fill all the criteria above, even for "static" objects. The group it needs to look for may not be the "owner" of the parcels, if you want different groups to have different "allowed" destinations, for example. Something needs to be done about that, for it to be as versatile as *I* want it to be, but, just having it, and having both the limitations, as well as the abilities, listed above, would go a long way in making the system far more flexible than it is now.

I think you're over-limiting it.

First, for objects you own and have granted rights to (which would automatically be granted for attachments, while attached) I don't see any reason they should have any limitations as to where you are teleported, beyond those applied to manual teleports. Why? Because for these uses it's no different (in terms of just the functionality the user gets) from IMing you a SLURL. SO there's no valid reason to restrict it more than a SLURL. I don't understand why you're concerned about enforcing a tighter limit than that: it wouldn't be able to bypass lockouts unless the user could already bypass lockouts this way... see point 1 below.

Second, for objects that are part of the build (owned by landowner), it should be limited in how often you can be teleported, so you can't be stuck in a teleport loop. This limit would be implemented in the client, since teleports are initiated by the client, and so it wouldn't matter whether objects in different sims or owned by different people requested the teleport... after you complete a teleport additional teleport requests for 10 or 15 seconds (possibly user-selected) would just be ignored. Otherwise it should be automatic so things like "portals" or "stepping disks" could be implemented (particularly with fast teleports, point 2).

For other objects, the user would have to approve the teleport, through a normal approval dialog. This would NOT be a landmark "about" image or a map (so it couldn't be used for map spamming) but it might have a "show on map" button.

These limitations would make "griefing" with teleports a non-issue.

*1* Bypassing restrictions within the same sim? I'm not sure this could be securely implemented, since the client initiates the teleport. As far as the sim is concerned a teleport is indistinguishable from the user following a landmark or a SLURL. You would have to extend the current protocol to have the sim cryptographically sign the request.

Once that's done... rather than restrict where a HUD could teleport you, instead restrict the ability to bypass the normal teleport restriction to objects owned by the owner of the *destination* parcel. You could still do this from scripted HUDs by having them llRegionSay() something to the teleport object on a secure channel.

But either way, there's no point in imposing restrictions on the straightforward and easy implementation using an extension of the current map/slurl/landmark mechanism.

*2* Fast teleports in the same sim. THis is something I would like. If you're being teleported in the same sim, there's no reason for the "teleporting" screen. You're not doing a region crossing. This would make non-linear builds more effective.

llTeleportAgent feature reminds me of Ultima Online days, when i used to "gate" friendly travelers, giving free rides to other towns... little did they know it was Wyvern Island and I closed the gate on the other side.. waiting a few minutes to go loot them.. Other than that... I think this would be a great feature due to Stargates and other objects in Second life, it would make it a much better experience to be able to be seamlessly teleported.

Some sort of system needs to be in place, maybe land owner/group deeded objects could teleport people. other than that, you get a promter like animations to allow/disallow. and check mark to remember for this avatar/person and that might solve 99% of the griefing issue's.? I did like a few of both of your suggestions, just not sure how best to implement such a system where its immune to abuse, and confusing people teleported around .

Umm. The point is to "have" different behavior. The existing behavior simply cannot provide the means to do some of the things you would need to, in cases where you want "new" people in the sim to go one place, but also allow people that are regulars to have freer reign. We are talking about a feature that doesn't exist yet. There is no reason why it "can't" work differently than the current system, which simply won't let you do any of these things, and **as I pointed out** can be broken for someone far too easily by simply having the sim owner drop a damn TP hub into the sim, where there wasn't one before. (Mind, you might still have to get the sim owner to set it up so your group can use it properly, but that is going to be a lot easier than convincing some guy that just opened a shop, mall, club, or what ever, to remove the TP hub.



Hmm. Well, obviously. This is one reason why limiting distance, to like 10/20 meters is a good idea for the "stationary" ones, but also why you need a work around for people that want something wider ranged (might be necessary to just always ask if farther than a certain distance from the object). Yeah, some ass could still TP you all over the place within 10 meters, but the server could, instead of doing the whole "blank the screen and try", thing, just refuse to jump you if you are too close, this wouldn't be a problem. The single object could keep sending you TPs, and the server simply ignoring them, without it freezing you, keeping you from moving out of range, or otherwise messing you up. But, if the system *did* work exactly like the current one, then, yes, you would need a limit on that, or you could find yourself with a mess of "too close to teleport", or and endless series of them. This would be bad, in both cases, but an object that "can" effect region wide, instead of only effecting a 10 to 20 meter area... would be positively stupid, even with such a limiter.

But, the simple fact is, Linden is almost 100% certain to never implement anything that can effect anyone outside a 10, or *maybe* 20 meter, range **ever**, so talking about me restricting it too much in that sense... is really just me being practical.



Well.. Yeah, simplest thing with attachments or rezzed "would be" to make it always ask. And that isn't really a huge problem, since its "stationary" things that really need some way to do it without all the usually mumbo jumbo. So, yeah, we are not too far off in that.


Umm... How? I mean, how is the destination server going to know that an object is "authorized" to redirect into your sim? Is the same prickly issue you get with attachments of rezzed. You would have to have some way to "mark" not just the original object, but any "copy" of that object, as "authorized to access my sim." Imho, it would be **much** easier to have an object that "belongs" to a group of AV, which owns the parcel send some sort of marked packet to your objects script, as a "dataserver" request, which contains the "encrypted request", hmm.. and like a session ID with time stamp. Your object then "passes on" this data to its own llTeleportAgent function, which causes the server to check if a) such a session exists, b) it hasn't timed out, and c) start the TP request (informing the client its taking place).

I mean, a lot of functions are "overloaded", in LSL already, which is to say, they can accept any one, few, or many of the data they "can" accept. So, its not that hard to make a function that takes an "unmarked and unencrypted" request and check it to see if its coming from a value object, that belongs to the parcel owner/group its being called in, or to run different tests, if the request it gets is not a SURL, but a dataserver packet, containing the session data.

If you start checking "destination" parcel, then you end up with a huge fracking mess, since it means you have to somehow authorize every script that tries to make such a teleport, and that.. just isn't practical. Or, well, the alternative is to test every AV that has/is using, the object, against some list of who is "allowed" to use things to get into those place. And, ok, that would work too, if you could test more than one group, which.. again, isn't so easy to manage...

However, I think you are overlooking a bigger problem. Since the point of having the "originating" object define the destination is to make sure they land at a "known" place, merely authorizing someone to TP into your parcel doesn't "solve" that problem. You "parcel" might consist of half a sim, and you might have 10 "entry points" for your system in that parcel. Without some way to force the destination to "only" be where you want it to be..., someone could simply script their own TP object, then, because they "are" allowed in, land any place in the parcel they wanted to.

Point being, how do you "prevent" them landing where ever they want, without restricting where they get the coordinates from, if the only ground for denial or allowance comes from if they are in the right "group" to arrive in the parcel? You pretty much can't. The control has to be from the "other end".

Well, actually, there is another way, but it adds even more data, which the servers would need to handle. They could allow "multiple" teleport points to be set in the parcel, so that any of them where allowed. Still have the same problem though. unless you chop up the entire sim into a mess of parcels, you can't "restrict" who gets to use which TP locations. Its a "lot" easier to add a new TP coordinate to the script in an object than the run over to 55,123,60 and make a 10x10 parcel, to use as a TP location. Even bigger of a problem if there are things already built there, and mucking with those things is going to fowl up renters, or groups, or someone else, but changing permissions on who can build there, etc. Basically, changing the destination permissions, and trying to control from that, where people go, makes is 100 times harder to do it.

Mind, it "may" be possible to say, "Allow objects owned by group Q to use teleport agent in this parcel", but the "destination" still has to be under the control of those objects.



But, as I pointed out, to work at all, it "can't be" the existing system. Especially if you have issue #2, below. Fast, in my estimation means two things a) if its in the same sim, its a bit silly to have to "relog" into the same sim. Mind, I don't know the technical reasons this is done, so it might not be solvable. b) it means not seeing the map at all, in certain cases where having you still standing there at the gate/teleporter-pad/what-ever-it-is fundamentally messes up the intent of the build in the first place. If I get TPed, I need to be "gone", not sitting there being asked "here is your chosen destination, do you want to go there?" lol



Yep. Would be really nice to have. Sit teleport sort of works, but since it still requires you "do" something... But, in such a case, having it "ask" isn't so bad, if the point is just to make it happen when you step on a teleport pad, or something. For things that are supposed to work like a gate, you "don't" want it asking, or you having to click, or any of that mess.

Yeah. That is one of the issues. Mind, even having to say yes *every time* would be a huge improvement over the current, "click the object or maybe, if its working, collide with the worm hole, show a map, then click teleport, then.. maybe get there.", which mean while 4 other people have just walked into you, trying to walk through the same gate. lol But, I do think there needs to be some means to better control in-sim TP, and inter-sim TP, where you want people to be able to get around TP hubs or restrictions, but you don't want them to have 100% complete access to just TP in where ever they want. The current system is either basically full access, newbies and veterans both get treated the same, or you can't enter at all. It makes things like TPing from the faction base in some place like.. South Beach, to some back alley in Little China, where say, someone set up a temp "portal" (same chain of sims, but with 2 others in between them), instead of jumping from SB to the LC teleport hub, an impossibility, even when, in the case of these sims, there may be a valid reason that it "should" be possible. And that doesn't even include basic stuff, like the ability to go from the the nearest TP hub "to" your own base, if you just arrived in that chain of sims (one way trip, one hopes, or people would use it to cheat all the time). lol

Hmm. Actually.. I did have a thought, and its one that "could" work with something like the stargate system, but then those systems are designed with DBs behind them, and a complete communication system, so.. not sure how practical it is. But... technically, what is trying to be solved here is that we have personally originated "request", which must be "local", which needs to act like it was "another" AV, presenting an "offer to teleport.

In that sense, your idea of the destination driving the event would make some sense. However, it means that the back end, which handles figuring out if the person "should" get the request at all, has to be done a bit complicatedly. In essence, someone, say, walking into a teleport pad has to initiate these actions:

1. On collision: Local script calls some ll functions to tell the "distant" TP object that it needs a hand off.

2. Distant object, "maybe", receives the message, "maybe" somehow checks that you are in the right group, and thus figures out if you should be sent an offer.

3. If you pass the tests, it calls llTeleportAgent, which "maybe", manages to pop up a "object XYZ sent you a "Join me in Blah!", accept?

4. "Maybe" the teleport works.

The problem with this is, obviously, there are a lot more maybes. A "purely" locally driven system, with restrictions on where it can send you, based on ownership, has only three fail points, a) you are not detected as a valid user of the system, b) your destination isn't owned by the right people, or c) system lag causes the TP to fail.

The "destination pushes the offer" system has:

a) not a valid user.
b) lag/network issues prevent your gate network from finding the destination object at all, to send a message to it.
c) lag prevents messages *to* the distant object, once you know which one it is.
d) SL is having issues with profiles, so the offer teleport system isn't working right (sometimes it will work for friends, but not group members, or total strangers, etc.)
e) lag prevents the TP at all.

Lot more things can go wrong, but the biggest problem is simply that you need a much more complicated script and communication system to make it do it at all. And part of that is "precisely", because you can't currently find if someone is in a group they are not displaying the tag for, and thus test against groups the object doesn't belong to, if they are in neither the objects group, nor wearing the allowed tag.

But, if that where fixed... you're right, a destination pushed system would be feasible, just... buggier than hell, even compared to the existing TP system, given the existing issues with the components of the current system that would need to be used to produce it. But, it would work with the *existing* "offer teleport" method, even if that did mean you would have to click "yes" every time.

Actually, most of the necessary code already exists in the client and the server. This feature was all but released in SL 1.8 then pulled back and re-released as llMapDestination.


If the sim owner puts a TP hub in, or the parcel owner puts a landing point, then that's their choice, and it's in no way the perogative of llTeleportAnything to bypass that.
I see absolutely no need to limit distance. I don't even understand what problem you're trying to solve by limiting distance. It certainly won't stop a teleport loop... your malicious landowner could simply put a new teleporter in range of the target location. The only ay to stop a teleport loop is in the client, by having the client ignore teleport requests during the "cool down" period after a teleport.

And it MUST be the client that limits you. The server can't do it, because it doesn't know how you've been teleported.

Why not? They don't limit the range for llTeleportAgent() or llEjectFromLand() or llUnSit() or llMapDestination(). Limiting the range doesn't protect you from malicious behavior. There's no reason to throw extra restrictions in when there's neither precedent nor need.
There's no reason to always ask for attachments, and precedent for attachments to not ask. There's good reason NOT to make it ask for attachments or landowner requests.
You're the one who wants this capability. I'm just speculating how it might *possibly* be implemented. The only way I can see that it could be done securely would be for the requesting object to encode the owner of the teleporter, the time, and a hash known to the sending sim, into a packet sent to the client with the request. The client passes it on to the receiving sim when it initiates the teleport. The receiving sim then gets the hash from the sending sim and decodes the using that hash, and sees if the owner is the owner of the destination... and if so it would allow them to bypass, otherwise it would just reject or redirect them as normal.

I'm not talking about anything that's visible at the LSL level here, I'm talking about how the existing packets that SL uses to implement teleports would have to be extended to provide the functionality you want. I'm not asking for that functionality, so I don't care if they do that or not, but you might find this useful when you write a JIRA request for an override capability for llTeleportAgent().

Simple: only *you* (that is, objects owned by you) can override it. If you want to have a HUD do it, the HUD wouldn't teleport you itself, it would just call...

llRegionSay(SECRETCHANNEL, "SECRETHASH"+target_number);

Then somewhere on the sim the user is in (this would only work if they were in one of your roleplay sims), your teleporter object, on land you own, would wake up and call

llTeleportAgent(llGetOwner(speaker),llList2String(legal_targets, target_number),llList2Key(legal_targets, target_number+1));

Where legal_targets is:

list legal_targets = [ "MyRolePlaySim1", <102,34,56>, "MyRolePlaySim2", <112,44,21>,...];

You DON'T relog int the same sim when you teleport within the same sim *right now*, all that happens is the sim moves you to a new location. All "fast" means is for Linden Labs to go "hey, we're not doing all that stuff RIGHT NOW for intra-sim teleports, so why are we bothering with the 'whoosh screen'?"

I'm usually OCD enough to make it through posts and grasp the details, but this thread really has me in "tl;dr" mode. I truly don't understand what the big deal is here: why should llTeleportAgent() behave any differently from what happens when somebody pushes the "Teleport" button on llMapDestination(), with permissions automatically granted for attachments and sat-upon objects, and otherwise explicitly requested? Is there some concise way to explain what other problem we're trying to solve here?

As best I can glean from the discussion, it seems there's a desire to be able under some circumstances to override the Landing Point on a parcel (or maybe the hub of an Estate sim, for those few who still use that kludge). I don't support that. At all. Either a parcel is Teleport Routed or it's not; I see no need to be inventing new, sometimes-true semantics for this. If this is something "stargates" currently do (I don't immediately see how they could), then I wish they didn't. But really, the damned things already use enough prims to pave a sim; it would be easy enough for a parcel owner to carve out a 16sq.m. destination parcel without Teleport Routing, if it's that important for there to be some place where some agents are supposed to be directed some of the time.

(You may sense I don't have much affection for "stargates." That's because every time I join land and forget to set auto-return, within a week one of these things gets rezzed there, chat-spamming away about all its internal misadventures and throwing off script errors.)

There's actually two unrelated issues.

I want to be able to build a door that you can walk through that takes you to a location elsewhere in the sim without breaking the narrative flow of the action by making you click on something (either on in-game objects, or a dialog). When they announced llTeleportAgent I promptly built a mock-up of such a build, using old-style sit-teleports to simulate underground tunnels, and showed Torley... who was over the moon about it... then waited... and waited... and waited... and we got llMapDestination.

But I'm not bitter.

Much.

Kagehi seems to want to use teleports to solve a problem in role-play, where he wants to be able to move people to locations they're not able to teleport directly to. I don't believe this should be allowed unless the person who owns the destination parcel is doing it, and I'm suggesting possible mechanisms whereby this could be implemented without violating that obviously essential constraint.


That too. One of the members of the Coonspiracy has set up one of the original Stargates on our parcel, and they seem to be relatively well behaved, but there seem to be at least a dozen competing stargate networks now with ever-fancier gates and ever-more-complicated sets of accessories so they can *sell* something, and none of the "modern" ones are worth scent-marking as far as I'm concerned.

They don't want to add grief vectors. They don't want to have to redo the way the permissions system works.

Umm. What part of "In RP sims, you may want to be able to set up "in sim" *and* inter-sim destinations, even **if** there is a hub, did you miss exactly? And, I am sorry, but seriously. I have no problem with some sim owner deciding to set up a hub, but I, and a lot of others, have a "major" issue with them screwing their renters, for no other reason than that they didn't realize one of those renters what using one of these systems.



What? I can't think of the logistics from Linden's end and conclude that setting a limit for such a fixed object is something they are "likely" to do. These sort of things are invariably trade offs. Odds are, they won't provide us with "exactly" what we want, due to their own concerns, so showing you can meet half way is better than saying "Well, unless it does *everything* we don't want it!"



Umm. First one doesn't exist, which is the point, the second.. Well, they have to be "on your land", but the purpose is clearly broken if it only hopped you a short distance, N0 idea what you mean with UnSit, since that only works "in" the prim you are on, so *technically*, unless you use "WarpPos", it *is* limited to 10 meters, and the last one makes you jump through some hoops before you can do it. But, I think you are confused. I mean 10 or 20 meters being the limit of how far away you are from the object for it to teleport you, not how far it "can" teleport you. Just as you have to be in range to "touch" a gate, or other item, to get llMapDestination from something.



Yeah. Could be done behind the scenes, but basically the same thing I said in a prior post.



Hmm. Ok, limiting it to "within the same sim" isn't going to work for the case I have thought about using it before, but.. Yeah, something similar could work.. That way "having" a hub would say, trigger a teleport_detect() function. Mind, the only **huge** problem here is, you are adding more delays this way to the system. The server has to then make sure there are no teleport objects *in* the sim *before* it can teleport you at all. **Very** bad idea. Would be better to have something like.. llSetValidTeleports(list valid_list);, where the Linden DB keeps track of which ones the land owner has "turned on". That *is* the only way I can see it working. Your, "listen for a teleport, then check against a list, then tell the server "dude, its like OK man!", adds even more lag, delay and breaking points than the "offer teleport" system currently does.. And it can be flakier than hell already. But, the biggest one is the added lag in the destination sim figuring out if someone is "using" such an object.

I didn't miss it, I just believe that the appropriate course of action in this case is to engage the sim owner in conversation on the subject, rather than bypassing them.
I'm simply noting precedent.
Sorry, that was a typo. I meant llTeleportAgentHome();
Landowners can unsit anyone on their land.
There is an active exploit involving an object that surrounds a user with an invisible prim, waits for them to click anywhere, then retreats to the far corner of the sim so the user can not identify the prim they clicked on and proceeds to spam them with map requests to the point where their only recourse is to log out and log in again at a different sim.

This kind of exploit is precisely why I have been recommending a "cooling off" period after a teleport request of any kind for, well, the past year or two.

Well, its a pretty simple issue really. With RP sims you want to make sure *everyone* has the rules, and the meter being used, *before* they enter the main sim. This means making that *entry* a hub. The problem is, every single sim in the chain, and, for example, the CoLA system has, lets see... 11 sims, not counting the now connected "Damnation" sims, which have another... 5, or maybe six by now. Due to this basic requirement for handling new visitors, long time players can't "enter" the sims any place else either, nor can teleport networks be set up between the sims *at all*, because nothing can get around the hubs. Which means you can't make any sort of faction based teleport systems, hidden means to get into other sims, or anything else that makes Roleplay sense. Nor is it possible to just "make a patch of land with different rules",, because hubs redirect "all" traffic, as I understand it, not just per parcel. That is why they are a region hub, not a "parcel entry point".

So, yeah, there are two basic problems here:

1. You can make sure new arrivals go where you want them to, while allowing people already in the regions more access/options.

2. The system they did implement isn't automatic, even in the sense of how "offer teleport" does from a profile, but instead forces you to see a map and choose to be teleported.

In other words, it doesn't do what "either" the people that mostly think it works now wanted, or what the people that want some control of where people come "into" a sim, but with the option of, once they are in there, of providing other means to get places, with what they are really looking for.

And, the sim owner, in the case of RP areas says, "Sorry, but I want all new people to got to X,Y,Z, and there **isn't** any way to allow someone else to teleport anywhere else, *unless* I put them in a group that has full permissions, so no, I *can't* allow it. That is the point. If there "was" a way for them to allow it, it wouldn't be a fracking problem.



Ugh.. Ugly, yeah. Hmm. Maybe.. Sure I can see some people whining about how they TPed to the wrong place, and couldn't TP back immediately though.. lol But, yeah. Maybe.

Then I would guess you need to move to a sim where the sim owner is less interested in micromanaging things. I have had good experience with Alliez Mysterio, myself.

Thanks for the clarifications. At least I understand a little better.

The bit about breaking the narrative flow by clicking on a dialog: I do think that an avatar has to give permission to be teleported, either explicitly or implicitly by wearing an attachment or sitting on something, even if the script is owned by the parcel owner. But the prim containing the script that does the teleporting isn't required to be the prim that gets the collision event. So, if it were me, I'd have one script in the sim for each agent from whom I wanted any kind of permissions, and have it do what it's told by other things, such as this collision target, or a touch-to-animate prim, or whatever. An alternative is to make everybody in the sim wear some attachment that does all that stuff to them. I just think it's less "immersion intrusive" to grant permissions once to some object in the sim, rather than having to actually find and wear an object from inventory.

(I once tried to solve much the same problem with physical push, but no matter what I did it was just too rough and unpredictable a ride. That was with H1, though, so maybe things are better now. Still, it would be way too slow for the kind of trick I think is envisioned.)

I don't mean to ignore the problem about estate telehub routing, I just never thought about it before. Intuitively, it sounds like something that should be controlled by a Group Ability: if the land/estate owner wants to let just some folks teleport wherever they want, they should be able to assign those people to a Role that allows it. But maybe I'm still missing the whole point altogether.

Why? The parcel owner can already do pretty much any damn thing they want with the avatar in the name of "security", including things that are far more disruptive than a single teleport that can, for several months now, almost always be reliably cancelled. They can throw them around, teleport them home, eject them, trash their vehicle, cage them, bury them and crash their client, and I have yet to hear of ANYONE being sanctioned for it. Requiring someone set up a secure and reliable prim-prim communication script to get a subset of that functionality would be profitable for me, I suppose, but that's not what I'm here for.

Hmm. Good point. But the parcel owner can't animate them nor track and control their cams, which is what I spend far too many lines of code working around. But you're right: if I as parcel owner can push them to kingdom come and eject or teleport them home, I'm not sure why I shouldn't be able to do all these other things without the "pretty please" routine.

Sigh. It has nothing at all to do with micro managing. There are two basic reasons:

1. There are rules stating you "must" have a meter to RP in the sim at all, and this rule exists in nearly all of them.

2. You are not allowed to TP in help, in "any" way.

The first issue can't be fixed unless you make sure people see the rules, and get the meter, before they go to other parts of the sim. Despite this, some are a bit more lax in how they handle the hub (main sims place them in subways or basements, so you have a "captured" audience who you hope will actually read the rules). The second one.. Well, if the only way you can get help to you is by using "offer teleport", having 10 people show up, out of thin air, at a fight, is ***absolutely*** obvious grounds for banning.

The RP itself is quite open, but the whole point of having the meter is to provide a way for mostly "fair" fighting, which if, for example, some faction with 50 members could all just pop in by "chance" to kick the ass of someone they happen to "notice" is fighting one of their own, well.. that's not fair any more.

However, there is no practical reason why some group of mages wouldn't have a "portal" linking two different bases, and for there to be "some" allowance for people to show up from the other base, if the first one is attacked.

But, whether you think its micromanaging or not, the key point is that the current system is binary. Either you have no permission, or you have all permission, with no way to design anything else. And the, "Well, just set up a parcel that has different rules.", concept is a) harder to manage, and b) won't work, since you can't provide ways for people to TP captured people to their bases, TP with a group that "is" allowed, or, if you just let anyone do it, prevent someone from landmarking the entry point, and TPing there direct, bypassing the "intent" of the design.

Its about providing better options. The current systems is **not** designed with RP in mind, or with any sort of system in mind that isn't a strict "one entry point only, then you have to walk/run or fly there", or, "anyone can arrive any place they like", design. If you want anything in between those extremes, its just not feasible to do it, as things stand.

They can do that already. The CoLA land group contains everyone that runs as a GM. You *want* GMs to be able to go any place there is possible trouble, like a griefer, or someone without a meter who is trying to fight, or some nimrod with a DCS meter, who is trying to fight in a CCS sim, etc. You ***don't*** want the general players to teleport every place they want. However, you might want those people to have some "limited" TP allowance. Examples:

1. You join faction X, and you want to got to their base when you get in the sim. Allowing the person, when first entering, to TP there instead, might be helpful.

2. The Coven have some plot going on, but it depends on them escaping from Rampart to their main shop, 4 sims away. It might be useful if, as part of the RP, they could establish a temporary portal some place, which teleports them "direct" to the shop, but with a small risk that it doesn't close before the people chasing them get there (in which case, some of their pursuers might end up inside parts of the shop that are normally "warded" to prevent unauthorized people from getting in (door, or similar that only lets Coven members in).

3. More permanent "portals" that could link key locations, between different sims, providing a "short cut" for those that know them.

And so on. Basically, anything where you don't want "let them go anywhere", and where, "only let them go here", is just as useless.

Got it. A couple of reactions: First, it seems like you're looking for technical enforcement of a role-play rule; although it may be feasible for this particular rule, the really important role-play rules just can't be enforced by technical means. I guess I'm suggesting that it's sort of debatable how much effort should go into supporting this, given that almost everything else about role-play (no-fly, limited or no-scripts, weapons specs, proper IC texting, etc.) has to be manually enforced anyway.

But also, is the premise that llTeleportAgent() must be accompanied by a "fix" breaking the warpPos teleport hack? Every RP build I've done has had to resort to various ACL-driven warpPos teleporters, to let some in and keep some out. Granted, warping across sim boundaries is... treacherous, but on the plus side: at least there won't be "hostile" parcel settings in the way, the usual downfall of long-range warpPos.

lol Yeah. No hostiles, in principle. Thing is, I can imagine cases where someone might want to use my suggested idea even in non-RP. Sit teleport and WarpPos have.. a lot of bugs in them, not the least of which being that, instead of just "not" teleporting you, they have been known to "relocate" you to 0,0,0 in a sim, before getting around to moving you to where you where supposed to be in the first place.

In principle, you are dealing with "similar" situations with gates. If someone wants a gate on their land, but the main sim is bought up by someone with a very different intent, it would be nice if the guy that was already there could ask, "Heh, I have this gate, which isn't working any more, but it uses the llTeleportAgent thing, could you "allow" it to work as intended, so people coming to it are not diverted to your new hub?" At the moment, this isn't even a possibility.

Its not as much a matter of enforcement and just practicality. WarpPos has practicality issues, not the least being that the only way to make someone "non-visible" while using it is by cloaking them, which only works if *every* attachment they have has some transparency in it. Its a lot of things, enforcement just being one of them.

If someone's warping they don't show up anywhere except at the start location and the end location. The whole point to it and what makes it work is that the whole process takes place within a single physics frame.

Hmm. Must be using some bad teleports then. "Some" do seem to work like that, others... Well, not so much. lol But, good point.