Talk:LlEdgeOfWorld

Diagonals

Does this work diagonally? I've tried llEdgeOfWorld( <128,128,0> , <1,1,0> ) and such but the result seems to be based off of other neighbors (North, East, South, and West) ----Gregory Maurer 22:46, 27 November 2010 (UTC)

Short answer: No.

Long answer: Objects can't travel diagonally between regions (last time I checked ... 5 years ago). If you try it with llGetPos or llBreakLink, they will first go through the East/West adjacent region then into the North/South destination. This means if the East/West is missing then it goes off world even if there is the North/South adjacent! With this implementation detail, the diagonal values are of little use.

I investigated this in 2005 while trying to make a tool that would map the grid. For the sake of writing speed I will be using the old terminology. It utilized a bug in the max link-distance rules. Keep in mind the Private Islands were new and rare; Estates hadn't been dreamed up yet, Void Sims likewise. The vast majority of sims were in the and it lacked Void Sims. As a cool scripting project I wanted a Map of the Grid that could be periodically updated automatically. I wanted it to update in such a way that it wouldn't send out a huge fleet of drowns to wander the grid. I wanted something elegant, and I knew of this bug that could provide it. It used a two prim object, the root would act as server, the child as probe. The child would manipulate it's position, growing the link distance to humongous values, so that the child was no longer positionally in the region, the root however never moved.

Once the prim was in position over the target region, the link would be broken. The hypothesis was that the root would remain but the child would appear in the target region without going through the intermediate regions. At first it looked like this was true, but it was failing in interesting very repeatable ways. The hypothesis supported by my research was this: The root would remain but the child prim would first move from region to region along the X axis first until it's X position was satisfied, then it would go about satisfying the Y position and finally the Z position. If there was a missing or offline sim in the path described by the later hypothesis, the child would go offworld (and be returned to my inventory). More over if the root were lower then the land in the target region, it would be deemed offworld before trying to satisfy the Z position.

As my research progressed, I soon found the regions I was using for my testing were becoming resistant to the bug I was using. It's not that it didn't still work, after I exceeded a specific excessive limit the sim would kill my object. Mean while I had realized this same bug could be used for (sit) teleporting avatars across several regions (if you accepted the before mentioned limitations). The teleporters based on this were interesting, they had however a tendency to crash the region. It wasn't until later when talking with a Linden about the region specific limits placed upon my bug that I learned my mapper had been the cause of grid wide lag and simulator crashes. The physics engine apparently didn't like objects with huge link distances.

I just remembered this detail: A major driving force behind this project was that teleportation up to this point was restricted by LL and you had to fly/walk/drive from the Telehubs to your final destination. What we needed was an alternative fast mode of travel and if it didn't go through the intervening simulators all the better. And then there was the mystery of the new Private Islands and all the hidden wonders they promised. A teleporter that could breach a private island was much sought after. As it turned out the teleporter could only reliably transport an avatar two regions and not across voids. -- Strife ^{(talk|contribs)} 07:28, 28 November 2010 (UTC)