Teleporters in Second Life have been plagued with the use of
warpPos function which, although it is supposed to accomplish a simple task, the implementation is obfuscated with magic numbers, the design is very poor and funny effects are acheived. Here is a rundown of the problems with
// Try and avoid stack/heap collisions if (jumps > 411) jumps = 411
with no explanation whatsoever about what that means and why an overflow occurs.
warpPoscalculates the number of jumps necessary and then proceeds to jump 10 meters in the calculated direction without even accounting for affinity.
warpPosis based on a function that blocks the event handler which has the effect of timing out on OpenSim due to the timeout imposed on event handlers: an event handler just goes away after some time and
warpPoswill fail for long distances.
The following code should solve those problems by using vector calculus and calculating 10 meters in the direction towards the final destination. The function doing that is
jumpGates which recursively computes hops towards the final destination and returns them in a list which we process later using a timer. By using a timer we make sure that the handler does not time out and we call that timer using the minimal float value (
1.175494351E-38) since there are no limitations on the minimal
When jumping to the next gate, we additionally use the list as a stack in order to pop off the first coordinates and discard them from the list entirely. This makes the script start with an initial memory pool and, as it runs, it frees up memory instead of consuming more and more memory.
The example teleporter below is meant to be placed in a primitive with the object description set to a region position which represent the destination. For example, create a primitive on the ground and set the object description to:
<14.233517, 86.036453, 1004.25>
which, when an avatar sits on the object, will move the primitive along with the agent to the coordinates
<14.233517, 86.036453, 1004.25>. The script will then unsit the avatar and return to its original position.
If the teleporter is to be used on Second Life, the best variant to choose is the fast handler blocking teleport that can travel over great distances while being memory safe. The other scripts are meant for OpenSim, although the fast handler blocking teleport can be used on OpenSim as well provided that the distance to travel is small enough so that the
state_entry handler does not time out.
The Jump Gates variant uses jump-gates to precompute the jumps. One problem with precomputing jump gates is that the script may run out of memory. One could implement a check to test the available memory and then recompute the jump gates. However, that is ugly because the memory threshold may vary between implementations. The safe way is to not use a list at all and for that you can use the Safe Teleport variant.
If you are looking for a teleporter that supports multiple destination, that can be found on the multiple destination teleport page.
The different teleport flavors are summarized in the table below.
|fast_handler_blocking||This script is the variant that should be used on Second Life.|
|slow_safe_teleport||This variant is best suited for OpenSim.|
|slow_unsafe_teleport||Good for OpenSim but dangerous over long distances.|
The scripts are to be found in the teleport folder below.