HG Status Checker script – Hypergrid Business

Sick and tired of the inaccurate statistics in Hypergrid Business every month?

You know who you are. You’re sure you can do better.

Well, I’m going to help you out.

We’re running far behind on updating the Hyperica directory and I was thinking of automating some of the tasks, such as checking whether regions were up or not, and looking up their hypergrid addresses.

Well, I finally wrote a script to do just that, and am sharing it with you. Here it is: HG Status Checker

The way it works is that you put a list of hypergrid destinations into a notecard titled “Destinations.” One hypergrid address per line.

Like this:

The results come back in a new notecard, called “Results,” showing the hypergrid address, its status — up or unknown — and its x-coordinate and its y-coordinates, on separate lines.

Like this:

The reason this script works is that a script running on one region can request the status and coordinates of a different region — even if they are on different grids — as long as both your grid and the other grid are on the hypergrid.

So you won’t be able to use this script to check the status of regions on closed grids like InWorldz or 3rd Rock Grid. But you can use it to keep your hypergates up-to-date.

What I plan to do is to create an automated script that runs constantly, checking every region in the Hyperica directory at least once a day — maybe more often if grid owners don’t complain — then storing the results in an online database that anyone can access.

I plan to save such info as the last time the destination was checked, the last time it was up, and its percentage uptime over, say, the past month.

I’ll post the results here, so we’re not all querying the same OpenSim grids all at the same time. Instead, we can all query the same Google database. Google can take it.

If you want to disassemble my script and make it your own, here are the key parts.

Getting the region status

To find out whether a region is up or not is done in two parts. First, you send a message to the other region saying, “Hey, what’s your status?” Then you sit and wait for the response.

To send the message out, you use the llRequestSimulatorData command:

StatusQuery = llRequestSimulatorData(region, DATA_SIM_STATUS);

The lowercase region is a string variable holding the hypergrid address of your region — or, if you region is on the same grid, just the region name.

StatusQuery is a key variable. If you send out several different requests to different regions, this variable lets you keep track of the different requests. This isn’t so much of an issue in this particular script, though, since the way I set it up is I’m sending out one request at a time and waiting for it to be answered before I go on to the next one.

To get the data back takes a bit more code:

dataserver(key queryId, string data) {

if (queryId == StatusQuery) {
StatusQuery = "";
status = data; Â 
}

}

Here, the data is being sent back inside the data variable. Â If the status is “unknown” I go on to the next destination. If the status is “up,” I sent out a request for the region coordinates. You’d be surprised to find out how much regions move around.

Getting the region coordinates

Knowing the right coordinates is important in these medieval times, when the 4096 bug runs rampant across the hypergrid.

Someday, we won’t care about it anymore, and will be able to freely jump from any corner of the metaverse to any other corner. But, until then, here’s the command you use:

PosQuery = llRequestSimulatorData(region, DATA_SIM_POS);

Yes, it’s the same as the first command, except with a different flag –Â DATA_SIM_POS.

Getting the region coordinates out is a little trickier because the results come back in a weird format. Fortunately for you, after trial and error, I’ve been able to get real numbers out. Here’s the code:

dataserver(key queryId, string data) {

 if (queryId == PosQuery) {

 PosQuery = "";
 list location = llParseString2List(data,[",", "<",">"],[" "]);
 xpos = (string) (llList2Integer(location,0)/256);
 ypos = (string) (llList2Integer(location,1)/256);

Here, xpos and ypos are both string variables. They don’t have to be — you can keep them as integers if you plan to do any calculating with them.

The rest of my script is just going through the Destinations notecard, line by line, and saving the results into a new notecard.

Since the script has to wait after each information request, it can take time for it to go through the entire list. You might want to include a status update, such as llOwnerSay ( “Checking destination ” + (string)n + ” Â of ” + (string)NumLines). Just so that you know the script is still running.

Or you could send the requests all at once, and then figure out which response goes with which request.

Here’s the download link to my script again:Â HG Status Checker

I found theÂ instructions for how to useÂ llRequestSimulatorData on the LSL wiki.

To the extent that any of parts of this script can be considered an original creation, I hearby release it under the CCO “public domain” license, no rights reserved, do with it what you will.