I can understand making the maximum distance greater than the max link distance, it has excellent potential for use as a teleporter, but there's no reason it couldn't be capped at a reasonable (or even unreasonable) distance. I found this ticket while searching through tickets that involved this function because I was thinking of writing up a request to cap the max distance allowed using this function.

By my calculations, given that the max height for doing just about anything in a sim is 4096m, and a sim is 256m x 256m (362m diagonal), thje max distance you would possibly need to use in this function to move an avatar within a sim would be 4,112m. We could even add in a bit of breathing room and make it 5,000m, or even double that and make it 10,000m and I'd be willing to bet that it wouldn't adversely affect legitimate content. Given that an avatar moved to the heights in your script will become invisible on the client's screen, and possibly crash the client in some cases or break scripted content that contains movelocks or other calls to llGetPos(), there is no good reason why this function ought to be able to move an avatar to that height. Since being moved too high causes problems for the client (and possibly the server), it's obviously best to just prevent the function from being able to do that. Shouldn't be too difficult.

You're also right about capping the range, its not a lot of fun to get thrown this high up because some giggle-head thinks it funny to rez invisible covers over the top of chairs and seats in legitimate builds.

I posted the code because this kind of thing shouldn't be a secret. The more people who know about it the better IMO. And also when the code is publicly available it makes it harder for the "ultimate anti-greifer weapons makers" (an oxymoron if there ever was one) to exploit what is a bug for profit. I read a comment awhile back from a Linden (don't remember exactly who); anyways to paraphrase him "Programmers don't write code based on bugs and undocumented exploits, they fix them." I agree.

As for the range, personally I think it should be 4096 max. in one call. Thats the build range now so I can see how I may want to be teleported in one jump that far, especially in a busy region. Beyond that distance we are as you say only talking about skydiving, a legitimate activity, but given that a ceiling of say 20,000m can be reached in 5 jumps of 4096m in a blink, then this amount of time is hardly an imposition. Even 100,000m only takes a slow wink, although without a downward push, it takes ages to fall back to the ground

But, DEBUG_CHANNEL div 4096 is a very long time, and I will be TP'd away well before my poor wee avatar gets anywhere near debug_channel heaven

And umm! ya, my avatar gets absolutely munted way up there just like it did in Havok 1. Hope this gets fixed soon. Its new residents who get nailed by these kinds of bug exploits. And thats not good for anyone.

As for moving it in multiple jumps, that actually won't work, I don't think, because the function is read as an offset, as with most of the other llSetLinkPrimitiveParams types. The vector supplied is the vector distance from the root prim, so each call is putting you in a specific position, they're not additive. What could be done for skydiving that would be kinda cool would be to fire a rocket or skydiving pod up to 4000m or so, at the max height it can go for a physical object, and then have it use llSetLinkPrimitiveParams() on the sitting avatar or avatars to bump them up another 4096m. That way skydiving products could still get pretty damned good air even it if were capped.

I do know of at least one commercial product that uses this already, and I presume others will eventually do so as well if it is not fixed. Currently the one I know of places an invisible prim behid the avatar such that it covers most of their client's screen when the camera is in its default position. The object is set to have the person sit on it when clicked, so when the person unknowingly clicks on it, boom!

At least RC 1.20 has a stopgap preventative measure: If you're already sitting on an object, you won't automatically sit on another one by left-clicking on it (right-clicking and selecting "sit" from the pie menu will still work, of course).

Second Life Server 1.22.3.89352
Second Life 1.20.10 (89467) Jun 10 2008 18:17:42 (Second Life Release Candidate)

state_entry
...
llSitTarget(<0.,0.,0.001>,ZERO_ROTATION);
...

changed
...
llSetLinkPrimitiveParams(
llGetNumberOfPrims(),
[PRIM_POSITION, llGetPos() + <0.,0.,4095.998>,
PRIM_POSITION, llGetPos() + <0.,0.,4095.999>]);

With a box at 4095m, this double-jump gets me to 12,284 and a bit metres consistently. More than a double-jump, or double-jump values greater than 4095.999, puts me anywhere or nowhere.

This is consistent with what other people have reported (Linden Weapons Testing Sandbox notably) where it is possible to perform a double-boost llSitTarget to approx. 4300m from ground-level. The double-boost being the common factor as I understand things.

As Jahar has noted above, a double-jump shouldn't work, but it does and if it is allowed to remain then it should be documented as allowable, so that content creators who may wish to use this function to make skydiving boosters can do so with some certainty. 12,284m is a lot of fun, specially when you change your animation and swandive head-first into the ground =p =). But debug_channel ??? personally I don't think so.

On reflection, 4096m is not the ideal height for the lateral sim movement reason given by Jahar, and picking up also on the 4300m reported by others, I now see how a height greater than 4096m is useful in building a cage/follower escaper. I made me a really good one, using the script given above as the base =)

An offensive cage/follower can only make 4096m. With flight-assist to hold me up I can make an instant jump to a touch above that height. And, when that cage-creator is dumb enough, the cage/follower hunts me and "very cleverly" stops at 4095.xxx and waits for me to move. When it does then I always hope that it has a smiley texture so that it looks nice when I open up my Inspect window and take it's photo in a non-combat region =p

What's the ideal height? Ideally, it's whatever height can be reproduced consistently without it munting my client allowing me, and everyone else, to TP away or return to the ground without any problems. Whats that height? I've no idea, hopefully someone will work it out one day.

Second Life Server 1.23.4.93100

4096m.

kool =)

Closed.

The "Quantum Teleporter" has been using this methed for teleporting around a region without the need to use wapppos to move the prim, which is a higherly desirable teleport method. (see my product description for why)

I did extensive testing on the beta grid and the method continued to work correctly, however on the main grid after todays rolling restart it seems the teleporters are behaving erraticly. It seems that teleporting in one direction will work, but teleporting back will not.

I am still testing to work out the exact cause of the failure, however it will no doubt be related to a failed implementation of this fix.

Darling.

EDIT : The behavious that was failing 20 minutes ago is now working. even though nothing was changed. Testing continues.....

EDIT: It appears that the agent will not move if the prim has been moved.

Other quirks I found: the 4096 isn't constrained to the sim edges, it follows the Z axis of the prim, so you can rotate the prim to bypass the 256 thing. More strangely, which end of the prim gets the full 4096 seems to depend on its position in the sim and perhaps the prim's orientation, it will be a positive or negative (but not both) offset that will get the full travel. Even with all that taken into account, it still doesn't seem to work consistently,

Once again i point out this problem was NOT present on the beta grid or the main grid before the rolling restart. I have spent a month developing the next generation of SL teleporters and carefully checked that I am working with officially supporte behaviour, and then WHAM they break it. bastards! it is so much easier to make weapons that do bad things than make a good object behave correctly! /me tosses hands in their air in discust, gives up on the teleporter, and rezes a weapon to work on instead.

Also the test location I setup seems to work and fail intemitantly on short 10m teleports for no apparent reason.

@Viktoria Dovgal

Yes I have noticed inconsistant behaviour on the positive vs negative movment. I think they should just give 4096 movment in all 3 directions as people may rotate the prim when building their vehicle/teleporter. trying to predict where the avatar is going to end up in the sim on an object can can change location, rotate, and mvoe the avatar is going to cause problems.

@ Linden Labs, We have had orbiting in second life for a very VERY long time now. It is more important to have teleporters and vehicles working than to rush through an orbit fix that dosnt work properly. Being orbited is not the end of the world, but a failed teleport can be.

I agree that the function seemed to work well in the first part of the rollout (before the Tues/Weds rolling restart), but I only tested it using a cube at zero rotation.

Even though this function is still buggy, these are needed fixes to make this function operate in consistent manner. It's not just about stopping orbiting (although I'll point out that perhaps LL wouldn't be constantly having to fix orbiting bugs if people didn't keep trying to find creative ways to ruin others' SL experiences), but about the fact that an unbounded range for this function is just a bad idea in general. No other LSL functions are expecting an avatar's position to change by that magnitude in that brief amount of time. There's no particular reason for an avatar to be moved outside of the simulator, either. In fact, if one were creating a teleporter, for instance, and found that it accidentally took you so high that your avatar became unusable until you relogged, or just to a height where you couldn't rez anything or do anything, or that it accidentally landed you outside the sim boundaries or into the intersim void, you'd figure that you'd made a mistake. By limiting the range for this function, we not only prevent it from being used to grief, but also prevent it from creating errors or buggy behavior.

The function is broken now. Moving prio to Major.

My Teleporter is a single prim, tube, rotated on the X by 90, so that it has the external appearance of a cylinder.

I find that it is currently able to teleprot long distance, if and only if, it has not been moved after the avatar has sat on it. (with intermitant failures since the restart)

Teleporting over a region border is a desirable ability. Myself and others have spent considerable time working out how to teleport over region borders safly. This method apears to have some advantages over wapppos in my experiments. I would not support a blanket ban on crossing borders, nore would anyone else wanting to setup teleporters on a multi region estate. If a teleporter is not scripted to cross the region border the creater will implement their own range checking on the destination. Forcing range checking onto those of us who can script one to safly cross a border to protect from those people who cant is just silly.

The Sit Target for an object does not have different limits on the x,y,z, and is not effected by prim rotation. I think something similar should be done with this function. A value of 4096 for x,y,z seems sensible, just like the 300 was sensible in the early days when people seldome teleported above the clowds.

I have also notice another related bug. The manipulation of the avatar's sit position is reduced to normal prim link distance when the object being sat on is more than a single prim object. ie. a two prim object failed to move the avatar more than 8 meters. This bug has spoiled my multi-prim teleporters. I also noticed that the avatar did not move at all if the destination was over 8 meters. It silently fails, leaving the avatar in the original position.

@Lindens
I will send you a copy of my teleporter to inspect on request. I think you will find it demonstrates the value of fixing this properly.

Darling Brody

I do declare, obessions with "griefing" create the most amazing tunnel vision about use cases...

1) Avatar munting that requires a relog to correct. That should never happen at any height or distance no matter how far. Ideally thats what should be fixed by LL. The munting.
2) Inconsistent results being returned by scripts written according to the specs (as sparse as they are at times). Thats really annoying and wastes peoples' time. If the first is to be fixed by a vertical cap of 4096m then OK, but any scripts written by us predicated on this must reproduce the same result always. If not then its not fixed.

And if we're going to put in a ceiling, it makes sense to put it at 4096 just as with most other things. This would make the behavior consistent with other behavior. Unfortunately, the problem with inconsistent results is likely due to the fact that it's an attempt to put a global limit on a function that works using local (relative) positioning. In theory it should be fixable, but my guess is that as with most other fixes, it's going to have to wait until 1.25.

With LL having such a (well-founded!) concern about retention, try to bear in mind that this kind of thoughtlessly introduced instability is one huge factor in driving skilled content creators to leave the grid permanently out of frustration.

On the one hand, there is a certain amount of logic to this, since the behavior is now consistent with other calls to llSetLinkPrimitiveParams(). On the other hand, this was a very useful function and it is possible that a large amount of content may be broken by this change.

llSitTarget() will still move an avatar to the 300m limit that it always has, so at least that will work for most sit-teleporters.

Oh, and @ Maggie:

I understand that you are upset about this (although I'm not sure why, do you make teleporters?), but I think that your anger would be better directed towards those who abused an exploit of this function for financial gain rather than at those who are working very hard to find a way to make this function work in a non-abusive fashion without breaking content. I don't think that comments like that are of much help in solving the problem.

Remember that the root problem is that this function did not have any range limits. This left it open to abuse. LL placed its new limits badly, but they can and likely will change them IF individuals use the JIRA in a constructive manner to try to fix the problem.

I wore a script that contained a simple llSetForce to push me straight up as fast as I could go. My avatar was fine until at a little over 472,000m my avatar munted (upper body) and my viewer started flickering intermittently. (I took a photo and put in it my 1stLife profile page /me grins) Anyways I carried on going up to see if my viewer would crash. At 1,000,000m my avatar was still munted, my screen was still flickering but it hadnt deteriorated any further. So I stopped. It had taken over an hour to get there so =)

I could still fly around up there in my munted state and my IM was working, as was my Search. And my avatar unmunted when I TPed back down which I was able to do easily. So that was good. I was also able to create an LM for the record. Hotei (25,131,1000000). Pity I cant TP back there as teleport tops out at 4095.

Anyways, it seems to me that one or more variables that help to position an avatars body parts is where the munting problem lies. Unbounded relative arithmetic again I think.

This is not necessarily the same problem that Darling B. raises even though the unintended outcomes are sometimes indistinguishable. Yes its incumbent on lsl scripters (and any others) to range/bounds check their own code. However, when that code is written correctly then the expectation is that the lsl intepreter will execute that code as its written. I.e. I wrote a script to fly straight up. I didn't write a script to munt my avatar. If I had wanted to do that then I would have scripted it myself.

I find unnecessary tinkering with platform it depends on frustrating and annoying.

refer to: http://en.wikipedia.org/wiki/Primum_non_nocere

Seems that you can move inter-sim on the X and Y in both + and - directions, both in Edit Mode and script.

The way it works is to do it in 2 hops. (server 1.24.4.95600)

while not at target
hop to the sim edge // 0 | 255
if sim edge = 0 then position-- else position++ // link distance hop
tiny sleep to allow server and client to re-synch in new sim

I haven't done zillions of tests but it appears to be consistent so thats good. Also appears that you can go as far as you want across the grid provided the region/parcel settings allow you, same as any other vehicle.