1.9 broke llMapDestination

I can't seem to find a thread about this, so I'll post this here.

llMapDestination broke in 1.9. It used to work that you could put in the current region name, and the vector of the destination as it would come back from the dataserver event when using llRequestInventoryData with a landmark.

Now when you use llMapDestination in this situation, it only works properly if you are in the same sim as the landmark. This should break a lot of devices that people made since 1.8 (including one of mine). I hope this is a bug that will get fixed.

That was a bug in 1.8 as well

Actually it worked fine in 1.8, at least it did for me. Something changed in 1.9.

welp, i had this exact same problem in 1.8

I just confirmed the following this morning. The sample code in the wiki no longer works unless you happen to be in the same sim as the landmark you dropped into the attachement:

key request;
string name;
string sim_name;
vector pos;

default
{
    state_entry()
    {
        llAllowInventoryDrop(1);
        if(llGetInventoryNumber(INVENTORY_LANDMARK))
        {
            name = llGetInventoryName(INVENTORY_LANDMARK,0);
            request = llRequestInventoryData(name);
        }
        else
            llWhisper(0,"Please drop a landmark on me");
    }
    dataserver(key id, string data)
    {
        if(id == request)
        {
            pos = (vector)data;
            sim_name = llGetRegionName();
            llSetText("Touch to show \""+name+"\" on the map.",<1.0,1.0,1.0>,1.0);
        }
    }
    touch_start(integer a)
    {
        if(name != "")
            llMapDestination(sim_name, pos, pos);
    }
    changed(integer a)
    {
        if(a & (CHANGED_INVENTORY | CHANGED_ALLOWED_DROP))
            if(llGetInventoryNumber(INVENTORY_LANDMARK))
                request = llRequestInventoryData(name = llGetInventoryName(INVENTORY_LANDMARK,0));
    }
}

I don't understand what's broken about this.

You're giving it the sim name you're in, not the sim name in the landmark. Why would you expect it to deliver you to the landmark's sim?

I'm missing something here...

This bug seems to be buggy LSL code, instead of a bug in SL to me, I just tested this in game, by making the game give me these coords: Lusk: 250, 200, 10 and it showed the location on the map just perfectly with this code while I was standing in the sim Benham:

default
{
touch_start(integer total_number)
{
llMapDestination("Lusk",<250,200,10>,<1,1,1>;
}
}

Because that's exactly what the wiki code does too. And because there is no way for LSL to query a landmark and get the sim name of that landmark.

It works like this, the dataserver event gives you a vector. That vector describes the relative position from the object to the landmark. As llMapDestination was originally implemented (and used in the wiki), you could take the vector from the dataserver event (to get info from a landmark) and the name of the sim you were currently in and it would show you the position of the landmark on the map. Pretty nifty. A HUD attachement could become a two click p2p system that runs off landmarks.

Now in 1.9, you need the name of the destination sim. The problem is, there is no way to get that information from a landmark through something like a dataserver event. We either need a different function to get the actual sim name and position from a landmark or we need to restore the previous behavior of llMapDestination (and future behavior of llTeleportAgent). Otherwise both of these functions (and the dataserver query) become much less useful.

Right, that works fine, because you already know the sim name and vector of where you want to go. If you want to get that information dynamically from a landmark (like in the wiki example), you are screwed. You can't do it now.

According to the documentation of the dataserver event in question it returns the region coordinate of the landmark. Not the global coordinate nor the relative position of the object from the landmark.
It sounds like the dataserver event has changed. I'm not in-world, but when I get in-world I'll play around and see what it's actually returning.

Or, if the wiki's wrong, maybe you should go in and correct it?

Ok, so try this in a HUD attachment

This works:

default
{
    touch_start(integer total_number)
    {
        llMapDestination( "No", <10,10,10>, <1,1,1> );
    }
}

This does not:

default
{
    touch_start(integer total_number)
    {
        llMapDestination( "No", <10,1000,10>, <1,1,1> );
    }
}

It stops at the sim border.

It won't work if the x, y or z values are greater than 255. See Jillian's post on this here: /139/4a/94472/1.html

In 1.8, the values for the position could be greater than 255. Now they cannot.

One more thing, I apologize if I'm having trouble explaining this, but it is a change and it does restrict the uses for llMapDestination (and perhaps a future llTeleportAgent).

If there is a good reason why llMapDestination was confined to a maximum of <255,255,255>, that's fine. I hope they create a workaround for us. But this smells like an accidental change or a change by someone who didn't understand that it would break existing scripts and limit llMapDestination's usefulness. If that's the case, at the very least I would like to make LL aware of it (which I've been trying to do through bug reports and other methods).

Ah, so the value returned is neither really a region coordinate nor a global coordinate, but a mixture of the two. You could have explained that right at the beginning and avoided a lot of confusion... because on the face of it the documentation and the observed behaviour do actually match.

It doesn't appear to make sense that the Z-coordinate gets clamped to 255 m.

As for the rest--I'm not sure of the intricacies involved, but will ask.

My apologies, folks. I'm responsible for 1.9 clamping llMapDestination vectors to positions between 0,0,0 and 254,254,254. I didn't know people relied on it working for positions outside that range.

I've changed the code to go back to the old behavior. This will ship with the next server patch, probably 1.9.0.18, probably in a week or so.

Sorry,

James

Hooray! Ty! Ty! Ty!

greatly appreciated takes a big guy to fess up like that. looking forward to zapping myself around the grid with one dialogbox button...

Yay it's fixed!

Are you sure your simulator has been updated yet? They won't all be updated until around noon today. The fix is on the server, not the client.

Z values are not clamped anymore. You can try values > 256, but I wouldn't recommend going too high. The avatar gets wonky much above 512 meters.

James

Sorry, my sim must not have the update yet.

Wee!

Things alright for ya now, Keiki?