Determining if a region name is valid?

Is there a way to determine whether a not a particular string represents a valid region name that currently exists in SL? I haven't been able to find such a thing.

Maybe this will do what you want:

http://wiki.secondlife.com/wiki/LlRequestSimulatorData

Possibly. But it causes the script to sleep for a second every time it is used. I have 100 passes I have to go thru. I was hoping for something that didn't cause this kind of delay.

Well... Not knowing exactly where the dataset comes from that you are testing, I can suggest a couple of approaches.

If it truly is a dynamic list of 100 names that changes each time you have to perform this test, your best appropach is to have a whole slew of helper scripts that you access via a link message. Ten scripts will get you approximately 10 answers per second, rather than just 1.

If, on the other hand, its a rather static list, then simply pay the 100 second penalty once up front, and save the result in a list.

- Ace

I'm reading data from a note card that contains a region name and coordinates on each line. Besides reading each line (0.1 sec) I'm doing a bunch of other processing to ensure that the user has entered the data in the correct form. So I'm already up there with processing 100 lines. Any significant further delay would probably just be too painful for the user to wait for the object to configure itself. Within the other checking, I was hoping to include a quick check to make sure that the user had entered a valid region name. I guess there is nothing easy. I'll check this out to see how much time it adds to the process.

https://wiki.secondlife.com/wiki/Category:LSL_Parcel might help not sure but parcel details might work... not sure what it returns on invalid input but it has no delay

Ok I tried this out using llRequestSimulatorData as suggested, but I'm getting weird results.

After reading the notecard I end up with a list of region names with about 40 names called dest.
Then I have a function:

CheckRegionNames(list dest)
{
    integer j;
    integer nd = llGetListLength(dest);
    for (j=0;j<nd;j++)
    {
//        llOwnerSay(llList2String(dest,j));
        g_sim_qry = llRequestSimulatorData(llList2String(dest,j), DATA_SIM_STATUS);
    }
}

Then the dataserver event:

dataserver(key requested, string data)
    {
        if (requested == g_sim_qry)
        {
            g_sim_qry = null_key;
            llOwnerSay(data);
        }
    }

When I have it llOwnerSay the names from CheckRegionNames, I can see that it is cycling through all the names.

Now I would expect the dataserver event to be triggered each time, but it isn't. It only gets triggered once, returning the value "up". Even if one of the names is "***", an obviously invalid sim name, it never returns "unknown"

Any suggestions on what is wrong here?

The event Queue can only hold so many events before it starts to lose them (I see 64 mentioned in a wiki). So reading notecards, or triggering other dataserver events, from within a loop, could cause some of those to be lost.

Rather than cycling in a for loop, it would be better to signal one event from, say, the state_entry of state. Then in the dataserver event, process that event, and while still in the dataserver event, trigger the next one.

So for reading notecards, you 'd do a read from the state_entry. In dataserver you'd process what was read (assuming it wasn't eof), and then do another read. Which in turns triggers dataserver again, etc. And eof, change state.

For your llRequestSimulatorData, you could call llRequestSimulatorData from state_entry, then in dataserver event, check its validity, then call the next llRequestSimulatorData from the end of the dataserver event (and change states at eol).

Or you can get fancy and combine both the notecard read and the llRequestSimulatorData processed in the same state from the same dataserver event, checking some variable to see which one you're processing at the time. But that's more confusing, and I'd go with multiple states.

RJ You are correct. I tried it that way and it works.

I ended up abandoning the whole endeavor however. If I was going to take a 1 sec penalty justto look up a region name, I decided it was actually better to use a landmark approach rather than a notecard approach to this. Using llRequestInventoryData I can avoid having to check for the region name at all. Since I'm just feeding the info into llMapDestination, that will work just as well and will avoid all the checking to make sure the user entered the destination correctly.

Thanks for the input. It helped me think through this.