Except one case. When the X and Y coords are 128, 128 then it gets it right the first time.

this problem appeared with the voice enabling on main grid.

This problem needs to be fixed not ignored.

This works everytime:
default
{
state_entry()

touch_start(integer total_number)

}

this always fails on first activation:
default
{
state_entry()

touch_start(integer total_number)

}

i have a shopping directory panel with 60 of these buttons for public convenience and am working on other things that use this call so i need it fixed.

If a linden is assigned to work on this then i will assist with recording where these calls randomly go to on first calls to see if there is a commonality somewhere. As it is I see it is unassigned thus is not being looked at by anyone but people that actually use SL.

code follows:

vector dest;
default
{
state_entry()

touch_start(integer total_number)

}

@Ann: Your first two scripts didn't repro for me.

Hopefully we can have a solid repro so we can fix it soon. I'll import this.

here is the code that fails:
default
{
state_entry()
{ llSetText("Death Arena", <1.0, 1.0, 1.0>, 1.0); }

touch_start(integer total_number)
{ llMapDestination( "The Immortal Realm", <29, 162, 29>, <0, 0, 0>); }
}

Note the use of a hard coded coordinate set.
Another stranger thing going on now is the hard coded coordinates mysteriously change in the scripts themselves.
How this can happen is beyond my comprehension. But it is happening from time to time.
Sometimes it is the vector data and sometimes the region name that changes by itself.

Anyway...

The best workaround so far:

vector dest;
default
{
state_entry()
{ llSetText("Death Arena", <1.0, 1.0, 1.0>, 1.0); } }

touch_start(integer total_number)

}

Note the double call to llMapDestination that mimics the manual process of trying to get a slurl or llMapDestination call to product the correct results by using it twice in a row.

Who knows. Maybe someone saw this and slipped in a fix on you Torely.

Scroll back up chat history window to SLURL
Click SLURL
Observe - map opens with right region but wrong coordinates
Raise chat history window which has now sprung back to most recent line
Scroll back up chat history window to SLURL
Click SLURL
Observe - map updated with correct coordinates

I'll try and find an entry on the chat history jumping back to line 1 somewhere else in the JIRA.

• Log into Second Life.
• Teleport to Wengen (0, 0, 0).
• In a web browser, enter this: http://slurl.com/secondlife/Rizzo/134/120/605/
• Click the orange "Teleport Now" button.

• Observe: On the World Map, the coordinates say Rizzo (0, 0, 90) (or something close to that).
  = Expected: Coordinates should be Rizzo (134, 120, 128).
  > Workaround: Click the "Teleport Now" button on the SLURL webpage twice.

The problem I have now is the 'Teleport' button is always disabled. But if I click somewhere on the map so the red arrow appears, then close the map, then touch the object again, then the 'Teleport' button is enabled. Is this a related problem?

Unfortunately, due to user demand it was shifted back to opening a map, and the bug has returned with that code.

And of course, nobody at Linden Lab even bothered to FINISH this function. Half of its spec doesn't work. The second set of coordinates is supposed to determine which way the avatar faces upon landing.

If someone is pressing a movment button when the map appears it can clear the mapped destination.

I use the workaround of sending the map 3 times waiting 0.5 seconds between each map to give them time to stop pressing buttons, while resetting the map to the desired destination.

@Cheshyr Pontchartrain
You could have used show stopper. (1) It breaks content. (2) It is widly used and effects a huge number of people.

Darling Brody.

Could this behavior, or something similarly related, be responsible for the observed issues here? That for whatever reason, the map is displaying only the first part of the teleport jump?

On the other hand, if the map pops up and does NOT steal focus, then there shouldn't be any problem of input (such as walking) affecting the map coordinates, if in fact that is what is causing the problem. From Torley's repro, however, it really sounds like the problem may be something else, possibly related to how the teleport information is being relayed to the map.

Regardless of the cause of the problem, switching focus to the Teleport button is not a very good solution and will create more problems. The map simply should not be stealing focus anyways, and so I would start from there.

SL is different.

Supporting factors: The problem disappears when "show map" was replaced with "show parcel destination." Hence, masking the latency issue by allowing time for the client to receive necessary data, should the user, at that point, click show location on map.

Potential solutions: The client code appears to be using a system timer that is set to n-µsecs, as opposed to, say, a map destination callback from the server. With this in mind, following are some potential solutions with both Pros and Cons listed.

++++++++++++++++++++++++++++++++++

PS1: Compute n on the fly by relying upon reported stats.

Pros: This is a client only change. Increases the likelihood that the required data will arrive before the client software displays the map.

Cons: Increases client load, though this is negligible. It's a stop-gap as even the computation will be somewhat arbitrary since database access time and network latency is highly volatile. And, in some instances, behavior that is described under cons in the following potential solution could also occur.

++++++++++++++++++++++++++++++++++

PS2: Implement callback

Pros: Guaranteed data delivery

Cons: Requires changes to both server and client code. Latency issues are now visible to the client. In other words, the inherent prob in this solution is waiting for a callback. If latency is especially high, a noticeable period of time will pass before the map (or even, say, a timeout notice, similar to say, the group chat timeout notice) is displayed. This could, in return, be seen as a bug by the user. So next thing you know, users are regularly complaining about map lag.

++++++++++++++++++++++++++++++++++

PS3: Revert to showing the "parcel destination" instead of the map for slurl & llMapDestination calls.

Pros: This is a client only change. This buys time for the data to arrive.

Cons: Although viewing the parcel info can be nice, in general, users want/expect to see the map. This additional step required by the user (i.e., now having to click "show destination on map") has already been proven to be seen as an unnecessary extra step by the user community.

++++++++++++++++++++++++++++++++++

Summary: Even though SL is now sitting on a network backbone, as long as it continues to use a toy database, this and other latency issues will continue to be seen. In other words, from the big picture perspective, this is about scaling (or lack thereof), and the obvious culprit is the toy database.

What I also dont understand is how this bug which EVERONE suffers from dosn't get fixed while the map bomb that only effects people involved in combat get fixed!

Maybe the trick is to be rude and abnoxious like the people were in the map bombing jira? They demanded that their jira be fixed before this one and they got what they wanted.

I am, however, confused by your claim that the redundant call trick no longer works. I still call llMapDestination() twice, and as of this morning it was working properly.

Perhaps the solution to this problem is not nearly as clear-cut as it might appear. That would be one explanation as to why it has taken so long. Also, how does this bug reproduce using 3rd party viewers?

I decided to test this question out myself. I am currently logged in using the Emerald Viewer, and this bug did not appear. That is to say that when I called llMapDestination() a single time, it brought up the map centered on the correct coordinates.

Reproduction:

In the region Aeronautica Central, I was standing at the location <191,242,22> and I created a prim next to me and input the following code:

[code]

default
{

touch_start(integer total_number)
{
if(llDetectedKey(0) == llGetOwner())

}
}

[/code]

I managed to confirm that this worked as intended. The map popped up, with the correct region, centered on the correct coordinates. The Aeronautica Central region was selected simply because it was where I had last logged out, and thus where I logged back in today. The target destination was chosen simply because it is the region where our store is, thus first region to pop into my head. The target vector was chosen randomly, I simply wanted X and Y values that were different enough from my current location so as to ensure a fair test.

Note that the version I was using was Emerald v1.23.5.1455, which is not the current release version. I will test a bit later using the current 1.23.5.1101 release to confirm whether it works with that version as well. I'm not even sure if I currently have a copy of the LL 1.23.5 client, but I am certainly willing to download that and test it as well.

However, this does demonstrate that the problem may be fixed on some 3rd party viewers. If this is the case, and as all 3rd party viewers' source-code is open, it should be easy to figure out where the problem is occurring. However, note that I was also in a sim that had very little lag, and few people, and thus the map popped up with little loading time. It did not matter whether the code was compiled via the Mono or LSL VM, it worked both times. In fact, I double-checked this using a few other locations as well, and it appears to be successful.

As I said, I'll test using the release version in a little bit, and might be willing to test out the LL version just to double-check. However, I can report that the problem does not appear in at least one version of a 3rd party viewer.

Fortunately it looks like I do have a copy of the LL viewer 1.23.5 on my computer already, so I don't have to go download it. Want to see if I can go three for three here? If it works on the LL release viewer, then I'm going to mark this as resolved. If it doesn't, I'll download the most recent CoolViewer release and see what happens there.

I opened my map manually, and removed the map marker (had it show my destination, then clicked on my own location). Then I clicked the box again. This time the map opened to the correct coordinates. Strange behavior, I thought. Perhaps the coordinates do need to be sent twice to work correctly. But then I got an idea. I once again recentered the map on my location and removed the map beacon. Now, I changed the target coordinates around, I think something like <22,140,50>, or something similarly different from the coordinates previously used. Now I once again clicked on the box....

And the map opened to the correct coordinates! That is to say, it opened to that region, with the <22,140,50> coordinates that I had just updated the script with.

Clearly the problem is not with the script having to re-send the coordinates to the client, but perhaps that if the map itself has not loaded the destination region prior to llMapDestination() being called, the default behavior of the client is to simply use one's current coordinates. Note that I use different cache locations for each different client version, so it is possible that the LL client had not yet had a chance to fully load the map, I do not know.

However, I would hope that this sheds some light onto the problem here. It may simply be a matter of ensuring that the client's map has loaded the target region before llMapDestination() is called. Once the client's map has loaded that destination region, it will readily display the correct coordinates without being called twice. This is clearly demonstrated when I changed the target coordinates, and the map was able to load the correct coordinates on the first try.

It is possible that the Emerald viewer loads the map faster, it is possible that I had the target region already loaded in my cache somehow on Emerald, which I had been using regularly, but not on the LL client, which I had rarely used. This is why I mentioned the issue of different cache locations, since the LL client's cache may not have contained the information ready to display that region on my map.

Now we can add this to what is known about how region-to-region teleporting works, where the agent is first sent to the destination region, and then moved to the correct coordinates, and this begins to make some sense. Since teleporting requires this two-step process, it is highly likely that llMapDestination() may require a similar process. The target region must load on the map first, and then it will load the target coordinates.

This might also explain why calling the function twice has been a viable workaround, since what one is essentially doing is telling the client to load the region with the first call, and then the second call simply makes sure that the coordinates load now that the region has been loaded.

However, please understand that much of this is conjecture. What I do know is that the function appears to work as intended when using a 3rd party viewer, and it appears to work as intended using the LL viewer when the target region has already loaded on the client's map and cached. I am more willing to believe that the difference here was the different caches rather than the different clients involved. I really, really really don't want to have to mix and match caches and clients just to rule out this variable, so I would hope that perhaps others (especially those who actually have some financial interest in ensuring that this function works, unlike myself) could do some more testing to see how this reproduces using different clients, and whether my theory about having the target region already loaded on the map previously (and thus in cache) has any bearing on this.

This is what I meant earlier about how this problem may not be as simple as it appears. The end solution may be for the function's behavior to be slightly altered so as to either wait to send the target destination's coordinates until it receives confirmation from the client that it has located and loaded the region on the map, or the function could simply send a second packet after the first one, essentially telling the client to double-check the coordinates.

On the other hand, we do know that the Emerald client has altered how it handles the packets resulting from llMapDestination() at least slightly from the way that the LL viewer does (in that it has the option to block them entirely). It is possible that something in this code makes this function work more reliably, I do not know. Perhaps there is some slight delay that allows the map to load the target region. Perhaps the client retains the target location while it waits for the region to load. Unfortunately, I have little knowledge of the actual client code involved in any of these clients, and have no experience compiling clients on my own.

However, it does appear that the fault lies somewhere in the map loosing the target coordinates if it has not loaded the target region in a timely fashion, at least in the LL 1.23.5 viewer, rather than any fault in the server code involving the llMapDestination() function, which also would explain why this problem was not present when the client code was briefly changed to bring up a landmark-style card instead of the map, since that method likely loaded the region and coordinates at once.

This is especialy easy to see with stargates that you walk though. The map pops up, your pressing the walking arrow key which wipes the destination.

They need to pop the map and have no button/dialog set in focus to prevent the destination being altered by inadvertant user input.