|
|
|
added llMapDestination to title
Thanks for the link to this from
Any new news on this bug?
Given that the 1.20 client is now the main client and everyone can now make use of the new 4096 build height you'd think that LL would get this bug fixed. Makes the new build height kinda pointless if you can't build a skybox say up at 3000m and not be able to teleport where using a scripted teleporter from another region. I think the assigned priority of this bug is way too low... personally... this is a show-stopper...
Over half the builds I visit every day are around 3000m or higher... and I cannot reach them without manually setting the teleport coordinates. This also causes a lot of lost visitation... as very few people know the proper Z coordinate for the various builds. I agree, Lex. This incorrect cutoff breaks a lot of things, including simple landmarks. Ironically, it doesn't affect SLURLs or teleporting itself. You can go to 128,128,3000 by editing the coordinates shown on the map, so this would appear to be a problem in the viewer itself.
I have increased the priority of this to Major (this definitely qualifies as "Major loss or impairment of function"). Personally I believe it's Critical as this severely breaks functionality of llMapDestination with systems that need to teleport you higher than 1000. This maximum cap is absolutely ridiculous.
We desperately need this cap removed now! I have to agree on how important this issue is. I have a small SL business with a few hundred loyal customers who now have content that is only partially functional.
Question to all of you - if this is a client side issue, is there a 3rd party client out there that works that we can refer our customers to until this issue is resolved? I have to agree, this is an issue for our staff accessing sky-boxes etc. that's causing us issues. First time I've been moved to post on a issue like this, but this is a seemingly small thing affecting us in a BIG way. I gottta stick my hand up here and ask for some attention to this. Thanks
 Voted for. There really is no good reason for limiting the teleport to 1000m, whether it's the map you use to teleport, or not..
My understanding is that this is a server-side cap that has been put in-place. People using other popular 3rd-party client have reported that they are just as unable to reach our space builds as people using the 1.20 release client.
This cap was put in after Havok 4 was moved to the main grid, and they introduced the new land parcel window in the RC branch. After many people complained about the new functionality of llMapDestination brining up the land parcel window instead of the map (which I actually preferred)... we got the old map, with the old coordinate bug (http://jira.secondlife.com/browse/VWR-2060 I'm linking this to VWR-2060 as they are somewhat related and we need both fixed... we're losing too many customers and clients from these two bugs. Voted on this as well, there is simply no justification for this cap. anyone crying greifablity related to this clearly isnt realizing that unlike an old style (pre H4 ) orbit, the player teleported has a choice here and acess(via the popup map) to all information related to it. Please fix this LL
I'm with Sen and Chehyr (as usual) on this issue. I sell products through Sen's company and I, obviously, want her systems to be well received and work well. I got a friend of mine to buy one of her console rooms just last night, and after he bought it and I was helping him set it up, he kept saying that it really freakin sucked that he couldn't move it above, say 980m, to be sure he could actually get INTO it... he wanted privacy, and the higher was better. I am also partial to Stargates, and that limit effects them too. When other friends of mine were building the Utopia Club, which had to have access to TARDISes and a Stargate, including rental TARDISes, it was a pain to make sure EVERYTHING was under 1000m. So, basiscally, most of us SciFi fans out there who use these products can't use the nice, dark, "spacelike" areas of the grid, cause our extrasim teleportation systems won't go up there.
So, FIX IT. This seems like a fairly basic error. Now that people are making content at higher levels (and space like areas are good for scifi content) they need to be able to use the popular tp's to get there. I used both Sen's and Cheshyr's products and would love to have them at the new higher levels. Please prioritise it.
It's a simple one-line fix, too.
In the viewer source, llFloaterWorldMap.cpp, in the method LLFloaterWorldMap::trackURL. The third line in the method says z_coord = llclamp(z_coord, 0, 1000); Zing. There's the culprit. z_coord gets clamped between 0 and 1000. This is a fix that can be done in a matter of a minute. I'm not at home right now, but perhaps I'll just slap together a tiny patch for 1.20.15 later and submit it here. If this even warrants a full .patch file I'm glad to see it's such a simple fix. Now let's see if Linden Lab wakes up and applies it. I suspect that they'll instead ignore your correction, as they did with all of Nicholaz Beresford's wonderful bug fixes. Someone at Linden Lab thinks that their underpaid, collage student interns have more skill and knowledge than those of us with 30+ years programming experience and the time, resources, and passion to make Second Life the polished product it deserves to be.
I'm sad to say that client 1.21.0 (94415) still doesn't have this simple patch. It might not be proper protocol, but I've IM'd WorkingOnIt Linden directly to try and get some attention.
Given that this and the rest of the fixes for build height are so simple, they really should do a final re-build of 1.19 to let people use the old viewer in skyboxes as well... or else withdraw the old viewer and direct people to Nicholaz' viewer instead.
Another RC has been released, 1.21.1 and surprise surprise, this STILL hasn't been fixed >.<
That is because fixing problems requires caring. I care about my customers, listen to them, and update products accordingly. Linden Lab's actions make it very clear that nobody there cares about anything unless it has an IBM contract attached.
i posted a patch file, this issue turns using the stargate to get into midway into free skydiving lessons if u forget to alter the z coordinate.
Now we have the .patch file done to fix this bug maybe this will get resolved sooner, provided LL actually bother to use the patch. All they need to do is alter 4 measly little characters in one line of code to fix this.
Hopefully this will make it into the next RC update but don't hold your breath. Hi All
I completely agree, this has to be fixed fast. I work around until then can be that you assign a teleport point to your land. that works and neutralizes the 1000 m. So you may use that solution meanwhile, However, it is very complicated and you need the rights to do so. But maybe this tip helps some desperated people a bit. @Dania, using the landing point teleport routing does overcome the 1000m problem provided provided the person is teleporting from another region. If they're in the same region, they'll end up wherever the map indicates. What one could do is put a platform at 1000m with a teleport pad and note telling the guest they need to manually teleport the rest of the way up due to Linden's failure to fix simple bugs.
Aye, that works albeit poorly. Since "WorkingOnIt Linden" doesn't really exist, and is Linden Lab's equivalent of "shut up and leave us alone", I doubt we'll see any real action on this matter.
Switched to show stopper. As people can build above 1000, it means any map teleporters are BROKEN above 1000m. As the guidelines say a showstopper breaks contents I have raised the priority.
Stargates are very widly used and none of them are able to operate above 1000m. I am swamped with complaints and my Stargate is a lot newer than the other ones, who's creaters must be under sege with unhappy people. Darling Brody Ok, I want to know that the hell is going on at LL. They have released a new RC client today, RC4 and this bug STILL hasn't been fixed.
Come on LL, how hard if is for you to change one bloody line of code? Hell, we even showed you how to fix it. Do we need to dumb it down any more for you? grumbles Voted on. Kind of silly to have the ability to build at 4k, but not to TP there. Personally, I usually live around 3500, and it's a pain (albeit not crippling) to have to kludge my way home. Wouldn't call this a showstopper, but it ought to get fixed ASAP. And, as has been pointed out in this here thread, the fix is right there in black and white. C'mon guys, postpone that trip to the coffee machine for 5 minutes and do this.
I'm very, very disappointed at both the lack of action and the lack of feedback on this bug from Linden Labs. Every time a new Release Candidate is issued it's the first thing I check out. We've had several releases now and far from there being a fix, there isn't even a comment on the bug letting us know what is going on. We, the customers and content providers, deserve better. Far better.
I understand your frustration, Darling Brody - this is a very annoying problem and affects many products, not just Stargates - however please do not abuse the Showstopper priority. It is not a way to get the Linden's attention on a matter. Showstopper is described as:
"ONLY the most severe, confirmed issues which demand immediate attention from Linden Lab. For example, inability for many Residents to login. IMPORTANT: Abusing this setting will cause revocation of Issue Tracker access. If in doubt, mark "Critical" instead." This issue, although severe for our situation, is not a showstopper - it does not prevent us from using Second Life itself. Therefore I am reverting this back to Critical. It's not worth risking having your Issue Tracker access revoked and/or this issue being closed. This is a very important issue. Resolved with the suggested clamp of 4096 meters.
I agree that the number is a bit arbitrary and maybe this should be unlimited, but I wanted to get a fix in sooner rather than later, and it would have taken more time and effort to discover whether an unlimited height might cause new problems whereas the suggested change seemed safe enough. The fix is on track for version 1.23 but is easy and important enough that we might be able to slip it into 1.22 even though that deadline has officially passed. We know that this is important to you so please have patience and we'll get it out as quickly as we practically can. Thanks to Chalice for pinpointing the change needed and to Peter for the patch. Hey Coco, thanks for getting this sorted out for us. Nice to know that at least one person at LL took notice to this issue. Look forward to seeing this fixed.
I still don't see this in the fixed list in RC 1.22: http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release_Candidate/1.22
This will definitely be put in by the time 1.22 goes to main release, yes? Still not seen any progress on this? Been a good while since a fix was mentioned. Been pending for a while too?
@Coco Linden
2 months have passed since you said it was going to be fixed. Several RC clients have come out too. Did you forget to deploy the fix ? Coco is not even on the watch list! I'm going to remove the fix-pending status. I think someone has lost the fix along the way. Darling Brody Fix pending was announced 2 months ago. The RC has been updated several times as has the beta grid. Somthing has gone wrong between the fix being found and the fix being applied.
Given how long we have been able to build at 4096m, it is shamefull that this has taken so long. > http://svn.secondlife.com/trac/linden/browser/trunk/indra/newview/llfloaterworldmap.cpp#L746
Observe the top line. No change in the viewer trunk branch, nor in the 1.22 branch. There is bugfixing and testing going on with the 1.22 RCs anyways. This is not a feature request, it's a bug. Spend the two minutes to put it in and testing it already. Two minutes. This was filed in May for chrissakes. IM Sent In world: Coco, I am forming a linch mob and we are hunting you down. http://jira.secondlife.com/browse/VWR-7331
Why do you attack me when I'm the one Linden who decided to make something happen on this one? If anything, you should be attacking everyone but me. I understand that you're really passionate about the viewer, but we are too which is why this hurts me. I was very clear in my resolution comments that the fix is on track for version 1.23 which is why you won't see the change in the 1.22 branch. I'm re-marking it as fixed internally because it can't be any more fixed than it already is, but know that this bug won't be closed until it ships. Complaining won't make it ship sooner though your votes do make it more likely to be cherry-picked into the 1.22 RC process. As simple as it appears to be to "just change a single number", in practice it's not nearly so simple. Even the most innocent changes can have unintended consequences, and even though this one is simple, it's far from innocent. For instance, might this change simplify some nasty form of griefing? Probably not but we're not 100% sure and that's one reason that people have been reluctant to change this. I had to get enough people to agree to accept the risk of this change and that's a human problem and not just a technical one. Even at a pure technical level, we can't just stick anything in right before shipping to millions of people. That would be be incredibly destabilizing and you definitely don't want that. You want this product to be all things to all people, and you want stability at the same time as we develop madly on all fronts. We therefore have to funnel all of our collective works into a single code base in an orderly fashion and that implies release cycles that are longer than any of us would like.
I don't know that anyone is attacking you. Well, except Darling but she's mostly harmless. You're just in the unfortunate position of front man for this particular issue.
Re your statements, I left the public sector for precisely that reason. I had a web developer job for the state government. Paid well, the office was in a nice mall, but I could not tolerate having to get minor changes approved by a committee who knew absolutely nothing about the product. At one point some pigheaded beaurocrat tried to tell me to make the website readable by the blind. Normally I wouldn't argue, but we're talking about the Registry of Motor Vehicles. No blind person has any business renewing their driver's license, online or elsewhere... The fact is, this is a very simple change, and was a bug in the first place. It isn't debatable and has nothing to do with griefers. Your people failed to update teleport code when they increased build limits. There is nothing to discuss. It was a huge mistake on Linden Lab's part and one that can and should have been fixed months ago when certain other problems with the new build height were resolved. It is a very minor bug of course. There are far more serious problems that should be #1 priority. For those who cannot wait for this fix, I've already posted the solution. Use CoolViewer or any of the other third-party clients that fixed this bug months ago. @Coco Linden
Listen here Coco. There is one thing you should bloody well know, and it is about time you became away of it.... I am very sorry for making you feel bad. It was not my intention to upset you, I just wanted to get a reaction as I am too stupid to read the version number correctly ,and I throught that it had been forgotten. At least I was not the only stupid one, everyone else seems to have missed it too. Sending you a lunch in-world right now. Darling Brody. Being too stupid to read is no excuse for attacking others.
I can understand frustration and being cynical etc., I know I can be. But a linch mob?.. hunting you down? IMO you should have been banned from posting on JIRA for that one, darling. "... but is easy and important enough that we might be able to slip it into 1.22 even though that deadline has officially passed."
Seems plain to me that Coco raised hopes of this being implemented sooner, and that was the last official information we had. This issue is seven months old! I opened a trouble ticket two weeks ago about an issue stopping me from logging in and it hasn't been answered yet, how am I supposed to administer the Island that I pay $400USD/mo for? Yet another example of the utterly lack lustre response to problems that is driving people away from SL. I rent a dedicated web server for around $175USD/mo and if I have an issue with that, tickets are answered in under 30 minutes, LL support is shocking in the extreme. Ditto to Cheshyr Pontchartrain's comments and as for the absurdity of it being a potential griefing issue, have you not considered how griefers can exploit this bug for lulz by sending innocent noobs valid landmarks that send them to empty space at 1000m, and watching in sadistic glee as they helplessly plunge to the ground in abject terror?
@Be Holder
Hay Beholder, what is your excuse for attacking others? Your only comment in this JIRA is to attach me. You are the one who needs to be removed from the JIRA. Your only contribution here is not helpfull. And while I am talking about your contributions, what makes you think you have the right to refuse my appology on Coco's behalf? What has it got to do with you? Do you normaly run around refusing appologies on behalf of other people in the real world, or is this a special kind of arrogance you save for strangers on the internet? markbyron falta : "...and watching in sadistic glee as they helplessly plunge to the ground in abject terror" Press the Fly button !!! Darling (pre-morning-coffee) Brody Ok, Darling and Beholder - stop bickering now! If this thread dissolves into a drama session, this issue will never get fixed! Take it inworld.
This is a serious issue affecting many SL businesses, residents, and tech all over the grid. It is costing me and my business partners money every day, as my heavily scripted RP TARDIS homes that depend on llMapDestination are being ordered removed by many landlords that now insist on all skyboxes to be above 1 or 2K. Coco, I work in the public sector, in a job where I get the public ire routinely. So understand that what I am about to say is not an attack, but some helpful advice. We don't care if your feelings are hurt. Now, I do care if the real human being behind the keyboard of Coco Linden gets hurt. Don't get me wrong. But Coco Linden is a business representative, not a "real" person. We pay money to your company. You... need to grin and bear it. If enough people get mad enough about something - you're looking for a new job. And frankly, we're paying money right now for something we're not getting. Customer is always right, remember? I'm losing money every day because of this. Considering the whole world is losing money in droves, it makes me furious when something this easily fixed is costing me. And yeah, some of us may seem unreasonable. But when LL pushes features to the top of the release priority with questionable stability, feasibility, and desirability on a regular basis, I refuse to believe that it's THAT hard to get a simple bug fix in. I smell really bad politics here. This is months old. We all know that you are working for us the best you can. But you also need to be sure to pass on the message to those who need to know that this whole deal is beyond despicable business. It's just inexcusable. And next time someone gives you a totally lame excuse like griefing to pass on, make them post it themselves so you don't have to take the well deserved heat for that. Now, I'm going to try and round up another 100 votes. It better be for something. One line fix, and I got bit by this bug yesterday on my own land and it was an unpleasant experience.
Please fix! My Hyperloom systems also use this call for TP and of course, we can't go over 1000m as a result. Please fix as this makes the entire line of several large businesses USELESS at heights over 1000m. If we can build up there we should be able to Teleport there.
Ok folks I posted my votes on this issue a LONG time ago. There are MANY scripted objects in world that are presently partially disfunctional because of this particular bug. I do see that its now labeled as 'Fix Pending' and labeled as 'Critical' so I'm confident that it
@Coco Linden - perhaps an estimated 'worst case' time line? @Everyone else - CHILL guys! I've coded myself for a LONG time and know better than most that a single change can affect all kinds of subsystems on a large build. People are still ranting about this in some of my groups in world citing 'dirty politics' and other spurious reasons for the change not being in place yet. YES I know it affects many businesses that want to take advantage of the 4096 build caps. I also know that it affects even MY business ( two of my best selling products are broken right now ). Frankly I'd rather it be done properly however, instead of rushed to the gate only to break something else (as far too often does happen). The only thing we need to know Got my vote. By the way, ever heard of symbolic constants? If this line had involved a 'MAX_SCRIPT_TELEPORT_HEIGHT' or something, catching this bug might have happened sooner and might have been easier to pass through the red tape department.
 I understand what you're saying Traven. I've been coding on and off for 15 years now, and I understand how one tiny thing can affect tons of other things.
But this WAS fixed. A while ago, an RC client had the TP height unlimited. It was implemented a little odd (LM window instead of a world map screen) so some residents objected. Instead of altering the implementation in the next RC - it was just gone. Period. No explanation to the RC testers, nothing. Then when it was discovered that a simple one line fix would do it, pretty much every 3rd party client implemented it. Again, no adverse issues. Over the course of a few months, this fix has been tested by thousands of residents, either in a LL RC or a 3rd party client. No functional issues were mentioned by a single resident. That leaves only a few options for why this isn't fixed. LL doesn't care, or there are other forces at work. I don't like either option, but I'd rather a conspiracy than they just don't care. Of course, it could be technical, but some of the 3rd party clients are written by people just as, or more, talented than LL's coders. You'd think someone would have found at least ONE problem. As a paying resident since the first half of 2004, I am adding my vote of support and asking this be resolved as quickly as possible.
@Cheshyr: My griefing reference was just an example to point out that there are considerations other than technical that need to be considered with anything like this. There are other non-technical things to consider as well, and in all probability this fix will not enable new problems. My point was only to address the claim that this is a no-brainer.
@Zimzim: I did intend to give some hope of slipping this into 1.22 but I can't promise anything. @markbyron: No, I hadn't considered how the current problem could be used for griefing. One really good thing about the alternative viewers based on the open source is that they give us evidence of when a change like this is likely to be safe. @Traven: Thanks so much for your words of reason and understanding. I'm not in a position to say when other than to say 1.22 is possible though it would require an exception to our QA process, and that I feel very confident about 1.23 as the worst case and expect I'll be able to say that definitively in a day or so. @Sen: About seeing the fix briefly which also involved going through the LM window (which I personally preferred) instead of the main map: I don't know but this may have been the way that the fix got lost in the first place: People complained about the UI change which was then rolled back quickly by bypassing the normal QA process, bringing with it a roll-back of the height fix. I don't know if that was the case but it easily could have been and this is just meant to show how circumventing safeguards to push something through faster can easily lead to more problems. @Hewee: Symbolic constants make for better coding practice but code simplicity is not the issue here. Technically it really is trivial. OTOH, if we had taken it one step further and turned it into a debugging variable, then at least a motivated resident would have been able to change their local version without requiring them to use a specially-built viewer. That would make for a nice patch if anyone feels motivated. @Ralf and everyone else who voted instead of complaining: Thank you. To everyone: Votes and constructive suggestions help but personal attacks are counterproductive. They drive away both residents and Lindens who would otherwise enjoy participating in the dialog. Yes, I represent the company here but I am also a real person with real feelings. We do care deeply, and there is no conspiracy. The unresponsiveness you feel from LL is largely a reflection how unpleasant it can be to get attacked for trying to help when we have other choices. In the end, neither residents nor Lindens can exist without the other. So please- Coco, I appreciate your comments and work on this bug, but there is a larger one still unassigned. VWR-2060 prevents llMapDestination() from working at all. It's been broken since before I joined SL in 2006, is flagged critical, and has nobody working on it. As long as VWR-2060 is broken, your own work on
Update: Hi, I'm the Release Manager on our upcoming Version 1.22 of the viewer. Thanks for the passionate discussion and votes on this issue.
As Coco mentioned above, she implemented the patch posted by Peter Lameth into an internal branch for testing. My job is to be cautious with all our bugfixes, and be sure we subject them to functional testing – both on their own, and interacting with the viewer's entire systems. So, the proposed fix for this issue ( Your comments on this issue have definitely asked that we accelerate this fix, though. I do recognize it is a painful bug! So, Coco & the Release Team have taken a special review if we can get this fix to you sooner. And you are right, this fix is small and isolated (it's just one place where the value gets clamped to 1000m.) And, it has been in use in other open source viewers. For that reason, we undertook the coordination to get this bugfix sooner, into Viewer 1.22, which is now almost ready from its Release Candidate cycle. You will soon see this fixed in 1.22 RC6, which is scheduled in the next 5-8 days. Of course, I can't always accelerate a fix without trusting it through our normal testing, even when it is desperately needed. But I appreciate this is a clear chance for us to make a small change with a big impact. Thanks for your patience on this one! Wootwoot!
Thanks Ramzi :> I know it probably is tricky to work outside the established protocol, thanks for doing so in this case tho. As for testing, I can assure you, if the clamped value indeed was merely changed from 1000 to 4096, it has been tested alot already in 3rd party viewers. For all intents and purposes, using the map to TP to a coordinate up to 4096 simply finally works. Thanks again! This is still an issue under:
You are at 293086.5, 280612.5, 101.9 in Garman located at sim7377.agni.lindenlab.com (8.10.146.124:12035) Test Script: default } Still positions map to 128, 128, 1000? Hi Cal, thanks for the comment. To clarify, this bug is not fixed for residents until the Release Candidate 1.22 RC6 is released.
EDIT: This RC6 viewer is now available at: http://secondlife.com/support/downloads.php#download-Testviewers
This will not be fixed for ALL residents until the final 1.22 viewer is released. To take advantage of the fix, residents will need to upgrade to version 1.22 at that time. So the fix is only "pending" at this time.... but IS coming soon! Is there any timetable on releasing the 1.22 viewer to the general public as a stable release as of this time?
Just asking because I'm curious as the last post on this issue was at the end of January. The timetable is "real soon now". Of course it's been that way for a while and still is.
We apologize for the delay we're really trying to get out a stable, final version as quickly as possible. verified working in the 1.23.4 release viewer if anyone cares...
don't suppose anyone knows if the 4096 ceiling agrees with the landmark ceiling? It worked in 1.22 as well, Void. Why are we digging up the dead?
And yes, landmarks work up to 4096. They have for quite awhile. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Critical
llMapDestination can't TP to Skybox over 1000 meters, which was made possible in 1.20
He's using a Mystitool HUD, which uses llMapDestination for teleports.
llMapDestination now seems to be capped at 1000m, possibly related to the fix for
VWR-6399Repro:
default
{ llMapDestination(llGetRegionName(), <128,128,3000>, <0,0,0>); }{
touch_start(integer total_number)
}
Observe: Map opens with coordinates 128, 128, 1000
Expected: Coordinates should be 128,128,3000