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.

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

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;
}

is this an official function, that's not likely to disappear any time soon?

cheers,
Koz Farina

So, this ability to use the SLPoint_to_XYPoint function isn't going away then?

Thanks Yoz,
Koz

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'.

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 -->

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.

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.

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.