Discussion: llWarpPos Cross-Sim Transportation

I'd like to take the liberty to suggest the following changes to the ordinal_border function:

Replace

    if (ordinal.y > 0)
        ordinal.y = 255;

by

    if (ordinal.y > 255)
        ordinal.y = 255;

and

    if (ordinal.x > 0)
        ordinal.x = 255;

by

    if (ordinal.x > 255)
        ordinal.x = 255;

This will avoid overshooting the destination when travelling "right" and/or "up".

I replaced the llWarpPos with warpPos. My way of scripting, may be difficult for others to understand, but as long as I am able to understand it, I am fine.

I released this open source because I felt that people could get good use out of it.

With regard to the concerns about people using it to make nukes to travel to other sims, I have 2 replies to that

1) It explains on the WIKI under llSetPos how to acheve sim crossing.
2) They could very well go and nuke it themselves if they wanted to.

Maybe releasing this was a mistake. I don't really know, and frankly, I don't care. Its released, and there is no taking that back.

Hopefully something good can come out of this :/

This certainly makes Warp Drives for "the Big ships" possible. Using the nonphy movement scripts is fine and dandy for driving around a sim, and maybe crossing a few, but big ships need big engines that allow them to deploy fast and long ranged.

This means for all us shipbuilders, this will be incredibly useful. Who wouldnt want a WARP drive on their ride?

Now I figure out how it works :/

    if (llEdgeOfWorld(pos, first) == FALSE)
        return first;
    else if (llEdgeOfWorld(pos, second) == FALSE)
        return second;
    else
        return <-1, -1, -1>;

This piece of code is fundamentally flawed. If anyone can tell me why, I'll post a fix

its flawed because your first and second variables will have to be offset from the current position for it to respond right ..... as an example lets say:
first = <5, 20, 80>;
second = <200, 45, 50>;
pos = llGetPos(); //lets say your at <125,10,125> for now.

now with the above settings calling llEdgeOfWorld(pos,first); will check if the edge of the world is the same direction as the point <130, 30, 205> when you wanted it to check if <5, 20, 80> was pointing to the edge of the world.

to fix this, instead call llEdgeOfWorld(pos, first-pos); .... this will return the answer you wanted.

Generally speaking this is absolutely correct.

In our specific case I propose a slightly different solution:

First you'll have to consider, that first and second normally take one of the forms
<0,128,z>, <255,128,z>, <128, 0, z> or <128, 255, z>, representing potential positions for crossing into the adjacent sim (if there is one).

(There is of course the special case that, after the modifications I proposed earlier, EITHER 0 < x < 255 OR 0 < y < 255 meaning that we're not going to need to cross any more sim borders along that axis, but in that case we won't be checking for a border in that direction, so we'll not worry about it.)

We know that llEdgeOfWorld(pos, dir) tries to solve (pos + f*dir) so that it intersects with the edge of the world. That's also a good indication that unless we're immediately dealing with the direction of an object in the world (obtained e.g. by llRot2Fwd), we're best of using unit vectors. That way we'll emphasize that the magnitude of dir is really of no concern.

In the case of this warp script it is really of no consequence what vector we have from pos to first or second. We will cross along one of the four sim borders (if we can) which happen to lie west, east, north and south of any point in the sim. Therefore we only have to consider <-1,0,0>, <1,0,0>, <0,-1,0> and <0,1,0> which I represented by the constands WEST, EAST, SOUTH and NORTH.

The values of first and second already tell us which borders we'll be attempting to cross, so we can easily map those values to the direction we'll need to check.

If the x component is zero, we'll check WEST, if it is 255 we'll check WEST, if y is zero we'll check SOUTH if it's 255 we'll check NORTH. For any other case we can pick a direction to check in as it is of no consequence (this will have to change when implementing a path-finding algorithm).

Dr. Ian Malcolm: Yeah, but your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.
---
Dr. Ian Malcolm: I'll tell you the problem with the scientific power that you're using here: it didn't require any discipline to attain it. You read what others had done and you took the next step. You didn't earn the knowledge for yourselves, so you don't take any responsibility for it. You stood on the shoulders of geniuses to accomplish something as fast as you could and before you even knew what you had you patented it and packaged it and slapped it on a plastic lunchbox, and now you're selling it, you want to sell it!
---
I thought I recognized this debate, and as Ian said it more eloquently than I could--well, there you have it.

As of this post I have been in SL for all of 16 days now. StumbleUpon brought me here, but its the scripting that brings me back.
It seems the main point is the "cut-and-paste'ers", the potential is too great for the uninformed to do great damage. So should scripts be posted for possible mis-use? ( I avoid the issue of intentional abuse, as malice usually finds a way.)

Would you rather see something like:

while ( !server_crash )
{
rez_obnoxious_scripted_prim();
}


...or an exact copy of the well scripted, well documented Swarm script by Apotheus Silverman, that I found and have used? I freely admit I have not a clue as to how it works, but it does, and well. There will be a day that I will understand it but until then I have no worries that the script will run wild.

In conclusion--I am a cut-and-paste'er. I take it on faith that everyone at this point knows more than I about scripting, and if a script has been posted it will work correctly. It seems to me not should a script be posted, but is that script going to be a good *teaching* example?

I'm going to speak with two hats here. I'm a teacher IRL and in SL, and a scripter too, of sorts.

Posting scripts can be done for a number or reasons. Unlike some people I'm not really convinced that warpPos is "evil" there were plenty of tools for greifers before and whilst this could make one aspect of griefing the grid easier, there were more than enough successful attacks before this was posted, and the arrival (well documented after the act, and amended) of the grey goo fence which to my knowledge has stopped all but one attack since that time. That attack didn't use this method. So, posting the WarpPos script hasn't had a downside that I've seen personally, nor seen reported. What it has done is allowed people that want to play with such things to see and share a relatively new idea for using something in a cool way. There might have been a few people out there that knew about this feature, but it was a flash of inspiration to the rest of us. From that point of view a good teaching tool to existing scripters, as it communicated an idea for us to use. It also wonderfully allows the 'cut and pasters' who want to use the tool to use it.

Posting scripts here doesn't have to be educational. In fact quite a few of us will share "utility scripts" quite happily to let others use them. All scripts posted to the scriptlibrary are duplicated here for discussion - the owner's intent in posting to the script library is almost always to share. This strikes me as falling into that category. Having them well commented so others can also understand what's going on would always be nice. But actually the long discussion on this thread has teased apart the script quite nicely so you can still learn from it.

Requests for "how to" (which start their life here) usually get answered with here's the references and the pointers you need. People who post whole scripts and can't find out why they aren't working moderately often get rewritten whole scripts back - sometimes it's better to totally restructure and explain why yours works than try to lead them through the process of altering their own script. They're the places that are directly about teaching, they're specifically to answer a question, and hopefully they get commented or mentions about why this approach works.

I know Im being a pathetic non scripter who struggles with rezzing objects, but How does this script work? What are the commands. No one, and I mean no one I ask can figure it out. Even scripting folks dont know "how" it works.

I don't think this issue is as big as you think. The LSL Wiki contains an exellent single-prim linked door script (Timeless Linked Door) - and yet, people in SL spend loads of L$ and hours of fighting crappily written, sometimes expensive - door scripts.

I could never understand why, and after having befriended me, I know several builders who aren't experienced scripters, who are thoroughly enjoying the fruits of me pasting Timeless' door into a script and giving it away for free...

As such, Zack seems to be ahead of the curve... He at least reads the forums, even if he is still trying to understand how to use his new knowledge.

Having said that, people have already used warpPos() to do stuff like make teleporters to skyboxes > 300m - once they find out that the llUnSit() hack doesn't work more than 300m away... Modifying warpPos() to cross sim boundaries was an expected next step for warpPos().



It's operation is simple, in many ways, to most other sittable objects in SL:

You sit on it.

What happens after that, is left as a reader exercise (which is a fancy way of saying "Study, grasshopper, and some day you will understand..."


- d.

512m, please. You can pick up the script in my store on LostFurest dAlliez... after using it to jump straight up 500 meters.

WarpPos has some advantages over SitHack, but because the teleporter itself moves it's not as clean for people following each other through a teleport. As I have time I'm working on a cleaner WarpPos-based version. though at this rate llTeleportAgent() will be implemented by then.

You want this thing too, huh?

I've been looking over this script, and understanding bits and pieces of it when I see them. I copy/paste, except for the fact that, after I have it in the script window in SL, it seems easier to understand,e verything color coded and spaced out.

If this script helps take care of inter-sim lag, then it's a god send for people making airplanes. If it's just for objects crossing sim boundaries, then I say it has been done before, whether efficient/good or not.

From the wiki:


I tested this at one point, trying to go > 300m straight up, and was left mid-air at llGetPos + 300m(Z)... Unless you are talking about a glitch, along the lines of getting llSensor() to work > 96 meters...

It was a fun fall back down, though.


- d.

Try working out the length of a line from the centre of a cube to a vertex when the sides are 600m long (or it's 300m in each of x, y and z from the centre to the vertex if you prefer).

Simple, half of one side times the square root of two.

Actually no, that's for distance from center perpendicular to an edge.

The distance from center to vertex is a simple trig function, though I can't think of what kind of angle the mid-side, center, vertex would make.

side of cube = s
distance from vertex to cube center = x
angle formed with midpoint center vertex = u

cos = (s^(1/2))/x : x = (s^(1/2))sec

tan = (s/2)/(s^(1/2)) : arctan((s/2)/(s^(1/2))) = u

so x = (s^(1/2))sec(arctan((s/2)/(s^(1/2))))

The trick is that this offset is along the *objects* axes, not the *world's* axes. Think about it.

The 512 meter limit seems to be a different beast. You get VERY strange results going past 512m.

Corrected:

So, what's ?3 X 300 then? Or was I too cryptic for everyone?

Actually it works out to be 519.615m (to 3dp) with that and Argent's rather bigger hint you can maybe see why she says 512m max range for a tp?