|
History
| Log In
|
|
|
|
|
|
Changed priority to match internal issue's after triage.
Hi.
Just trying to re-address this issue again - ie: being able to place a map next to a postcard sent via the client. I think that having additional Global Coordinates being sent along with the existing Region Name and RegionXY coordinates would be great. Currently, we still have no way of extrapolating global coordinates from a postcard email in order to pinpoint a map location, as XYPoint is used now since SLPoint no longer works. Love to get this fixed asap, as this is now really holding up some important and cool iteration I've been intending to do over on bloghud.com for a while now. tbanks. Koz Farina Personally I use a PHP function much like the following:
function SLPoint_to_XYPoint($region,$x,$y) { $url = "https://cap.secondlife.com/cap/0/d661249b-2b5a-4436-966a-3d3b8d7a574f?var=a&sim_name=".urlencode($region); $options = array( CURLOPT_RETURNTRANSFER => true, // return web page CURLOPT_HEADER => false, // don't return headers CURLOPT_FOLLOWLOCATION => true, // follow redirects CURLOPT_ENCODING => "", // handle all encodings CURLOPT_USERAGENT => "spider", // who am i CURLOPT_AUTOREFERER => true, // set referer on redirect CURLOPT_CONNECTTIMEOUT => 120, // timeout on connect CURLOPT_TIMEOUT => 120, // timeout on response CURLOPT_MAXREDIRS => 10, // stop after 10 redirects ); $ch = curl_init( $url ); curl_setopt_array( $ch, $options ); $content = curl_exec( $ch ); $err = curl_errno( $ch ); $errmsg = curl_error( $ch ); $header = curl_getinfo( $ch ); curl_close( $ch ); $content = substr($content,8,strlen($content)-9); $content = str_replace("'", '"', $content); $coord = json_decode($page,TRUE); $coord['x'] = $coord['x'] + floatval($x) / 256.0; $coord['y'] = $coord['y'] + floatval($y) / 256.0; return $coord; } crikey! that's a bit useful! :)
thanks for that! is this an official function, that's not likely to disappear any time soon? ;) cheers, Koz Farina A late response, but yes, this is an official function which our Javascript webmap implementation uses. It's not currently documented, and we'll be fixing that soon.
I was ready to close this "Won't Finish" (due to the alternative solution above) but it looks like the postcard code is about to get some attention for a different reason so I'm trying to slip this in at the same time by making it really trivial to do.
Current proposal: a comment in the HTML that contains the grid x+y of the region. Koz, how does that sound? Having the HTML comment sounds good too. it will make other people's lives easier too.
So, this ability to use the SLPoint_to_XYPoint function isn't going away then? ;) Thanks Yoz, Koz ;) Postcard template now fixed internally. The HTML now includes global_x, global_y and agent_id of the sender.
(Also fixed: A problem where region names in Slurl URLs weren't being escaped properly) Yep, Koz - while it's possible that the URL for the coordinate lookup service might change, this is going to be a permanent service to both support our own webmap and others'. As of the 1.19.1 server release, you can stick a fork in this fix, because it's DONE.
Sent postcards are now using this format: <!-- BEGIN POSTCARD DETAILS agent_id=[UUID] username="Firstname Lastname" region_id=[UUID] sim_name="[name]" global_x=[int] global_y=[int] local_x=[int] local_y=[int] local_z=[int] END POSTCARD DETAILS --> Finally, an important note for all those to whom the above format info is useful:
At present, the postcard format continues to be NOT OFFICIALLY SUPPORTED. In other words, we make no guarantees about all postcards being in this format, nor about the format never changing. If you write code that parses SL postcards, please bear this in mind with regard to the assumptions your code makes, and the way it handles parsing failures. I can't even begin to express how frustrating and annoying it is for you to change a format that has been constant for 3 years, with no regards for how it would affect any of the sites relying on postcard processing. You could have easily added a second set of comments instead of changing the format of the existing comments, but instead, you chose to break existing functionality with no warning at the whim of one person requesting it.
Yoz, I really do hate to say this, but that is a very poor answer in my opinion. I do not use the postcard format myself but really - it has been consistent all this time, it is _very_ well known that it is used by many third party sites, offering enormous amounts of free benefit to Linden Lab, and "oh well it isn't official you take your chances" is just not good enough.
All that anybody wants is just that, if there is a change to be made, it is announced _before it happens_, and _what the change is_ is documented. That isn't too much to ask, is it? "We are going to change function X on date Y so that it does Z now"? This sort of thing has improved dramatically over the past year, but this is a move back to bad old days. Okay, time for a mea culpa, because - as you say - this should have been handled much better.
Cristiano: You're right, there should have been advance public notice of the change. The ecosystem of resident-run services is vital to SL, and this lack of planning around that failed all of us. In the future, I'll try to ensure that I notify residents accordingly when a change that I'm involved with may cause breakage. Please accept my apologies for the problems that this caused your service. |
||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Low
Postcards need to send Global Coordinates since removal of SLPoint() from the SL Map API
Despite how it appeared, the disabling of the old web map API wasn't directly related to the release of the new one. Both are meant to be running in parallel for a while, especially since there are many devs (such as yourself) using the old one. The problem was that generating the huge list of map data that was in the old Javascript code was causing such a database hit that we disabled it in order to find a better solution. Within the next couple of days, the old map API will be working again with much better caching, and so your existing code should be fine.
If putting coordinate data in the postcards themselves would still be a much better solution, let me know and I'll keep chasing that up. In the meantime, I want to get more developer input about the new map API and what we can do to improve it, especially with an view to phasing out the old one without leaving anyone high and dry. SLPoint() is an obvious next step.