Does a normal Teleport script have problems pushing you thru prims?

I have found a couple of TP scripts and for some places they work fantastic.

One click and pop I'm up 100m into a skybox (straright thru my roof and the floor of the skybox en-route)

However exactly the same script just moving sideways thru a few prim walls to get outside into a tree house normally makes me end up zig zagging around during the teleport and plopping me at (I think) the right heights but just near the coords.

And again, other places seem fine to TP to using the same script.

I know these TP's kinda push you to the location, or rather I think youin effect are being sat on the prim, the prim moves you there and the prim moves back (all very fast)

Is there then some issue at times when this prim has to move thru walls and joins in walls to certain locations you may set up?

ALso, (on this topic) I've noticed you often arrive as if you are laying horitontally and quickly stand upright as you appear. Is this "the norm" for this kind of Teleport also?

Thanks

The landing point is crusual. If it is close to or inside an object(floor, wall or ceiling) you will "zig zag"


That depends how you sit on the prim that teleports you. If you do not sit upright you will arrive in an odd position. Use: 'llSitTarget' to sit right

Here is a little program snippet to make you sit upright:
llSitTarget(<0.0, 0.0, 1.1> * (ZERO_ROTATION / llGetRot()),ZERO_ROTATION / llGetRot());
This will sit you upright 1.1m above the prim no matter how it is rotated

Many thanks for the advice. I will have a play and adjustment later.

Yes, in my early days I found out about moving the TP box itself, esp without resetting the script.

Just thinking, Oh, I'll rotate or move the box a little then using it, and wondering why I was sent out into space !!! LOL

See this for reference:
http://www.lslwiki.net/lslwiki/wakka.php?wakka=teleport
In here is mentioned a "real" and a "fake" teleport.
What I said about landing position and sitting upright goes for both types

In addition to the tips from Dora, try adding a half second sleep just before the unsit. This lets the server have time to void any enertia your avie may have gained moving to the sit pos. This will agravate the apearance of standing from a sit, so play with the delay till its tolerable. Or take perms and force a standing anim rather than the generic sit.

I'm starting to get really fed up here.

the Zig Zag problem.

TP from one room to another.

60% of the time it's fine
40% of the time you get thrown either around the room, or end up outside the room.

I've put the laning points a little away from walls and incresed the height 1m.

Guess I just have to fiddle the figures then?

Try using a moving prim.

I quit selling my 300m "long range" sit-offset teleporter and I've gone to moving prim teleporters exclusively.

You mean they type where (in reality) you sit on a prim, the prim moves to the new location, drops you off then moves itself back?

If so, I actually just changed to one that does that last night and it seems better 99% of the time. But also as it has a delay when it arrives to unseat you and wait before returning.

Or do you mean something different?

Yes, that's what I mean.

You need a certain amount of delay before unseating in either case... unseating immediately makes the "flying all over the place" problem worse.

What mine does is delete itself instead of unseating you, meanwhile the teleport pad rezzes a new one, so there's less delay for people following you.

Ah that sounds good.

I have two of them which are both one click sit and you move.
One a script from these forums, the other a gift in-world (both freeware so to speak)

One of them you SEE working more. In that you can just catch a glimpse of the prim before it shoots back to the starting point.
I know this one shoots back as it didn't work and got stuck when I didn't have "Object Entry" selected on two ajoining parcels I used.

This one also has a 1 second delay when getting you off and before moving back.
And is the more reliable of the two.

The other one appears faster, but I end up zig zagging so often it's unusable (about 50 to 60% failed TP's_

I'm TPing to a 10m x 10m x 6m room space and often find myself outside it and banging against various walls.

the other one. Slower with the delays seems less prone to that. I tried speeding the two 1 second delays at the end of the TP down to 0.5 seconds and it became a tiny bit less reliable, about 80% ok I's say.

The odd thing is, the 1st one I mentioned takes me from ground, thru a roof up 3500m and into a BIg room reliabaly every single time, it's the short hops into smalleer rooms that seems to be the problem.

you're re-rezzing a fresh base unit sounds a great idea.
Is it availiable to try/experiment with, or some prvate work?

In an ideal world I'l like a 1 prim multi TP unit, and again found a script of these fourms, but got the zig zag issue badly with it

On a related side issue:

Can anyone please explain in VERY BASIC talk

How the different methods of TP actually work and the pros and cons of the types and also how can you tell)

eg: I could go any buy one thinking it's going to be more reliable than my free script, only to fund they all use the same basic code and all will suffer the same basic issues for each type.

Thanks

Well, my Netporter is a moving prim teleporter. It uses the same basic warp script that most of the moving prim teleporters use. It's designed for ease of use by both the owner and users.

The teleport prim is always present to use. That means when someone comes to your land they can teleport immediately, instead of clicking on the base, pickinging a destination, and waiting for the teleporter to rez. I don't know why this isn't more common, because I find waiting for a teleporter to wake up after I arrive somewhere pointlessly annoying.

You sit, then pick a destination by a button. This is how Cubey's first moving-prim "Terraporter" worked, though it made you cycle through destinations. For some reason most of the teleporters I see in-world make you click on them, then they ask where you want to go, then they rez the beam.

Each new version of my teleporter has simplified the configuration. You don't have to create a notecard or copy down the location of the teleporters, you just have to put the name of the location into the teleporter pad's description.

I try and keep the network internally consistent. Bases pass messages at a low rate unless they're moved or deleted, and the network is synchronized within 10 seconds of rezzing and naming a new pad. The product that appears to be the market leader only appears to load the network when someone clicks on it, adding to the delay before someone can use it.

Technically, I use llSetPrimitiveParams (WarpMove), using a single list for every stage in the jump rather than moving to waypoints. This involves building up a long list of [PRIM_POSITION] commands each of which moves you 10 meters closer to the destination, and passing them to llSetPrimitiveParams in one step. Linden Labs has approved this hack and fixed it when they inadvertently broke it in an up date. There are other hacks that are more efficient involving building up a list with an impossible intermediate destination but until LL approves them I'm sticking with one that works.

I use llRegionSay for synchronization, sending one message when the base is set up and on moving_end and similar events. I also send keepalives after a period (several minutes) of no network activity. Communication between the base and the teleport beam is via the on_rez parameter to pick a channel and llWhisper()...

If you don't want to buy one, there's enough information to build one. Google for "WarpMove" to find the key component... I've had to re-edit this message several times to avoid triggering the forum's daft SQL-exploit filtering, so I'm getting tired of typing. Try plugging WarpMove into the "teleport beam" version of Cubey's Terraporter (I think it's the Terraporter II) and you'll have a decent start.