|
|
|
[
Permlink
| « Hide
]
TheVerity Hax added a comment - 17/May/07 12:46 PM
I believe it should work just like llMapDestination(string sim_name, vector position, vector lookat), only instead of it bringing up the map it just auto teleports you. To stop grifers it should stop working @ both the request of the land owner(much like disabling scripts) or by making the object physical. This would stop people from making bullets for a gun the insta-teleported people.
Yes, disabling the ability for llTeleportAgent to work when the prim is physical is a good idea.
Also, if Linden Labs worry about it still being abused how about also having it work much like someone sending you a teleport request. So, llTeleportAgent is triggerd on a phantom prim with collide and the little blue box pops up in the corner with the two buttons "Teleport" and "Cancel" Always a possibility but I'd rather not have to have anything come up @ all, making it much more... well instant.
 I just looked on the wiki and from what LL has released it is planned and should react like this...
llTeleportAgent(key avatar, string simname, vector position, vector lookat) and this will require agent permission. What if the permissions worked similarly to animations when you sit or attach an object... in other words, have it automatic if you're linked to the object that wants to teleport you? This would rock for HUDs.
Then again, just the mere implementation of this would also be fine The whole point of this, is to get somehting like llMqpDestination, but sw lot simpler and less obtrusive. So that we can make things like stargates which teleport you when you walk through them, rather than having to click anything. To that end, it shoulod work without permission if:
The object is trying to teleport it's owner. Yeah, although, using a simple "Offer Teleport"-like dialog would do it just right. Or, you could have a list of assets that you automatically allow to teleport you, much like the Mute list. This would rock, and if it was able to publish using in-world "packs", you could buy a Stargate-Compatible add-on to your list ..
I've been eagerly awaiting this feature for quite some time now. I believe it should work just like llMapDestination, with the exact same restrictions. Forgoing those restrictions, PERMISSION_TELEPORT_AGENT would also suffice quite nicely.
I disagree with that it should be allowed while sitting. Considering this would cause incredible amounts of avatars stuck in animations. (Then again, that probably should be considered a bug that animations aren't all stopped automatically on teleport) Those who've wanted this for ages, yes, I'll confirm this has been a much older issue which we originally wanted to include in 1.7 I think, and said we'd put in 1.8. Many versions later, regrettably, it still isn't included. Some work was done on it in Jan. 2007 which was getting close to being put on the Beta Test Grid, but much busy-ness has occupied us since then, so llTeleportAgent continues to await...
Nonetheless, thanks for your interest and keeping it alive; I'll link this to the internal issue. Actually a discussion on this topic and how it should work has popped up in detail around version 1.12
http://forums.secondlife.com/showthread.php?t=117703 A summary of my ideas presented are teleport throttling (a short delay before scripts can teleport anyone again, which gradually gets larger with subsequent teleports in a given time), and a "grant <person> permission", "grant <group> permission" and, "grant friends permission" option in preferences. This would allow trusted individuals, groups, or your friends to teleport you without need of permission. All others would require a pop up asking if it's alright. @Feynt:
I don't see why all that would be necesarry, to be honest. Throttling could (would) be done with a static sleep like every other throttled command, probably. I also don't see a need or use for permissions outside of per script run time permissions. Who really wants to grant full "Summon" rights at any time to a person? I'd be wary of such a thing. The only other major limitation I think should be in place is that an agent should have been fully loaded and in the sim for at least 30-60 seconds, enough time to remove an offending attachment that may be trying to teleport them too much. This limit would be irregardless of which script that called for it, thus the script sleep time on llTeleportAgent wouldn't have to be as long. THe land owner should be able to use this on anyone on his land without their permission, Likewise, an object deeded to the group, on group owned land.
And it should NOT be disabled for physical object. Having the ability to do this would be useful. For example, in a roleplay area. You could have a bullet teleport someone to a location on their death, while there is some effect in the place where they were. This would allow, for instance, vampires to disintegrate into dust. This important feature hasn't even been assigned yet to anyone!!!
What I would like to know is that the linden work on all day long?! They release new versions of SL all the time, but have you noticed something? With every release SL becomes more unstable and useless, they don't really add anything new, and that voice thingy is a peice of crap which people already DON'T like. So my question is what is the point us, the users, requesting new features if the linden don't give a f*ck about what we need. Peace out! I'm going to go with Ryozu Kojima on this one - i'd rather see per-script runtime permissions.
Regarding those who want llTeleportAgent to work for parcel owners without needing approval from the target agent: I dont really like the idea. If you want to have a bullet teleport people to specified locations, their roleplay game attachment should be able to take care of this without permission already (since its owned by the avatar and attached). If you want to kick someone out of your parcel, you can already use llTeleportAgentHome and llEject. There's no need for pin-point accuracy when you just want to remove someone. There are times when llTeleportAgent would work better without asking for permission when owned by the parcel owner, though: One of them being the Stargate, which would better when teleporting on collision with the event horizon without having to open a popup. Still, its a pretty minor thing compared to the abuse potential of being teleported to specific locations without your consent - yes, even by the all mighty parcel owner. You don't need to allow it for physical objects for role-play, if it's allowed for the landowner (and the griefing potential for any "only allowed for the landowner" calls is negligable, because the landowner isn't anonymous and the landowner has more to lose if they're TOSed), the bullet can llShout(SECRET_CHANNEL, "secret_word"+(string)llDetectedKey(0)) and the landowner's monitor prim can do the work.
The minimal potential for someone to repeatedly teleport you to some place unpleasant when you step on their land, instead of using a cage or llPushObject to do the same thing, can even be solved by applying the following three steps: (1) When teleporting within the sim, don't bother with the "teleporting" screen, just move them. That way the user retains control, without losing the narrative flow of the build. Stargates are just the beginning of what this would allow... you could have non-linear builds, where (for example) a prim "cave entrance" in the side of a hill teleported you seamlessly to a skybox "cave", or have an "infinite corridor" effect, or more practical elevators and turbolifts, or cleaner transitions between scenes for machinema, ... I've used "touch teleports" to fake some of this and it's a poor alternative to a real teleport call. A little thought. Whether or not it's needed, what is the point in restricting it from physical objects?
Any object should be able to do it if it has the permission. Honestly, I cant believe we don't have this already. Imagine web pages without hyperlinks to sub pages on the same site. I agree with Argent that sit teleport hacks are a poor alternative.
There should definitely be an option like this in SecondLife! There are so many possibly uses... You could walk into a TARDIS replica and instantly be in a bigger room, or walk through a Stargate and be on the other side the same was as the show! I've always wondered why there sn't something like this already.
There isn't something like this, because it promotes freedom through anarchy... I call it 'Griefer Fear'. It's so simple to implement and of course Argent's protocol is adequate to a real time situation where one has no prior knowledge of the web that they are entering. BUT... and here is a big hole through which giant virtual trucks are driven through in SL... in almost ALL role playing scenarios, permission is 'already given'.
In other words, if I enter a game environment, I should be presented with a check list of permission choices. I will either sign off on an adequate number of those necessary to meet the minimum requirements of the game, or I will be told that I cannot play. Simple. So.... if I enter a game, or a parcel, or a sim ...and sign off on the 'permissions list' previous to exposure to any of the 'approved' actions and events I might encounter in those contexts... THEN, I should be able to seamlessly flow from one event and action to another, without having to stop each time, and reassert permissions! Example: I go to to SIM X to play a game of 'Portals'. When I seek to enter, I am presented with a list of permissions, (which maintain a safe key combination to 'escape' if I change my mind, that teleports me instantly out of my 'preapproved activities', to a safe zone). Now, ...if I accept enough of the permissions to gain access to the SIM X game ...it begins. There, simple. SL presently... is like going to Disneyland and getting on the Pirates of the Caribbean, and before each turn to each new scene, the boat has to stop and each passenger has to give approval to see what is next... its quite ludicrous! NO? ...yes. SO... I vote for enhancing ALL 'permission requiring actions and events'!, to be able to be 'batched', as long as an 'escape key combination' described in the 'batch agreement', is respected. For the first time today, I was programming a scripted device in SL, and I suddenly realized... : "this would be much less hassle if only we had llTeleportAgent()!"
Torley Linden,
It Could be Cooler This would permit people to have the teleporter effect (particles/sound) move with the agent to the destination. Then the prim can unsit the agent and delete itself, or in the case of vehicle continue on it's way. We already have plenty of ways to teleport around SL. What llTeleportAgent can do is let us dress it up with exciting special effects. Taking a prim with us is the only reliable way to do this as llEmail etc are far to slow for communications. For an example of just how cool a teleport effect could be with this. Go to my shop in Meyers and try the Quantum Transporter. You want to ride it with the camera attached and detached from your agent to get the full effect. Now imagen the teleporter prim being able to take you to another region. Too Cool! Being able to teleport someone somewhere is no fun unless you can dress it up like your faverite Science Finction tv show. Other Issues Permissions for teleporting while sitting on a prim should be granted by default to make intergration into existing teleporters seamless while permission for those not on a prim should be presented as a dialog box offering to teleport you complete with a mute function for those who might use it to direct customers to their shops. I would imagent sitting on a normal WarpPos teleporter prim that begins the particles and sounds. The prim moves to 768m high to make the teleport look faster than it really is. Then Issues a llTeleportAgent to move the traveler to the destiantion region. (hopefully with the prim they are sitting on to continue the particles and sounds on arrival - hint hint) In the case of something like walking though a stargate the agent would be offered a teleport dialog box similar to when their friends offer to teleprot them. (which is what I suspect you are already planning) Note: Teleporting a prim with an agent on it will not be the same as teleporting a prim alone which would be risky for grid wide replicating objects. Darling (teleporter junky) Brody This can be done now (since the new search) by using the teleport app: secondlife://app/teleport/<sim name>/x/y/z/
Should clarify, this can be somewhat done now similar to a SLURL but without the map (so can't be used in a collision event or anything like that) by using the teleport app: secondlife://app/teleport/sim%20name/x/y/z/
Harleen Gretzky,
Thats a cool use of the function. It works very well in the chat output of my object scanner. I tested it in llOpenURL and it failed So you still have to open your chat history and click on the URL in there for it to work. Darling. Bumped up to critical because LL are taking their sweet time about this thing finished >.< Torley said it was almost ready for testing on the beta grid. Get on with it ;_; pokes LL with a cattle prod
I can't believe I hadn't voted for this yet.
You can play with fast teleporting using Dale Glass's homebrew client. It's really very cool .It will be great to be able to do it in lsl. Primarily, I want a working stargate that teleports you when you walk into it. It would also be cool for personal teleportation devices. Downgrading to normal, upgrading priority shouldn't be used for the sole purpose of bugging LL to get on something (except for bugs and such) especially since they've already acknowledged that they're working on this. I'm definitely voting for this though since it's a great idea and I've always lamented for years that Stargates can't do touch teleporting.
As an IT Engineer, I would have to disagree with your statement Gordon, but hear me out.
I disagree because the priority lets Linden Labs know how much people want this feature, instead of just how many people have voted. If I was to see two requests I would go for the one with the higher priority because there is more of a business case for doing so. In Linden Labs case good publicity, more people would be more invested in Second Life because of word of mouth and the fact that it would make alot of people happy that they have sorted out such a long running desire to have this feature. If people do feel that strongly that they think this is a critial request and should be put above other requests then so be it, at least Linden Labs know how people feel. From talking to Second Lifers, this seems to be the case. I will like to say this though, I completely agree and understand that security bug fixes must always be a P1 to correct or as Linden Labs calls them, Show stoppers and therefore take priority. Wyvern: I have to agree with Gordon. Priority shouldn't be used as a "supervote".
On the other hand it could be argued that the priority should be increased because the alternative mechanisms used to implement the subsets of teleporting that we CAN do involve a lot more overhead from the sim. In addition, this would be "low hanging fruit" - easy to implement, since they already implemented it for the 1.8 beta, and would produce a big benefit for Second Life. The ideal implementation would disable the "black screen" teleport screen for teleports within the same sim... it would just move you as if you'd been sitting on a prim using WarpMove. That way all the existing WarpMove teleporters could be replaced by portals. Major maybe but definitely not critical, I'm not going to bring it back down to normal since I don't feel strongly enough about it to get into a whole war of how major it is but there's no way that this is a critical issue. Moving down to major.
I would set thing up so that portals are linked to controllers (ie Stargate + DHD) then you would have to actually Dial the destination then move to the Ring to teleport. besides if the addresses use SG-1 type
addresses (39? symbols 6-8 symbols in the address) that would be 38! addresses and how many square meters are there in SL Total?? I would also implement an "iris" function so that somebody that doesn't want folks gating in can make folks go "SPLAT" (as a subset/alt function of the plot regs) The whole Stargate is already designed all it really needs it the llTeleportAgent to make it so users can walk into the Even horizon is be teleported without all the hassle of a map or anything like that.
We can already click on the map to tp anywhere, so what would be the difference in adding the LSL function? Perhaps restrict it to Agents so griefers can't remotely grief? Certainly allow it to be triggered for touch and collision events.
Many RP sims tend to have telehubs for direct map teleporting anyway, and any RP sim owner who would want to join a loose network (such as the Stargate "network" The difference is that you wouldn't click on the map, or on anything, you would just walk through a volume-detect prim and materialize at the far end of the "stargate" link.
To prevent griefers from abusing it, restrict it like "push" on push-restricted land is, so that only the landowner can trigger it. You could further limit it so that llTeleportAgent wouldn't work on you until (say) 30 seconds after you were teleported, so you didn't find yourself teleporting over and over again. Linden Labs appears to be implementing a change to llMapDestination rather than implementing this. From the 1.20 viewer release notes:
Not adequate. Yep, just tried it out. All it does is open a window like you would see for a landmark. Also, it's completely useless if there is a region landing point set. I experimented with it, and no matter where you set it to send you, if there is a region landing point, that's where you go.
Every TP-Hack that has been implemented (like sit-target) 'n such is a pain.
We DO need a real TP-command! (and not one that's like the one LL attempts to implement now...) I think, the easiest and most useful solution to the permission problem would be to give it the same permission rules as animations have... If it attached, it TPs instantly, if it's rezzed, it needs permission to TP people.
Landowners still can use llTeleportAgentHome to get rid of griefers, and RP-people usually wear combat meters - The TP could be included there. The stargates could first ask for permissions while you stand in front of them, and then use them to TP you after you went through them. There is no "permission problem".
If it requires a prompt then it can't be used for non-linear builds like an endless corridor, "underground" builds with the "underground" part in skyboxes, stepping disks, or anything else where the continuity of the build would be ruined by requiring the user to respond. This has nothing to do with "getting rid of griefers" and everything to do with the effective narrative flow of Second Life. Not only should it not require permission for land-owner builds, but it should not bring up the "teleporting' screen for teleports within the same sim. Argent is quite right. If the object containing the script that triggers a llTeleportAgent() is owned by the land owner (or group) then end of story. Just have it do what we want without annoying popups. Land owners pay for pretty much everything in SL, it is time they were given the privileges befitting their rank.
 Argent, I'd agree with that if the landowner no permission needed thing was restricted to teleports only within the sim otherwise require a permissions dialog. I know that this would break implementation in stargates (which I love incidentally) but I think for builds that require teleporting to do this type of thing for effects not to mention for the new breed of teleporters I'm sure this will be spawned it's all inner-sim anyway.
Samantha, this won't work without checks and balances and I'm sure that this won't get implemented (hopefully) without checks and balances. I can only guess that you're trolling since anyone who's spent 5 minutes in SL knows that landowners indeed do not pay for everything in the economy or B) you are a hopeless extremist and should be pitied and marginalized. Gordon I refuse to allow YOUR own trolling to cloud the issue at hand, since anyone that has looked at SL can clearly see that most of LL's income comes from land sales and Tier. We are not talking about the SL economy where it is the members that make/spend the money here. I was merely trying to point out that if you are a land owner then you have either proven who you are and that there is an asset that can be taken from you if you are naughty. Unlike anonymous griefers. That IS what we are talking about here with safety popups. This function would be no different then doing a llTeleportAgentHome(), the same checks would apply. There is no reason to hobble the script to work only in inner sim without popups if you have the owner can be held accountable.
Note: I tried to be continuous in my thoughts however if they seem a bit fragmented please note the first paragraph came after the second and third were written so reading them 2nd 3rd 1st might make more sense. -G.W.
Samantha I apologize for my above statement, I was a bit extreme however the point I was trying to get across still stands that having a function being able to arbitrarily send someone anywhere on the grid at anytime with the minimum of checks (what about group owned land for example where anyone can join the landowning group? since you'd need new role restrictions for this kind of function) I see the point of being able to give smooth teleports since I am an avid user of stargates however there are issues with doing so. I wish I had as much confidence in landowner's doing the "responsible" thing and LL enforcing them doing the right thing however both from external accounts and personal experience dealing with certain landowners I have to diagree and of course we could argue why we disagree under the sun burns out but it's irrelevent why we disagree since the fact that not just you and I disagree but the fact that there is no common consensus among the community (and don't get me wrong I don't think we should be running sl entirely by consensus since we wouldn't get anything done) is a good reason why landowners shouldn't get a free pass on this. I agree that hinderences where possible (thus my inner-sim reccommendation) should be brought down where possible however there has to be a balance point on this. Another suggestion, it's a bit broad for this and should probably get it's own issue but it's related to this. What if a person could give a blanket pass for certain permissions either to anyone (with the "are you really sure blue dialog of scariness" or to specific people which would allow them to use these permissions without each time having these barriers. Yes this would be a barrier, yes it would be somewhat of a pain, however if for example you could say anything scripted by whoever the name of the stargate creator is can use llteleportagent on you then anytime you used a stargate you wouldn't need to give explicit permission. This is just a what-if of course but I think we really need to think outside the box on this one since llteleportagent is in itself a bit outside the box when it comes to function vs user decision balance. Gordon: why would it make a difference if the teleport is in-sim or out-of-sim? What threat are you trying to guard against by adding that requirement?
Within a sim sure you could repeatedly teleport someone over and over again (essentially forcing them to restart sl at home or at a different point) however it is limited within a sim, if you remove that limitation someone could literally be arbitrarily transported anywhere on the grid and that is essentially what many of you want which is a function that can arbitrarily function on an av. Also, if nothing else this function would have to be limited to touch and collision events since can you imagine llteleportagent working within a sensor event?, I don't think this would hinder any legitimate uses and this would of course mean that security systems couldn't arbitrarily tp people but since they already have enough functions they don't need the ability to.
Gordon: By your reasoning it would make more sense to limit intra-sim teleports than extra-sim teleports. The "repeat teleport" problem has already been discussed to death, and can be solved by simply having the viewer ignore teleport requests for N seconds after a teleport has completed.
What I'm getting at is... what is the problem you see that allowing teleports "anywhere on the grid" has that allowing teleports "anywhere in the sim" doesn't? You say "someone could literally be arbitrarily transported anywhere on the grid"... yes, so? What's wrong with that? And, yes, i can imagine it working in a sensor event. It would HAVE TO work in a sensor event to implement non-linear builds. With your proposed restrictions, llTeleportAgent would be no more useful than WarpMove and llMapDestination... in fact llMapDestination was originally provided as such a crippled version of llteleportAgent after llTeleportAgent was dropped from the 1.8 beta. I would rather it not be implemented at all than it be implemented (again!) in such a crippled form. Well think of it this way, if this is implemented say good bye to flying over mainland since any parcel owner (I'm assuming that the parcel owner restriction is one that you'll agree is needed) can send you anywhere else on the sim. Yes they can currently arbitrarily eject you and yes they can currently send you home but why let them send you arbitrarily anywhere else as well as to their parcel border or your home.
A throttle serverside I think would probably work better I think to prevent teleport spamming. Incidentally if you haven't seen any of my previous musings on sl I am in fact playing devil's advocate vs my usual position of not crippling functions due to griefing potential. I am personally still conflicted about this however these are serious concerns that really need to be adressed before this could potentially be implemented. Gordon, don't be silly. Not only can any parcel owner completely screw fliers over as it is, but you don't even have to be a parcel owner... you can use physical attacks to blast people and vehicles into orbit, and llTeleportAgentHome is already more destructive, in terms of screwing up a flier and preventing them from recovering their vehicle, as anything they could do with this... because it CAN'T be cancelled, which this could be.
So the idea that adding this relatively benign call would suddenly make people start using it for security... when there's more aggressive and powerful things that they can do already... is silly. "I'm going to set up a security orb that people can escape by hitting (Cancel)". The throttle would be client side. the client is the one that initiates teleports, not the server. Yes, there's serious concerns. But these serious concerns have been hashed out over and over again since 1.8. They have all been addressed, over and over again. Including the one you're concerned about.
"why let them send you arbitrarily anywhere else" So that you can build endless corridoors, and "underground" tunnels in skyboxes, and 4d mazes, and stepping disks, and portals, without breaking the narrative flow of the game. I've built all these kinds of things with long range sit teleports and warp move, and they just aren't the same. http://www.sluniverse.com/pics/pic.aspx?id=63686 That build doesn't exist any more, but you could walk into that culvert, and click, and walk down a tunnel, and click again, and walk out of the culvert on the other side of a hill... with the intermediate tunnel in a skybox. It was as convincing a scheme as I could come up with back then, but it wasn't good enough. With llTeleportAgent() it could be nearly perfect. This page is not a forum you guys. Some of us are watching this topic in our emails and I do not appreciate the continued spam.
To prevent griefing, this option could benefit in my opinion from a dialog menu pop-up asking permission to teleport the user. We already use llMapDestination for Touch event teleporting in the same way. A user should have to give permission by clicking one more button after the event is called to confirm before traveling. (Unless of course they have already granted permission by some other means like sitting or attaching.) I see Linden Lab STILL haven't done anything with this
 lowering back down, priority ranking should not be used as an attempted bludgeon to get LL's attention.
I think you will find that this IS pretty critical. It was promised back in SL ver 1.7, was on the beta grid for a week then LL got cold feet and pulled it.
This is a much needed LSL function for many many scripters out there that make teleportation devices, especially ones that have to currently rely on the annoying llMapDestination function. To them and many others this IS critical! this is the info they provide about what each priority ranking means, I hope this helps clear things out here
"Priority Levels An issue has a priority level which indicates its importance. The currently defined priorities are listed below. In addition, you can add more priority levels at the administration section. Showstopper Tigro, somewhat unfortunate that there's nothing on feature requests that's equivalent to what this is for bugs but even if you change the wording a bit to make it fit feature suggestions more this still does not meet critical level, there is no time rush on this, this is not an issue where content is just not being developed because this feature isn't implemented even if you have to use a less worthy function (and I don't like llmapdestination() any more than anyone else.
Wolfie, probably has to do with the fact that the extremists want this to be able to used anytime by anyone without even a dialog approval for it, the moderists want something more similar to the shortly lived way that llmapdestination worked with a mini window that showed the destination and an option to tp, and the luddites don't want anything like this ever. Not even taking into account that LL has stated that they take votes into account more than priority thus making how high the priority is moot for anything other than categorization purposes (I don't have the quote off the top of my keyboard but I can probably find it if you'd like) despite the fact that many issue reporters seem to think that the time an issue has been open should be a factor it is just illogical that the priority would go up just because the issue has been open for x days, months, years. I didn't post that to defend either side, just to provide material for an agreement to be reached
on a side note, I would love if somthign like this was implemented in away that would allow things like StarGates to work more "realisticly" but without opening too many opportunities for griefing (one thing I thought right now, which I don't have time right now to check if it has already been brought up before, would be to have both the land owner set the parcel to allow this function, and have it be limited to certain events, like collision, both on solid and volume detect enabled prims) Tigro, I agree on the stargates or how about star trek transporters or such, of course the problem is griefers, even if you limited it to certain events the griefers always ruin it for everyone else <sigh>
This is not a "critical" issue.
I've been pushing for llTeleportAgent since it was first rumored, and even I'm not willing to call it "critical". Gordon: hope you don't mean to imply that because I don't approve of a warning dialog I am therefore an extremist. Warning dialogs are not a very effective security tool, and there are much better ways to limit this call to make it useless for griefers than to force people to approve a dialog every time they step through a gate. Limiting it to scripts owned by the parcel owner, limiting it to avatars on the same parcel as the script, and ignoring teleport requests within even a fairly long period will leave a system that is "griefer proof" without breaking the narrative flow of the game. Argent, no I didn't, I should have been more broad (or was it more specific) with that statement, there are people who want this to work anytime, anywhere, with absolutely no restrictions which in a world without griefers would be amazing however we don't work/play/etc... in such a world.
Having this work with the same restrictions as llTeleportAgentHome() will be more than enough of a safety net against griefers.
I believe a similar level of grief can be done with rezzing a phys cage that bounces people away or somthing
having parcel owners choose if only the owners or if everyone can do it, and perhaps also limiting the destinations (only in this parcel, only to this coordinates etc), adding the instant teleports to the bumps and pushes log, and perhaps also including the ability to teleport among the abilities that get disabled when an object/avatar is muted and a few other things probably would allow this to be used to it's full potential without opening all that many griefing possibilities. Perhaps also make automaticly accepting a scripted teleport a toggleable options on the world menu or somthing. (displaying the regular teleport dialog if it is disabled, and showing one of those first time messages instructing newbies (and people unaware of the changes) about it) (of course, in the beginning all of those options would be set to the most restrictive by default, so no one would be affected by the change without being aware of it) Gordon: I don't think i have seen any comments from people who want it to work with no restrictions whatsoever. Certainly none that were meant to be taken seriously.
Wolfie: it needs a little more restriction than llTeleportAgentHome, such as a mechanism to prevent continuous serial teleports and the ability to cancel the teleport. Tigro: I don't think there's any reason to allow objects that aren't in the land group to do it, ever. I don't think that the additional restrictions you suggest are needed once it's restricted to the group. it coudl be used as part of game mechanics, someone might want p2p teleport commanded by chat etc woudl all require non-landowners to be able to run the command
I was thinking it could receive restrictions similar to llPushObject (except stuff like the strength crippling that came with H4, that sucks) I do not see why permissions must be such a fuss. It would be very easy to come up with a reliable and spam-free solution.
Consider that land-owners be allowed to use it on avatars that are on their land, much like they can currently use llPushObject, llUnSit, and llTeleportHomeAgent. No permission is required, because it is understood that a land owner, who is generally paying money into the game, will not use it incorrectly or abusively to the point of it becoming a grid-wide problem. There should also be an optional cancel button-- some may find use in this as a security system of sorts much like TPHome is used currently. (There are If, however, the script is If the viewer were to be modified in any way for such a thing, you might also be able to introduce a method for blocking all teleport permission requests, so as not to even see them, automatically denying them. This would save people who do not wish to be teleported at all from 'permissions spam'. Past the permission issues... I do think that this function has great potential, if it ever sees the light of day. It will be a great day when LL impliments this function... if they impliment it properly. Argent, the problem of someone creating a system of circular teleporting (A > B >A>etc...) to essentially trap someone in a tp loop is something that has to be adressed. How to do that without breaking seamless teleporting though is a toughie other than implementing a per agent throttle. the problem of course is that per agent throttling is tricky when the function is specifically designed to move someone across sims which (and I could be wrong) I believe most throttling is calculated and takes place.
Argent, see Arbitar's comment above, that's what I'm talking about to answer your point about the extremists. Arbitar, comparing this to LLTeleportAgentHome is a fallacy though because with LLTeleportAgentHome the assumption that can be made that the teleport destination is a safe location and one where they will not be arbitrarily teleported from as it is chosen by the person. No such assumption can be made with LLTeleportAgent since as currently described it could be used to teleport a person anywhere including spots that lead to having to reload or even an involuntary crash, a good example of a troublesome destination would be <0,0,0> or 0,0,-100>, even if range limits were put on the destination coordinates to stop you from making the z coordinates a negative or too high of a positive value there are any number of other ways to teleport someone involuntarily into a situation that will screw them up.
An example if I may: Person A goes onto person B's land in sim X, for any possible reason person A is teleported onto person B's other property but this time on sim Z, as soon as they hit they are teleported back to person B's land on sim X again and the cycle continues until person A either quits and relogs or B's objects stop attempting to teleport A. @Gordon
Yes, I suppose you're right about the llTeleportAgentHome. I should have given that more thought. Included in permission dialog boxes should be the sim/position of where you will be teleported. But for landowners, whom I think should be allowed to do it without permission, perhaps a cancel button should absolutely be required. It's use in security systems might be hampered that way, but upon more thought, it would be rather odd to have security systems have the ability to teleport you anywhere-- the only use I can see for that is if you wanted to teleport offenders to a specific area outlining rules of the area. Not particularly useful otherwise though, llTeleportAgentHome has found a good position as the 'security' teleport function. That way, I suppose security systems can't abusively teleport you anywhere, but only to a place you know. As for the recursive a->B->a teleporting, perhaps breaking the loop with a cancel button click. It might be interesting if the cancel button could temporarily disable script teleport requests for a set amount of time from that object. Please keep in mind that I'm not saying what I think absolutely should be done, I'm open minded-- a function like this could both be very useful and very dangerous. But the more we lock down and delay the operation of functions such as this, the less usable they can get. Implimentation of a function that can do amazing things like create non-linear builds and allow devices like Stargates and other teleporters to operate without fuss would be widely praised, even if it does indeed open the door for new greifing. I think it's imperitive that a balance between security and function is found-- if it's too secure, prompting every single time from everyone, etc, it will be useless (we could just use llMapDestination), if it's too functional, it will be abused by greifers. I agree, if it's dulled down too much you might as well use the map destination function. I'm thinking that different levels of security depending on the situation, attached objects could use it without dialog in all situations maybe (similar to most other functions for attached objects) lanodwners could use it without permissions in y situations but would need permissions in z cases, others might always require permissions....etc.
hm...I'm starting to see the point against completly automated tps;;;
how about sending the avatar to some sort of "limbo" in the origin sim so the avatar looks like it is already not there anymore (perhaps a negative, or way above 4096 altitude), and instead of showing the avatar to the user, show a screen with a dialog with a time-out for the ok, the screen would give information about the destination (perhaps similar to that window that opens when tping form a landmark), and besides the the ok button (would automaticly be pressed after N seconds (30 is too much?) to allow it to work completly without user interaction, and also a "time-in" system to keep it disabled for a small bit to help both with avoiding people clicking on the thing without being sure they want to, and to throttle the rate of auto-tps, or perhaps a checkbox that would be unchecked when the thing shows that only when checked the OK button would become enabled, perhaps have a debug_setting to define the timer for more advanced users), there would also be a button like "always accept auto-tps from this user" (and perhaps also "always accept auto-tps from this object"), as well as a mute button for the user (to mute everything by the user) and a mute for that object only (like for when a script goes borky and the owner can't fix at the moment, but you don't want to mute the owner, just get rid of the auto-tps), and of course a button to cancel the tp just this time (pressing this would send the av back to where it was when it was teleported behind that window the screen would be filled with a texture specified by the script (knda like a "loading" screen, to contribute to some extent with the suspension of disbelief, somthing like a screen shot of the teleporting effect or somthing. Also perhaps allow the command to choose between a simple window with just the name and coordinates of the destination in a corner of the screen and a regular full-featured window with the about land info and pics and stuff centered having an object, or avatar muted like this would prevent the auto-tp process from even being started, the user wouldn't notice anything if a muted object tried to auto-tp them edit:and perhaps under special conditions (like the parcel owner teleporting someone to another parcel owned by them in the same sim, and scripts tping their owner), provide the option of not requiring user interaction at all nor throttling timers, this would help with things like games that rely on auto-tps and gadgets to tp yourself llTeleportAgent(); should be allowed to execute automattically for your own scripts, and those of people on your friends list, or perhaps people you've granted mod rights to?
Alternatively members of your currently active group, so if the object that the script is running in's group matches your active group, it should be allowed to teleport you without asking. Other than that, it should give a simple yes/no like the current prompt when a friend offers a teleport. Gordon: circular teleporting is not an issue, because teleport requests are actually initiated and handled by the client (even llTeleportAgentHome: the server sends a request to the client that then does the heavy lifting) so the throttle would automatically be "per agent" and the "dead time" after a teleport would remain dead whether the teleport requests were from one object or many, one owner or many, one sim or many.
As for Arbitar's comment... he explicitly described a set of restrictions on it (in some ways more obtrusive ones than I was proposing)... he was definitely not proposing "unrestricted" teleports. Kosmos: tying it to group membership or anything else that requires access to the group database or presence server is a problem... these servers are bottlenecks, so extra accesses would just increase lag. Just an idea...
Wouldn't a simple way to make this secure is that the creator of stargate/teleports etc. are assigned a public private keypair, and then first time it asks me do I want to give permission to say everything created by that agent. If I hit yes then the public key is downloaded to client, and on transport it encrypts some data with it for the request to the server, and the server then decrypts it with the private key on the object (obviously the key must be no mod/no transfer/no copy by default). That way I can use stargates all I want safe in the knowledge no greifer is going to be a problem. And making a teleport revoke dialog is simple enough too. You don't need to implement any cryptographic security, since all the communications that matter to whether permissions are honored or not is between servers completely controlled by Linden Labs, and whatever security the rest of the internal permissions traffic involves would apply here as well.
Aside from the cryptographic stuff... having to grant permission for every builder would be barely better than having to grant permission for every build... unless you're only trying to solve things for big players like the stargate folks and telling the little guy to go jump in a lake. what do you guys think of my last suggestion? (the one with the av disappearing on the origin without being teleported while they don't accept or deny the tp and with the option to set to always accept etc)
I don't understand the point of it. It's just a more complex way of doing the equivalent of popping up a dialog box, and breaks the narrative flow of the game even worse.
What about adding a new button to the teleport status screen that displays while you're teleporting, so that if you are caught in a teleport loop, you can click the button to "Teleport Home" and thus break the loop.
I also agree that teleports should be "throttled" or disabled within x amount of seconds after you've teleported to prevent griefing, to give you time to load and such. This could easily be set to a minute or two, since most people don't teleport, and then telport again right away. Another idea, would be to have a button come up in your screen after you've teleported, and stay there for a few seconds to remind you teleports are "throttled", in case you want to teleport sooner. I also think it would be a good idea to prevent llTeleportAgent from acting on avatars outside the parcel the script's object is on, that would prevent it from griefing neighbors. As for people being able to set inhosipitable destinations, the command could be limited to above water and ground level at the destination, and within the sim's boundries e.g. above 0 and below 255 in x and y. As well as not above whatever the max in Z is, maybe limit it to 4000 or something. There's no reason for an additional button... the one called "quit" would break the teleport. In fact, if you "quit" out of a teleport that should block whatever teleported you.
The throttle should probably be quite a bit less than a minute, because you need quick in-sim teleporting for "non-euclidean" builds (for example, where you have a door in a house that leads to a skybox). And even a five second throttle, in the client, would be more than enough time for the user to react and break a loop. Yes, it would have to be limited to avatars on the same parcel... that's a given, and a limitation that already applies to llTeleportAgentHome. The destination would be clipped to the building volume of the destination sim. "Quit" not only breaks the teleport, but tends to log you out as well. Not what we want, as far as I can tell.
I still think it should be made like animation permissions. It would need permissions to TP you ONCE as long as you stay within the sim, not repeadingly, the same way as an script with animation permissions keeps those permissions. Additionally, a few seconds throttle, and an option to revoke TP-permissions, and everything should be fine. Attached objects should have the permissions to cause TPs as well, because with all those HUDs out there which open maps from landmarks within their inventory, it's sure that some people would prefere an direct TP from an HUD menu. those who liked my suggestions here please vote on http://jira.secondlife.com/browse/VWR-9200
 Yakumo: I have not had "Cancel" (not "Quit", sorry) log me out of SL in months.
I see no reason to pop up any explicit request and break the narrative flow of the game. Nyo... And I don't see a reason to invent a new permission system.
When you enter a build/Sim/whatever that uses llTeleportAgent, some kind of central TP-server object could sent you an request to be allowed to TP you, and would only need to do so once. Other objects just would need to send that object a message to use TPs indirectly. If you're using combat systems for roleplay, they could simply include it within the attachments, so the player automatically TPs on death, as attachments don't need to ask for permissions. Yes, it would need users to script such tools, but I see more possibilitys in functionality compared to simply restrict it to land owners. If it's properly used, it would just need one request per build/parcel at most, and with all those TP-problems SL has a sim change tends to break the "narrative flow" anyways, unless I'm the only one who has that. I don't see any interruption except at points where it interruptions are inevitable no matter what permission system you use. What you're describing is a whole new permission system. And it would still break the narrative flow for things like teleport gates.
I suspect I would personally benefit if it required a bunch of complex message scripting to use the new feature, but I'd rather have a clean design. The primary use cases for this are:
What scenario do you envision that would need a dialog? Well, I don't like the idea of the landowner automatically having permissions.
In llTeleportAgentHome, I decide myself where I get TPed to, by setting my home position there. It's a simple "Get out of here". llTeleportAgent, on the other hand, tells me to go to a place without me even knowing where it is, and I simply don't want anyone to be able to do so without my permission. If the landowner wants me to TP to a distinct place and not simply "anywhere but here" (Home), he can ask me at least once. The landowner permission dialog could be handled so it only pops up if the target destination isn't on a parcel said landowner..well, owns. Just a thought :>
Hmm... Well, I guess I wouldn't mind a TP as long as I stay within the same sim, yes. But grind-wide teleportation should be restricted, and not only by hitting the "cancel"-button. Sometimes when the TP works fast you don't have time to react if you aren't expecting it.
It;s only the in-sim teleports that happen that fast.
I have no objection to having a dialog the people who are worried about it can turn on, but I don't want to have it there by default. There's been too much capability in SL nerfed or eliminated unnecessarily as it is, and Linden Labs too often tends towards a sledgehammer approach that messes up perfectly harmless and helpful tools. If you don't expect them, an sim-to-sim teleport can be to fast to react as well. Mostly because an TP out of nowhere would be rather perplexing, and by the time you even understand what's happening, you might already been teleported.
There is already an "always accept"-option for notecards, I guess it wouldn't be to hard to make something similar for teleports. I think most of those concerns would be dealt with the stuff I suggested in comments here (most, if ot all, of my suggestions are collected on VWR-9200 )
If it's only automatic for landowners, then the absolutely worst thing that can happen is that you get teleported once against your will. Then you just don't go back to that parcel, or you turn the teleport block on. There's no need to make autoteleporting impossible, you just need to make it a lot less desirable for griefers than other tools they could use. If they have to own the land you're on, and even then they can't prank you twice, it's just not going to happen.
And this could be generalized. Things like asset drops, animations, teleports, all could put a message into chat, "You were teleported from URL/animated by/given a card by by USER NAME. Click HERE to ignore further requests by that resident." This discussion reminds me of push, which kept getting nerfed and limited until it's no longer usable for the kinds of things it used to be used for, like antigravity elevators. And long before it became almost useless people switched to using kinetic weapons for griefing. Well, I don't like if things happens to my avatar against my wishes, once would be once to often for me.
I'm fine with people having the option to automatically accept, but I, personally, would most definitely not use it. Argent, your making the pretty safe assumption that landowners won't use this to grief. To play devils advocate for the moment, if we didn't make that assumption then that negates your argument since a landowner could repeatedly and unlimitedly teleport you from parcel A to parcel B to parcel A to parcel B.... to their hearts content and you'd be stuck in a malicious teleport loop and be forced to quit and restart.
Hey Folks! (notably Argent and Gordon). I think you've been arguing enough for the past 3 months and made your point. JIRA is not a one-to-one discussion board, please refrain from endless arguments here for the sake of all watchers.
Such discussion can take place in a Meta issue or elsewhere. Debating endlessly on a feature request is not only a waste of time, but can also compromises the clarity of the issue itself. You either agree or don't with the premises and can give arguments to justify your opinion or clarify it a couple times when necessary, end of story. Yakumo: it wouldn't happen against your wishes any more than getting hurled about by landowner push happens against your wishes, because the fact that it's limited would make it useless to griefers.
Gordon: we've already discussed the infinite teleport thing to death. If you can't remember the previous discussion even though it's archived right above us, that's not my problem. Bryan: The only reason I ever add a comment is in response to someone bringing up another irrelevant objection. I've updated the description to suggest that people actually read the thread here, not that they will. Argent, all our previous ones have been about malicious tping by non landowners which has been taken care of by the idea of requiring permissions (as you have added to the proposal up top) however landowner's rights to repeatedly teleported have not been dealt with much at all other than to essentially say give them the go-ahead to have unlimited usage. For the reasons I stated above (infinite loop tp's between two parcels owned by a single av on one or several sims) I see this as open to abuse. I would say that the threat of losing their land is a good deterrent to this however since writing down all the parcel locations where this is happening during being teleported over and over again (I'm guessing they'd quit before seeing copying off the chat messages from the tp's) and then ARing the landowner after restarting is a large barrier to AR anyone who does this.
@Argent: llPushObject would not, and never would have, send me straight across the entire grind. Maybe a few sims in Havok1 if someone abused it, but never from one end of the grind with a 1-cubic-meter-accuracy to the other end. Besides, an non-physical vehicle can stop0 pushes, but nothing stops teleports.
Gordon, I didn't "add any bit about permissions". That was already there (didn't you see it?)... and it's the wrong solution, because it forces a dialog before a teleport can happen, and as a result doesn't provide any functionality that llMapDestination does not provide.
The "multiple teleports" is taken care of by putting in a period (at least 10s, possibly as long as 30s) after any teleport has been completed in which ANY teleport request other than one made by the user himself is ignored. That has also been discussed in this thread. there's no use case I can think of that would be broken by not being able to multiply teleport the same avatar more than 3-6 times a minute, and that would completely and uniquivocally break any multiple teleport based traps. Yakumo wants multiple dialogs to be handled by some kind of complex scripting where you have one master teleport object that can somehow retain permissions on multiple avatars (possibly using a couple of dozen active scripts, like dance balls). I don't see that as a solution: i've worked on dance balls, and fixed a couple that used the multiple script solution that were amazingly laggy on sims. Ok, thought about it again, and I need to admit that I now, partially, agree with Argent. As long as an TP just teleports you within a sim and the function itself gets a throttle to not be used to fast, landowners can barely abuse it.
But I still think that if the TP goes into another sim, it should ask for permission first, mostly because I don't see much point to it and don't even want to hear the complaints of "innocent" PG-users who get suddenly teleported mature areas. Additionally, objects that aren't owned by the landowner or the teleported agent should be able to use it as well, but allways triggering an permission request, basically similar as giving an object, with accept, deny and mute, to be able to offer friends TPs to a distict place without the hassle with landmarks and the map. Okay just to pull everything together
1 multihop transports should have a hard limit of say 10 ports then a cool down of 5 minutes 1. That limit is too strict and too lenient.
10 teleports can lock you up for minutes. There's no reason to allow more than one sequential teleport, or any multihop transports. But there's no reason for the cooldown period to be longer than 30 seconds, and even 10 seconds is long enough to hit "cancel". If you do hit cancel on a teleport, then that should probably block scripted teleports for a longer period. [Edit] The way teleport is implemented, the client would be responsible for the delay, so there wouldn't be any issues with multiple objects on separate parcels or sims triggering teleports to bypass the limit, and since the client knows when the teleport's complete it could start the cooloff period when the teleport completes... so there's no chance of client-side lag extending the teleport attempt past the cooldown period. [Edit] I don't understand your item #3. 2.1. is redundant: objects attached to you are always owned by you. 4. Teleports are already logged in chat. Including the owner of the scripted object would be the best way to log that. 5. How would it tell if an avatar is "PG/Child"? Better would be simply to require approval for teleporting to an M sim from a PG sim. Good summation Argent. 10 seconds I think is plenty on the delay (per agent not per object to prevent multi object teleport spamming). On the PG to Mature idea I think that there should be a settings options, ask before teleporting between PG/Mature regions(always,ask,never) always and never are of course obvious, always would always allow without a dialog, never would never allow and wouldn't dialog, ask would ask each time a request came in and would not implement that request (with a reasonable timeout of course after which it would drop the request) until you press yes or no and would need a mute button as well to ignore further teleport requests from that object.
I think we're missing a pretty simple feature that might help everyone come to an agreement. What about an option in preferences that is "Allow land owners to teleport me without permission"? Turn it off by default so as not to confuse the noobs. If on, teleporting would be seamless in that instance. If off, each script asks once (unless reset) like the current animation permissions.
If you want seamless teleports, such as for a stargate, you only need to flip one switch, then bam you have it. Make a shiney picture that pictorially describes how to change this option, and what it means, and distribute it with your stargate/whatever systems so that n00bs (and oldbies that don't understand the new feature) are clear on it. This combined with what has been suggested above would end in a system that is both permissive, but keeps people safe ( and yet isn't overly complex). Done! Having that as an option that you can turn on would make it more likely that people would abuse it, because they would assume that if you turned it on you didn't care what happened.
When I used to work in a sandbox I got orbited a couple of times because they thought what I was working on looked like a shield, "Oh, sorry dude, I figured you had a shield up and didn't care". If the feature is designed so that it's easy to report abuse and there's no "innocent infringement", it will pretty much eliminate abuse, so there's no need for an option. If there's a ready excuse for abuse, then guess what happens? Why not nip the problem in the bud? Had some discussion with some people on an alternative system to, which is at least "related". The existing "join me in" functionality isn't too bad, its having to click on something that is the pain. But, the principle of the alternate system solves two problems. Basically, the idea is to have an object "in" the region you are TPing to, which can send you a TP offer, just like a person would. Basically, the script would do something like:
llOfferTeleport(x,y,z); And then you could say yes or no to it (some arrangement might be made for permissions to auto-TP if you "trust" the device, but you could also ignore it, like you do people). Now... Why is this a superior solution? Well, because it also gets around the problems that a) the local device can just keep TPing you. It can't, since all its doing is asking the destination object to send you an offer, which makes looping a tad more difficult. Second, it means gates would still work, even if someone makes a teleport hub in the region (in principle one could limit it to the "owner" of a parcel, or the region, but they could also allow someone to be given limited "permissions", in some fashion). This means anyone unable to "talk to" the device would still end up at the teleport hub, but someone with specific attachments, or something like the gates, etc., would be able to talk to the device in a region, which had TP permissions, and thus offer a teleport to the person wearing/touching/colliding with it. Now, a lot of argument was made about how this wasn't necessary, but.. As SL grows, more people are likely to make areas where there are clear TP points that should be "allowed", but also clear restrictions on new people in the areas. For example, something like a full "Atlantis" replica would cover multiple sims, but, the normal teleports simply won't work. If you want things to work as intended, you might disallow TPs into any region other than the one with the gate room. I.e., someone can't just teleport into some random part of the build. Yet, you also would want to be able to transport between parts of the build while "in" the build, which have one or more sims "in between" them. You can't do that with the existing system, not even with llTeleportAgent, if it was supported. But.. If you could have the wall panel in one teleport chamber ask the other TP chamber to send a "llOfferTeleport" to the person who wants to go there, and it could, in a controlled way, bypass the hud and teleport restrictions... that would indeed be useful, but it doesn't overlap the functionality of llTeleportAgent completly (if you make a jira entry about that, please send me the link, cause I wanna vote for that too
I agree with Tigro. Teleport offers are not real time, they can't provide the effect of walking through a portal. I think it's an excellent proposal but needs to be its own entry. It would also separate the functionality that some people have been asking for... to bypass landing points... and avoid cluttering this proposal up with feature creep.
If you don't want to open a Jira, Kagehi, I'll be happy to do it for you. Edit: actually I think you're talking about SVC-1733. You might want to see about changing the entry title to "llOfferTeleport', that's a better name for the proposed functionality. Hmm. Interesting. Wasn't aware that someone else had proposed such a system. Had a chat in the SL forums about it, in which the idea got reworked quite a bit. But, yeah, the basic system wouldn't allow instant TPs, but... not sure LL would ever implement one that does, which is why I thought something better than the bloody "click 2-3 times" one would still tend to be better. lol The prior discussion I had proposed that you could use an attachment, which would apply some sort of auto-permission, which for SG fans wouldn't be a huge deal, since they usually have GDOs, etc. on them. The attachment would have a, "Can I accept teleport requests?", type permission. The biggest issue being... how do you do that, and only let it accept permissions from items that you "want" to allow, not just everyone? Its not like all gates have a single component with the same ID, since copies have different IDs, or owner, or even, necessarily, creator. Its damn hard to make something that allows you to auto-TP, keeps permissions for that for a long period, and won't suffer from people screwing with the system.
So... A "one click away" solution may be as close as its ever going to get to what we would like to see, was my thinking. Going to have to check out the other Jira though. On a thought.. The permission system could track sims that are "allowed" to TP you individually, which would work well for things like the gates. The problem is still cases where you are being bounced around in the same sim though, in which case, I tend to agree with the concept proposed of a limit to how many you can get in a set time, and a way to click a "ignore requests from this object" option, some place in the chain of teleports, if some moron tried to grief. OK. TigroSpottystripes, here you go:
https://jira.secondlife.com/browse/SVC-3546 Under certain conditions it "does" replicate llTeleportAgent, and I think the conditions required for that are fair ones, as are the other restrictions, when those criteria are not met, including the key one, which is that while something could act like a central control computer for teleporters (different application than gates obviously), it would be restricted to only allow locations provided as a "list" to the function, and then only on land owned by the same agent/group as the object. This doesn't prevent teleporting to other places, like the gates, but it does mean that the destination gate/device has to "originate" the offer. I.e., you can't set up your own device to permit teleports, or bypass a hub, to land you don't yourself own, or which is in a group you don't belong to (and therefor have no permission to set arbitrary locations in). Also, as per the rules described, an object that is not in the lands group or owned by the sim/parcel owner, cannot TP you to any point outside 10 meters of its own location. This means gates continue to work right, but not devices that would let you drop one in, then teleport to any place in the sim. You just teleport to the object, like a marker (but bypassing the hub, if one exists). And since most places are likely to have auto-return set, or rezzing disabled.... this is quite limited. thanx
btw, do you guys know why the entry for my suggestions regarding this function ( VWR-9200 ) barely got any comments and zero watchers? negative comments I can deal with, but being ignored? that is kinda disappointing (or somthing like that, I can't remember the right word right now) Please LL Fix This Issue. There is many Ways this could be Implamented Easily And Safely To prevent Griefing. My Favourate Is For Useders To Wear A Prim On there Body With The Script To Allow Them To Do THis Instant Tp Effect Without Having To Click The Teleport Or Any Kind Of Map Or Drop Down Box. Aslong As The User Has Given Consent To Wear This Object It Should Be Allowed. Mebey Even a drop down menu that says wearing this item means you can be teleported at will. Perhaps even a drop down menu like when you put a vendor online saying that this can take money from your Account.
what you're describing is a dialog, drop down menus are a different graphic user interface element
having it only work on attachments would be quite the limit, like forcing people to get a hud or whatever to be able to use things like stargates and other teleporters, and unless people agree on some standard lsl protocol people would need a different hud for each different system, and it would also be wasting resources, using more than one script for somthing that otherwise would only need one I don't see why my suggestions in VWR-9200 wouldn't deal with all the concerns about griefing and usability already mentioned here (and people haven't said much about what I said there :/ I see Linden Lab are still ignoring this request. Makes you wonder why us residents even bother posting to the JIRA
Wolfie I realized today to get what I needed done would take way to much work and this would solve alot of headaches. hoping still that somebody will look at this and try to help us
For what it's worth, I believe the process and restrictions detailed here are both reasonable and safe. It must have the same exact restrictions as llMapDestination, simply a different UI interface. I believe other jira had a point in that llOfferTeleport might be a better name for it, since it gives the correct idea that the offer might be declined. But other than that, spot on. I hope this gets implemented, but seeing how long it's been around I guess there's little hope.
I'm wondering if Linden Lab actually read these requests.
lol good question do they read this stuff or do they put this here to keep there inbo quiet?
I have to say I'm disappointed the Emerald viewer got this working before Linden Labs. I just walk through the event horizon, it's awesome.
UI is important, it's the stuff we use all the time, this little tweak makes the gate networks much more enjoyable. I think it would be fantastic you could go through a stargate like that or even fly a puddle jumper to it would be awsome to explore SL just like SG-1!!! i say go for it and through it!!!
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
New Feature Request - llTeleportAgent
