No-Frills Teleporters

Can anyone recommend a place to buy a no-frills long-range teleporter -- or better yet, just a teleport script that I can drop into my own prims? Something that's _just_ a teleporter, without any extraneous ruffles? There are five billion teleporters on SLX, but they all seem to be jampacked with bells, whistles, gizmos, and gimmicks that I neither need nor want.

I need something copy/no transfer, single-destination, that works at least up to 768 m (preferably 4096) but doesn't need to go outside the sim borders, probably configured by notecard if I can't get into the script to set it manually, and that works (or that I can configure it to work) on a single sit-click. And that doesn't do anything else.

No sound effects. No particle effects. No visible transporter beams. No cutesy un-changeable sit text. No floating text I can't get rid of. No object messages. No access controls. No multiple destinations. No handholding appearance options for people who can't click "Edit". No dialog boxes, no drop-down menus, no linking networks. No anything that isn't directly involved in moving one avatar at a time from the teleport prim to the location I've previously set. Just the teleport. Just. the. teleport. Please, just the teleport? *bangs head repeatedly against the wall*

I feel like I've been to every ice cream store in the county and no one sells vanilla, just mocha java fudge ripple caramel swirl roof sundae. With sprinkles. Which is great, if mocha java fudge ripple caramel swirl roof sundae with sprinkles is what you're in the mood for, but sucks if you need vanilla ice cream to make strawberry shortcake with.

I did post about this to the scripting forum a few months ago but without any success, so I figured redefining and redirecting the question might help. Since I've been banging my head against the wall for so long now, I've almost resigned myself to buying something fancy if I have to, and am looking at the BlinkTP, the Cool Teleporter, and the Easy Teleporter 3.7 (all in the $200-300 range) as probably being the least annoying. If anyone has any experience with these -- especially trying to mod any of these -- I'd love to hear it.

That was good. I felt the same way when looking for one a few months ago.

I've purchased this one from SLX before and it works great. There is a floating text option that you can get rid of, thats about the only frill.
http://www.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=203262

There is a freebie out there that I have used before. Gypsy-Port or something similar.

I won't be on tonight, but if you don't have anything by tomorrow I will either send you what I have or write a simple script for you.

Currently there is no limit on how far llSetLinkPrimitiveParams can move a prim, so something like this can send you all over the sim (up to the 4096 limit).
I suspect, however, that we may at some point see a limit, since this breaks the usual link distance rules, so use at your own risk.

vector target = <128, 128, 100>;

default
{
state_entry()
{
llSitTarget(<0.0, 0.0, 0.001>, ZERO_ROTATION);
}

changed(integer change)
{
if (change & CHANGED_LINK)
{
string sitter;
if ((sitter = llAvatarOnSitTarget()) != NULL_KEY)
{
llSetLinkPrimitiveParams(llGetNumberOfPrims(), [PRIM_POSITION, target - llGetPos()]);
llUnSit(sitter);
}
}
}
}

The 1.23 server that went out this week kind of broke this, but not entirely. The new limits were supposed to be to allow an avatar anywhere in the sim, but currently it's only reliable if you keep the prim at zero rotation, and stick to simpler prim types (boxes, cylinders, that sort). Other configurations may or may not work depending on who knows what. It's also more reliable if you stick to a single prim, but that was true even before 1.23.

More on the current issue in http://jira.secondlife.com/browse/SVC-2543

Thanks for the rec! I dismissed that one originally because it said it was copy-only, no mod perms. But the SLX info can be misleading sometimes. Are the actual prims in that one moddable, or can the script be copied to inventory and moved to your own prims?


Couldn't find anything by that name on SLX, will check in-world when I get there. Thanks for the offer! The conclusion I came to after my original post (in the scripting forum) was that the reason I couldn't find a moddable script was that it was impossible to write a _simple_ teleport script for distances beyond 300 m, hence everyone protecting their work. Which I totally understand, it just makes it incredibly frustrating when the annoying frills and flounces are no-moddable too.

See later post...

Also have a WarpPos module here:

http://wiki.secondlife.com/wiki/User:Talarus_Luan/WarpPosModule

Of course, that's just the movement code; you'd need to add in the rest of the "interface" in another script.

Don't try to modify that one; it is VERY tight on memory for the longest jumps (something like 18 bytes left for the full 410 jumps).

Tali and Viktoria -- Coolness! If I understand what I'm reading, it looks like the same Sit scripting used for old 300-m teleporters now has unlimited range? Or up to 4096 m? I saw some discussion of limits in the JIRA, but it didn't look like anyone was proposing limits tighter than 4096.

I wonder if the bugs mentioned are responsible for the weirdnesses I ran into testing teleporters last night and earlier today -- once a teleporter that used to work threw me onto a neighbor's property instead, once the same teleporter worked but vanished without trace afterwards, and once a new teleporter I was trying not only threw me all the way into another sim but completely ate itself in the process.

/me runs off to test these scripts.

It's not exactly the llSitTarget hack, but yes, it works in a very similar way, letting you do it all in one stationary prim.


Yeah, the new limit is 256 on X and Y, 4096 on Z, so it's good for a sim.


That sounds like an llSetLinkPrimitiveParams teleporter that was bitten by the rotation thing I mentioned above. posted a version to deal with that at /54/03/267096/1.html#post2089974


That one sounds more like a warpPos teleporter trying to get away with one prim by returning the platform. Once the sitter is gone, those tend to get stuck over other people's property if the other parcel is full or doesn't allow object entry. You may find it stuck in the air on a parcel's edge.


That sounds like another broken llSetLinkPrimitiveParams example (can you tell I've stayed up late playing with these lately? )

This one does a warppos jump, and ekes out the last couple of meters if you really need to go diagonally across a sim using the "failsafe" of a couple of normal llSetPos jumps in sequence. (The failsafe was originally included in the warppos to guard against the possibility that a server update might break warpppos, as once happened. It just pulls double duty here with a slight tweak).
You could do something with two warppos in sequence, but I didn't go that distance (pun kinda intended), considering how rare it is you actually need the last couple of meters above a 4km jump.
Be mindful of Viktoria's warnings about this getting stuck if crossing parcels. Also, sometimes the *client* seems to lose track of where the prim is when it does such huge jumps. The server still tracks it correctly, but it'll be invisible to you until you teleport out and back again, to get the refreshed data from the sim. I don't know if that glitch is still in the current versions; I was never able to reproduce it reliably.

vector target = <255, 255, 4095>;
vector base;

warpPos(vector destpos)
{ //R&D by Keknehv Psaltery, 05/25/2006
//with a little pokeing by Strife, and a bit more
//some more munging by Talarus Luan
//Final cleanup by Keknehv Psaltery
// Compute the number of jumps necessary
integer jumps = (integer)(llVecDist(destpos, llGetPos()) / 10.0) + 1;
// Try and avoid stack/heap collisions
if (jumps > 400 )
jumps = 400;
list rules = [ PRIM_POSITION, destpos ]; //The start for the rules list
integer count = 1;
while ( ( count = count << 1 ) < jumps)
rules = (rules=[]) + rules + rules; //should tighten memory use.
llSetPrimitiveParams( (rules=[]) + rules + llList2List( rules, (count - jumps) << 1, count) ); //Changed by Eddy Ofarrel to tighten memory use some more
while ( llVecDist( llGetPos(), destpos ) > .001 && --jumps > -100) //Failsafe
llSetPos( destpos );
}

default
{
state_entry()
{
llSitTarget(<0.0, 0.0, 0.001>, ZERO_ROTATION);
base = llGetPos();
}

changed(integer change)
{
string sitter;
if ((sitter = llAvatarOnSitTarget()) != NULL_KEY)
{
warpPos(target);
llUnSit(sitter);
warpPos(base);
}
}
}

Actually, I think it's more about the minimal no-frills version being so simple (and possibly without any failsafes) and/or based directly on the freely available WarpPos that everybody wants to funk them up. Also, the llSetLinkPrimitiveParams is relatively new, compared to the usual "classical" freebie scripts and was - and apparently still is - somewhat flaky.

That one turned out to be just invisible, not gone; when I tried the visit-another-sim-and-come-back trick, it was right where it should have been. It was good that it happened, in a sense, because that teleporter used to be reliable (if too chatty) and its flakiness now let me know there was more going on than just a screwy new teleporter. Still, a teleporter that can't be relied on to be there when you need it isn't much use to anyone.

The other one actually threw me into the middle of some stranger's private house, so I teleported home before things had even rezzed and didn't realize until a few minutes later that my teleporter was no longer where it ought to be. It still hasn't returned, so maybe it's actually sitting in the middle of their living room still.

WarpPos is a bit complicated for my current scripting skills, but I spent some time testing the first llSetLinkPrimitiveParams one. It doesn't work for me at all in a linked prim, but does when I put it in an unlinked sphere. The first time I used it unlinked, it did that vanishing thing but otherwise worked flawlessly, much more smoothly than any other teleporter I've used. After the first time, it didn't vanish again -- but it did start jerking a bit, working but with a slower, rougher ride, the cam views not keeping up with the av position, that sort of thing. My connection is so flaky, though, it's almost impossible for me to tell what problems are really in-world and which are just my inability to send and receive data reliably. And the successful tests were all up and down in the same parcel; when I tried from a parcel on the other side of the sim, it threw me several meters away from the proper destination. But I'm not at all convinced that that was the script's fault.

Yes, the llSetLinkPrimitiveParams thing wants to be in a single prim, otherwise the normal linking limits will get in the way.

And yes, slow connections or viewers can be trouble with any scripted teleporters. You might see that all the coordinates up in the menu bar are doubled from where they should be, or that they show as relative to where you sat down instead of proper region coordinates. If you were to wear a scripted thing that showed your position, it would report the right coordinates. Ctrl-R will usually take care of this because that tickles the right messages to sync things, it's pretty much the same problem that sometimes causes people to apparently end up "nowhere" (apparently at 0,0,0) when they sit on even ordinary furniture.

Yep. When I tried the WarpPos version, it reliably (and smoothly) moved my avatar both up and down in the same parcel and across the sim from a different parcel. But when moving up and down, the teleport prim did the vanishing trick and sometimes reappeared a few moments later, sometimes not. And when moving across the sim, the prim was "falling out" on parcels in between -- fortunately, they had autoreturn on, so I could find out easily what had happened to it.

If I understand correctly, you're saying the "vanishing trick" is just a viewer-side effect? So that if there were other people nearby, they wouldn't see it vanish? Or would they see it vanish just for a moment, during the actual teleport, and reliably reappear immediately afterwards? And it sounds like something that in normal use, when an av teleports away and stays away for a while (as opposed to rapidly teleporting back and forth as when I'm testing), it might not be a problem at all?

So it looks like the advantage of the llSetLinkPrimitiveParams is that it handles parcel crossings better, and the advantage of WarpPos is that it can be used in fancier (linked) objects. Anything else I should keep in mind?


*jots that down to remember*

I can't thank you guys enough for going over this with me.

That TP script works great Tali! Thanks! I hope they don't fix it.

Others would at the very least see the object blink out of existence for a moment while it delivers the avatar with the warppos jump, and then returns. Whether their client also loses track of the prim seems pretty much as unstable as whether your own client does, and *not* necessarily at the same time.
But as you say, in a typical situation, it may not be much of an issue; people rarely go looking for the teleporter back at the original location after using it, but it may be a problem if somebody watches another avatar teleport, and then waits for the teleporter to return.

Hmm. So... can't get in-world to test it until late tonight, but it sounds like the workaround to this would be to make the actual teleporter a transparent prim next to the prim that looks like the teleporter? My other functions, including the SitText, are in the main prim that people would click on, and if the teleport prim is really there but just not rendering properly, it wouldn't matter since they couldn't see it anyway and aren't expecting to. Is that why so many people use transporter beam prims? How would it be affected by linking -- would only the teleport prim vanish or the entire linked object? I've seen both effects in my recent testing, but don't remember under which circumstances or with which scripts.

I find it entirely entirely unfair that I actually have to go off to work instead of staying home and playing with this instead.

Thank you Tali Rosca for the code. It works great!