much frustration with dataserver and sensor

What I am trying to do as what started as an excercise in understanding LSL better has turned to an excercise in just how frustrated I can get :|

I am trying to learn dataserver + sensor events in the hope of building a multi tool which does exactly what I want no more no less...

Is there a trick to having a sensor find say 5 avatars, stepping through each one at a time and listing DATA_BORN and DATA_PAYINFO or any other combination of two DATA_blah items?

I have tried having sensor call a function getData(llDetectedKey(i)), I have tried having sensor call call llRequestAgentData for both items, having sensor call llRequestAgentData for the first item, and dataserver call the second item... etc.

Everything I try either returns things out of order, or just for the first AV, etc.

I am sure it is some little gotcha that I am missing

Any suggestions would be greatly appreciated!!

Dataserver events will return when/if they feel like it, i.e. you cannot count on the ordering or even if you will get a result.

Because of this it is usual to store the request ID and check this against the dataserver event query id to ensure you have the right data.

Without seeing your code its difficult to say exactly what you are doing wrong but you will need to track the ID's of the requests and match them up with the replies. You cannot combine requests so DATA_BORN will be one request and DATA_PAYINFO another.

The dataserver Event can be a tricky little deevil.

For example, requests to the dataserver may not arrive in the same sequence they are made, and they may not arrive in a timely manner. So, the trick is to loop through the dataserver requests using the dataserver Event itself to control the loop.

This is kinda rough but I hope it gives you the general idea:

    dataserver(key query_id, string data)
    {
        
        if (query_id == QueryId); // I may have other types of request so make sure this is the correct one
        {
            //process data
            
            if (i < llGetListLength(AVKeyList)) // now query the next agent in the AVKeyList
            {
                ++i;
                QueryId = key llRequestAgentData(llList2Key(AVKeyList, i), DATA_BORN);
            }
            else // hey, we're finished
        }
    }

    sensor(integer total_number)
    {
        for(i = 0; i < total_number; i++)
        {
            // make a list of all the keys
            AVKeyList += llDetectedKey(i);
        }

        // now process just the *first* agent in the AVKeyList
        i = 0;
        QueryId = llRequestAgentData(llList2Key(AVKeyList, i), DATA_BORN);

    }

The situation is made even worse when the grid is lagging. You may not get a response at all, or it may take minutes to get your data. My general recommendation is to try and get all of one step of the process completed, then move on to doing the next, giving the user status messages in-between. IE, get the scan done, and then do the llRequestAgentData calls, pretty much like Pale suggested. I would also block further scans until the entire process is done, to prevent messing up the process in case of grid/database lag.

LOL now I find out that "event driven" means "random actions will be taken on your behalf when and if the machine feels like it"

Thank you all for the help... the solution while not pretty and not what I intended...

sensor event creates a list of keys detected, calls the first llRequestAgentDate which makes matching lists for what ever other information I want.

... and it did give me a good app to play around with lag reduction and so forth (not quite a silver lining but not dank either!)

Just like in reality. People are event driven, and sometimes they walk into each other "by accident" because they don't process the events in the right order, or there is some sort of delay while they process some other event.

This issue is common to *all* distributed systems, not just SL.