Move/teleport object triggered from another object

[Chase3XxL]

Hi, i was looking into llSetPos or llSetRegionPos to move an object between 2 fixed positions.
But i would like the move to be triggered from another object like a switch.
So somehow i have to enter the object id into the script. My goal is to have one object move between 2 locations within the same  Sim by a toggle switch.
By touching the switch the target object should jump back n forth, no animation needed.
Is that feasable? 

[Rolig Loon]

Yes.  There are many ways to do it. All you need to know is where to go. You don't actually need to know what's at either of your two target locations ...just where they are.  Possibly the easiest solution is to put a script at both locations that does four things:

1. Says "Hi! Where are you?" in llRegionSay on a secure channel when someone touches it.

2. Listens for that message, grads the UUID of its sender, and says "Here I am!" in llRegionSayTo the UUID.

3. Grabs the UUID of the incoming "Here I am!" message, uses vector Pos = llList2Vector(llGetObjectDetails(UUID, [OBJECT_POS]), 0); to find out where it came from, and

4. Teleports the person who touched it to Pos.

You can put that script into as many objects in the region as you like. Each of them will become a teleport sender/receiver. Best of all, you can move them around randomly as frequently as you want and they will always work.  You can customize that basic idea to add  all the bells and whistles you need for your specific application. 

Edited November 24, 2022 by Rolig Loon
typos. as always.

[Qie Niangao]

You can add a script to the target object, right? If so, it makes the llSetRegionPos call in response to communications from the switch. ("Jump back and forth" suggests the motion should be instantaneous; otherwise llSetKeyramedMotion can look smoother.)

While I was typing this response, Rolig outlined a very useful way to set up such communications. There are other, less general variants on communications depending on such factors as distance between the switch and the target object, whether they'll always be in the same region or not, what they should know about each other to make sure they're dealing with a reliable communicator, etc. That part includes whether one or both need to know the other's ID—not necessarily in the special case were there will always be only one of these pairs in the region.

If you can't add a script to the target object, I think it's most likely impossible, except under very special (physical object) conditions.

[KT Kingsley]

The switch object needs only a very simple script that reacts to the touch_start event by by chatting a message to the moving object. Ideally this would be done using llRegionSayTo with the UUID of the moving object, and on whatever channel you choose (usually a large negative number).

The moving object script sets up a listener using llListen set to that channel. When the listen event is triggered the moving object can compare its current position with either of the two jump locations and then move to the one it isn't at.

You can get the moving object's UUID by putting a line, llOwnerSay ((string) llGetKey ()); into its script and copying the resulting chat into the switch script.

This is fine if the moving object gets rezzed and stays rezzed. If, however, it's something that comes and goes it may be necessary to add some more script lines to both scripts to enable the necessary mutual recognition.

[Rolig Loon]

Well, you could do it if only the sending object was scripted, as long as the person or object that is moving back and forth is also scripted, and as long as the target object is within sensor range.

1.  Knowing the unique name of something at the receiving end, use a sensor to get the UUID and position of the target object.

2. Store that information and in a script in the object/person you want to teleport  and

3. Teleport.

Rinse and repeat as many times as you like, bouncing back and forth between the two locations.

EDIT:   Which is a version of what KT wrote while I was typing.  

Edited November 24, 2022 by Rolig Loon

[Quistess Alpha]

Just for fun, assuming the object to be transported is no-mod (but allowed to copy), if the teleporter has land permisisons, it can llReturnObjectsByID() the object, then llSetRegionPos (region pos has fewer limitations than llSLPPF or setPos) itself within rez range of the target location and then llRezAtRoot the object at that target, then llSetRegionPos itself back to its home location.

Edited November 24, 2022 by Quistess Alpha

[Chase3XxL]

Thank you all for your amazing input.
Its clear to me now that you cannot influence one object from another object without a comms channel.
I guess ill have to try something like this eventually.

My idea so far is to make the listening side as dumb as possible and try to pass any data needed from the sending object (the switch).
But it will be at least a couple of weeks before I can start on this.

thnx again to all of you 
 

[Quistess Alpha]

14 hours ago, Chase3XxL said:

make the listening side as dumb as possible and try to pass any data needed from the sending object (the switch)

There are pros/cons to either/any approach, but in general, I usually make the receiving object the "smarter" one.

If the switch just says "flip" and the object goes to the other position, there's less risk of the switch&object going "out of sync" (especially if the object goes to a specific position on script reset) as compared to a switch that says "go to A" or "go to B" without checking which spot the object is currently in.