Teleport on touch scripts

[LissomePrey]

I've been playing about trying to understand how teleport on touch works.

The approach seems to be that touching temporarily sits you on an object that rezzes a copy of itself and then moves the avi to the required location before it dies, leaving the new copy for the next person to touch.

I've done a stripped down test (code below).

1) I rez the object (TP Box) which contains the script and a copy of itself.

2) I touch it and get transported

3) I come back, check that the new object appears to be a true copy, which it seems to be.

4) I touch it and get tranported

5) I come back, check the new object and it has the script but not a copy of itself.

I can't see why that happens, any suggestions would be appreciated.

default
{
    
    //set up new copy of the object
    on_rez(integer start_param)
    {
        llOwnerSay("rezzed");
        llSetClickAction(CLICK_ACTION_SIT);
        llSitTarget(<0.0, 0.0, 1.0>, ZERO_ROTATION);
    }

    //detect someone sitting so create a new copy ready
    changed(integer change)
    {
        if (change & CHANGED_LINK)
        {
            llRezObject("TP Box", llGetPos(), ZERO_VECTOR, llGetRot(), 1);
            llSleep(1.0);
        }
    }

    //new copy is ready so move with avatar and then die
    object_rez(key id)
    {
        llOwnerSay("object rezzed");
        key avi = llAvatarOnSitTarget();
        llSetRegionPos(<210.0, 240.0, 2400.5>);
        llUnSit(avi);
        llDie();
    }

}

[LissomePrey]

I've got a stage  further.

The TP Box has full permissions for next owner as does the copy inside it. After the first use whilst it appears the new TP Box is the same , the copy inside it has lost Copy permissions for next owner. Not sure if there is a way around that.

[Wulfie Reanimator]

14 hours ago, LissomePrey said:

1) I rez the object (TP Box) which contains the script and a copy of itself.

2) I touch it and get transported

3) I come back, check that the new object appears to be a true copy, which it seems to be.

4) I touch it and get tranported

5) I come back, check the new object and it has the script but not a copy of itself.

Objects can't exactly contain copies of themselves. When you make a teleport object, take a copy, and put that copy in the object... the copy you've just put in is a version of the object without a copy of itself. You're basically creating a Russian Nesting Doll and eventually you'll reach the last copy without a copy of itself.

These sit-teleporters wait for an avatar to sit on them, then move to a destination with llSetRegionPos, then force the avatar off with llUnsit, and then return to the origin with llSetRegionPos again. Or they can move the avatar itself as if it was a link (but that's limited to +/-1000 meters). Only one object is needed for all of this.

Edited February 9 by Wulfie Reanimator

[LissomePrey]

Thanks

[PheebyKatz]

I don't even bother with all of that. They sit, it moves instantly to the destination, it unsits them. That's all you need.

The object itself can do it, and it goes so fast most people never even see it go, if they're watching someone else "teleport".

You can even have it turn to face the right direction before unseating them, so they face the right way. Just be sure to turn it back when it goes back.

If it's a big object you're using as the visible portal, or part of a large linkset, you can just put an invisiprim right in front of the spot they should click, and use that invisible object as the "mover" instead.

I've made several different versions of this kind of "fake tp" device, even one that has a notecard whitelist of permitted users. They're my go-to for quick local transport options. If you'd like copies, hit me up inworld sometime and I'll send them to you, so you can dissect them and stuff.

Edited February 9 by PheebyKatz

[LissomePrey]

11 hours ago, PheebyKatz said:

I don't even bother with all of that. They sit, it moves instantly to the destination, it unsits them. That's all you need.

The object itself can do it, and it goes so fast most people never even see it go, if they're watching someone else "teleport".

You can even have it turn to face the right direction before unseating them, so they face the right way. Just be sure to turn it back when it goes back.

If it's a big object you're using as the visible portal, or part of a large linkset, you can just put an invisiprim right in front of the spot they should click, and use that invisible object as the "mover" instead.

I've made several different versions of this kind of "fake tp" device, even one that has a notecard whitelist of permitted users. They're my go-to for quick local transport options. If you'd like copies, hit me up inworld sometime and I'll send them to you, so you can dissect them and stuff.

I just got interested as a friend said they had bought a script and I wondered how difficult they were and then read the wrong sample script off the internet!

There is something odd about an object rezzing a copy of itself that is not a true copy but thinking about it, it is probably a good thing to stop griefing as objects that could rez multiple copies of themselves forever would be a gift to griefers, so good that it doesn't work.

[Quistess Alpha]

5 hours ago, LissomePrey said:

There is something odd about an object rezzing a copy of itself that is not a true copy but thinking about it, it is probably a good thing to stop griefing as objects that could rez multiple copies of themselves forever would be a gift to griefers, so good that it doesn't work.

I'm not old enough to remember "grey goo", but it's certainly possible if you're clever enough. Check out llRemoteLoadScriptPin(). it's a bit of a pain, but it mostly solves the matryoshka doll problem.

[LissomePrey]

Going almost way off topic, apologies, thinking about this reminded me of John Conway's Game Of Life Wikipedia Article which probably almost everyone who studied or even worked in IT in the 70s or 80s coded a version of.

 

I have no doubt that there are SL versions of it somewhere but thinking about automata, if an object could rez exact copies of itself, you could have an entirely autonomous version with no central control. As is, I think you could only go semi-autonomous with a central object that you requested to create new objects, though that object wouldn't need to know where any existing cells were.

 

And no, it isn't on my list  ... yet.

[PheebyKatz]

10 hours ago, Quistess Alpha said:

I'm not old enough to remember "grey goo", but it's certainly possible if you're clever enough. Check out llRemoteLoadScriptPin(). it's a bit of a pain, but it mostly solves the matryoshka doll problem.

Every time I script a monster rezzer from scratch, I get the Grey Goo Error until I fix it to only rezz 3 per session. It literally says "Grey Goo Error". My first impulse is always to run away, it's such a shocking thing when it happens.

It's horrifying, and hilarious at the same time. XD

Edited February 10 by PheebyKatz

[Bleuhazenfurfle]

I have a thing that rezzes a wall full of panels, and because I'm constantly tinkering with the script, it llRemoteLoadScript's them.  But because that's so slow, once ready, they take it in turns to help load more.  So it quickly rezzes a wall full of blank glowing panels, then the rezzer starts loading the script into the first one.  Once loaded, the script cancels the glow, and puts up the texture it's supposed to be showing.  The rezzer then starts loading the second panel, but now also the first panel starts loading the third.  Now you have three, loading up the next three.  And then six loading the next six.  I'll sometimes just sit there turning it on and off a few times, because it's kind of fun watching it work.