Multiple Teleporters

I have this gut feeling this can be done, but I am going batty trying to figure out just how to do it.

I have a system of teleporters that when rezzed or reset go out and find each other and share coordinates. When all this information is generated, a HUD is built for each teleporter so the user can select where he or she wishes to teleport too. This is all done by linked messages and all this works great.

The problem is that the actual teleporters are wall mount. To prevent the user
Because the offsets are applied to the region position (using llGetPos) the offset always have to be adjusted each time the structure is rotated.

Anyways, if anyone could point me in the right direction on how to accomplish this, or tell me it can't be done, I would appreciate it.

Some Snippets:

Setting the offsets:

string tempDesc = llGetObjectDesc();
vector tempOffset = (vector)tempDesc;
vector tempLoc = llGetPos()+tempOffset;

The standard teleport code:

(destination is tempLoc)

target = (destination - llGetPos()) * (ZERO_ROTATION / llGetRot());
llSitTarget(target, ZERO_ROTATION);

Thanks,

Bracken

Hmm for some reason, SL doesn't like something I am posting as I keep getting 404 errors. I accidently hit the submit instead of the preview.

I have this gut feeling this can be done, but I am going batty trying to figure out just how to do it.

I cannot seem to post the second paragraph that I posted in the orginal post without getting a 404 error.

The problem is that the actual teleporters are wall mount, so to prevent the user from ending up in the wall, I have to offet the landing location. I do this through the description field of the prims with the teleporter scripts. Again, this work wells until the structure is rotated.

Because the offsets are applied to the region position (using llGetPos) the offset always have to be adjusted each time the structure is rotated.

I have played with trying to use local position, but to no avail as those are offset from the root prim. The easiest solution is use floor teleporters that would requre no offsets, but I really would like to use the wall teleporters, but for the life of me, I just can't figure out how to get the offsets to follow the rotation of the structure. Granted, setup should be a one shot deal unless folks like to move their homes a lot, but even the orginal set up of the offsets is very confusing to folks that do not understand the coordinate system. For them it just becomes a frustrating trial and error.

Anyways, if anyone could point me in the right direction on how to accomplish this, or tell me it can't be done, I would appreciate it.

Some Snippets:

Setting the offsets:

string tempDesc = llGetObjectDesc();
vector tempOffset = (vector)tempDesc;
vector tempLoc = llGetPos()+tempOffset;

The standard teleport code:

(destination is tempLoc)

target = (destination - llGetPos()) * (ZERO_ROTATION / llGetRot());
llSitTarget(target, ZERO_ROTATION);

Thanks, and sorry this is so messy. Have not idea why I can't post text.

Bracken

Until the grownups get here and explain in detail, I can suggest that maybe you will want to use the functions llRot2Up, llRot2Left or llRot2Fwd (depending on the orientation of the wall-mounted TP object) to calculate the offset you need. Look at posts #9 and #11 of this thread /54/d4/334507/1.html for an illustration.

As an aside, when you refer to a HUD, do you mean the blue dialog box that pops up in the top right of the user's screen? Properly speaking, a HUD is an object that's attached to an avatar and appears on the screen rather than on the avatar itself. And when you refer to linked messages, do you mean messages passed in chat? Linked messages are generated by llMessageLinked and trigger the link_message event in the linked prims of a single object, and since linked prims may be no further than 20m apart, it seems unlikely that your TP system consists of these.

I hope this is helpful, and that I haven't, yet again, completely misunderstood the question.

These forums don't like anything that might be taken for an SQL keyword or function. In particular, opening angle brackets should always have a space after them when posting here. See this thread /327/5d/330018/1.html for more info.

I should have been more clear. I meant the blue dialogue box and and messages generated with llMessageLinked that trigger the link_message event. The offsets are retrieved from the teleporters description field (enter as < 0.0, 1.0, 0.2 > and added to the teleporters position retrieved from LLGetPos. The results along with the teleporter's prim name are then sent to the other prims through llMessageLinked where they are combined into a list to be later used by a dialogue box that appears when the user touches the teleport.

Bracken

And I have misused the word offest in the above quote. I meant to say "to calculate the *target* you need". And given that I now picture your TP system to be a single object consisting of linked prims located at the various TP points perhaps I should've said "wall-mounted TP *prim* too.

But I can see that I'm getting way out of my depth again here, so I'd better shut up. I'm sorry if I've wasted your time.

No waste of time. Thanks for taking the time to try to answer, and thanks for the heads up on the forum problem.

Bracken

Don't give up hope. What you want is doable, and someone will be along shortly to explain how

If all you need to do is get a new llGetPos() each time you move things around, you might try something like this:

moving_end() 
    {  
        gPos = llGetPos();
    }

where gPos is your Global variable.

moving_end is the right idea, unfortunately it doesn't actually always work when it seemingly should :/ An occasional timer to check for changes is generally needed for these things.

You can make this really simple. Set the teleporter at zero rotation, figure out what coordinates you like when it's set that way, and just use this for the destination you transmit:

// for a landing 1 meter behind, half a meter over
landing_point = llGetPos() + (<-1.,0.,0.5> * llGetRot())

Go ahead and assume that the teleporter's Z is up. SL has more than its share of crooked and wrecked builds, align with the buildings and forget what the grid thinks =)

Thanks all.

I knew it had to be simple. the offset * llGetRot() resolved the problem. Now excuse me while I go beat my head against the wall a few times to remember this.

As for the moving, I do have a reset built in.

Bracken