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.