|
|
|
Consider for a moment that this defect is changing hard coded vector data in real time. How many other vector data instances are being scrambled across SL? if one can be scrambled then any can since as far as I know this function was not touched in any update. So there is something more serious going on here that can have a lot of implications for anything involving vector data.
Considering the troubleshooting done by Adriana Caligari and the fact her use of llMapDestination is not affected by this defect I tried the following successful workaround below that uses declared variables instead of passing hard coded values which is better programming anyway. Note the double use of variable dest instead of the <0, 0, 0> for the unused point at coordinate (thanks Adriana!).
code follows: vector dest; touch_start(integer total_number) { dest = <29, 162, 29>; llMapDestination( "The Immortal Realm", dest, dest); }} I'm seeing this happening with SLurls too. I click the Teleport button on the slurl.com page, then SL sets the correct destination region, but not the position. I have to click the teleport button again to set the correct position to tp to.
This sounds clear enough to repro; I hope to have a look soon (since one of my areas of focus is Grid exploration).
@Daedalus: I've seen this sporadically but have been unable to come up with a solid repro (so far). Most of the time it works for me, but the occasional times it doesn't is annoying.
@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. those are not repros but workarounds. but there is a better workaround down below.
here is the code that fails: touch_start(integer total_number) { dest = <29, 162, 29>; llMapDestination( "The Immortal Realm", dest, dest); llMapDestination( "The Immortal Realm", dest, dest); }} 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. worth a note to say that the code that fails does bring up the map. look closely at the coordinates.
if they do not match what is in the script then you just repro'd the defect. I'm getting this roughly 75% of the time when I click on a SLURL in the chat history window.
It doesn't help that there's also a scroll bug at the moment! So: Scroll back up chat history window to SLURL I'll try and find an entry on the chat history jumping back to line 1 somewhere else in the JIRA. Also see Hugo Dalgleish and others' observations in
This repro works reliably for me:
removed "VWR-8982" from LLID field, this isn't an internal ID...?
undo, I'll leave it alone...
I've tried the fix as noted here, it works. The coordinates appear correctly.
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? This problem was resolved when LL switched llMapDestination's behavior into opening a parcel information window instead of the map directly.
Unfortunately, due to user demand it was shifted back to opening a map, and the bug has returned with that code. I'm updating this to Major as it breaks huge amounts of Second Life content. Although there is a workaround (call llMapDestination() twice with the same coordinates), it's a hack at best and sometimes results in the user getting hit with a second map after reaching their destination.
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. Upgrading to critical because (a) it is, and (b) it's so easy to fix that Linden Lab has no excuse for not doing so
I have found the cause might be the focus in the viewer.
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 Darling Brody. I seem to remember reading a while back, possibly during the big issue with llGetObjectDetails() being able to track people when teleporting, that the first stage of a teleport, the region handoff, teleports the user to the new sim in the same coordinates as in the previous sim, and then a second step moves them to the new coordinates.
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? With regards to the focus issue, it would be better to simply have the map not steal focus at all (as was mentioned in SVC-1038) for a number of reasons, than to have it focus on the "Teleport" button. As I mentioned in VWR-8485, it is generally bad coding procedure for any function to automatically redirect focus to a button that takes input on pressing Enter. While it may be slightly more efficient under certain circumstances, it creates real potential for problems if an item is clicked accidentally, or if there is a delay between clicking and having the map come up (perhaps due to lag) with the result that one accidentally hits the Enter key thinking it will input chat text and finds oneself teleported.
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. Is anyone still able to repro this? I've had no luck at all but i can't be sure if thats because its fixed or if its just not happening to me. I tried trying to steal focus before the map appeared and no luck so far and the first map of the session is working fine for me too.
Yes; this still continues to be a problem. It's still an intermittent problem but it does happy regularly. The "call it twice" kludge does seem to reliably work - however the kludge itself has an intermittent side effect of showing the map twice.
The problem with the field nomenclature is that JIRA was designed for normal software products where known reported bugs are not permitted to persist across many releases, and releases are required to fix most known bugs before going final.
SL is different. Well, if switching back to the behavior of popping up the parcel information window or landmark window or whatever the behavior was called,that was briefly introduced a few iterations ago, if that would fix this problem, then is that a viable option? I mean, if LL is having trouble figuring out where things are going wrong, then might switching back to that behavior, which worked reliably well, be an option? I know that there was quite a bit of opposition to that change when it was introduced, but if it does behave more reliably than the current behavior of llMapDestination(), then perhaps it is worth looking at?
Absolutely! if nothing else, the landmark code works, the llTeleportMap() code does not. So clearly there is a difference in the two functions, and the proper code can be gleaned by looking at the landmark source.
Probable cause: How about map lag? It is extremely likely that this is a latency issue that could be a result of everything from the toy database that SL uses to distributed data centers to network traffic load.
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. Now Angela, how is Oracle going to feel about you calling the DBMS they just bought a "toy database".
Well, I use mysql for many of my sites. However, they are not enterprise sites, so they do not need an enterprise (read, truly scalable) database. LOL
Hmm, two years for a trivial bug and you STILL haven't managed to fix it. I know it's trivial because this did not occur when we used landmark windows to teleport. So obviously the code is correct for landmarks, and mangled for manual map usage and/or llMapDestination(). Solution? Copy the code that works. Wake up and do your job, Lindens.
I agree. This is rediculous that I have to put hacks in my tour HUD to work around this bug that EVERYONE and I mean EVERYONE must have run into at some point or other. If you EVER teleport via some gadget that pops up a map, you will get hit by this and get frustrated, most users probably think it's the innocent scripter that's messing up. Ugh!! FIX THIS!
What I dont understand is they added a throttle tot he llMapDestination to stop map bombing, so they had their head under the hood of this code!
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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Critical
llMapDestination (and possibly SLURLs) sometimes fail to use the target vector data
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:
{ llSetText("KDC Main Shop", <1.0, 1.0, 1.0>, 1.0); }default
{
state_entry()
touch_start(integer total_number)
{ llMapDestination( "dead realm", <128, 128, 602>, <0,0,0>); }}
this always fails on first activation:
{ llSetText("Fetish Box", <1.0, 1.0, 1.0>, 1.0); }default
{
state_entry()
touch_start(integer total_number)
{ llMapDestination( "Ekota", <110, 83, 102>, <0,0,0>); }}
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.