Problem with llGetParcelDetails

I'm trying to figure out what the top left and bottom right corners are of a parcel so I can figure out what the center point is. I'm using Builder's Skybox v2.0 and it's becoming annoying guessing incorrectly the center point of the plot, which is where I have to be to be within the 30m limit. I don't think this is the one with the override, but even if it does have an override, I want to be a good neighbor.

I intend to make this an attachment when its working, but right now its in a default object. When I touch the object everything up to the while loop works as expected (I get my current position, the numbers are cleaned up, the correct starting point is printed out. As it loops through, however, the name, desc and owner do not change when the parcel boundary is hit. What am I doing wrong?

default
{
    state_entry()
    {
        llOwnerSay( "Howdy!" );
        llSetText( "Touch Me To Get Parcel Details!", <0,0,1>, 1.0 );

        list lstDetails = [ PARCEL_DETAILS_NAME, PARCEL_DETAILS_DESC, PARCEL_DETAILS_OWNER ];

        list lstParcel  = llGetParcelDetails( <16,218,85>, lstDetails );

        string strName  = llList2String( lstParcel, 0 );
        string strDesc  = llList2String( lstParcel, 1 );
        string strOwner = llList2String( lstParcel, 2 );
        
        llOwnerSay( "Test: " + strName + " " + strDesc + " " + strOwner );
    }

    touch_start(integer total_number)
    {
        vector vecPosition = llGetPos();
        vecPosition.x = (float)((integer)vecPosition.x);
        vecPosition.y = (float)((integer)vecPosition.y);

        list lstDetails = [ PARCEL_DETAILS_NAME, PARCEL_DETAILS_DESC, PARCEL_DETAILS_OWNER ];

        list lstParcel  = llGetParcelDetails( vecPosition, lstDetails );

        string strName  = llList2String( lstParcel, 0 );
        string strDesc  = llList2String( lstParcel, 1 );
        string strOwner = llList2String( lstParcel, 2 );
        
        list lstCheckParcel;

        string strCheckName;
        string strCheckDesc;
        string strCheckOwner;

        // Find top left corner
        vector vecTopLeft = vecPosition;
        
        llOwnerSay( "starting point: " + (string)vecTopLeft );
        
        integer depth = 0;

        do { vecTopLeft.x--;
             vecTopLeft.y++;
             depth++;

             lstCheckParcel = llGetParcelDetails( vecTopLeft, lstDetails );

             strCheckName   = llList2String( lstCheckParcel, 0 );
             strCheckDesc   = llList2String( lstCheckParcel, 1 );
             strCheckOwner  = llList2Key( lstCheckParcel, 2 );
             
             llOwnerSay( (string)vecTopLeft + " | "
                       + strCheckName + " "
                       + strCheckDesc + " "
                       + strCheckOwner );

        } while ( strCheckName == strName
               && strCheckDesc == strDesc
               && strCheckOwner == strOwner
               && depth < 1000 );
                
        llOwnerSay( "Top Left Corner: " + (string)vecTopLeft );
    }
}

sounds like it might be running into the new workaround implemented for object names and description fields.... instead of having that data saved to those fields, instead have it output to llownersay, and see if you don't get the right data then

Added the following right after the llGetParcelDetails call in the loop:

llOwnerSay( llList2String( lstCheckParcel, 0 ) + " | "
 + llList2String( lstCheckParcel, 1 ) + " | "
 + llList2String( lstCheckParcel, 2 ) );

and the data is the same for both the direct call and the saved data.

so I'm confused, because the while looks ok, parcel details is not returning the right data, or the test against that data is failing?

I do see two major logic errors...

one, you seem to assume parcels are all square. I can tell you they aren't all even rectangular.

two, you seem to assume that your object is placed is such a way as to provide a direct diagonal to the corner, more likely you'd run up on an edge in one direction first, especially with the planned creation as an attachment. even assuming you looped through each axis seperately until maxed it wouldn't account for odd shapes like an I, or an S, or an inverted C.

Parcel details is returning the same data as the first call to llGetParcelDetails
so, it's not returning the correct data after it passes the border of the parcel.



I'm not, I'm just not handling that problem until I can get reliable data from the call.



Yeah, that was a "OMG" and look around to make sure no one saw the shirt tail sticking out my fly moment.

So now I'm just going for the smallest X.

It still is not working however.

If I put a position that I know is outside the parcel I'm currently in in the start state then the data is printed correctly, but when I touch the prim the correct information is printed out up to the border. However, once the border is passed, instead of the new parcel information being printed, the old parcel information continues to be printed and the conditon never becomes true.

Here's my updated script:

default
{
    state_entry()
    {
        llSetText( "Touch Me To Get Parcel Details!", <0,0,1>, 1.0 );
    }

    touch_start(integer total_number)
    {
        vector vecPosition = llGetPos();
        vecPosition.x = (float)((integer)vecPosition.x);
        vecPosition.y = (float)((integer)vecPosition.y);

        list lstDetails = [ PARCEL_DETAILS_NAME, PARCEL_DETAILS_DESC, PARCEL_DETAILS_OWNER ];

        list lstParcel  = llGetParcelDetails( vecPosition, lstDetails );

        string strName  = llList2String( lstParcel, 0 );
        string strDesc  = llList2String( lstParcel, 1 );
        string strOwner = llList2String( lstParcel, 2 );
        
        llOwnerSay( "Parcel: " + strName + " " + strDesc + " " + strOwner );

        list lstCheckParcel;

        string strCheckName;
        string strCheckDesc;
        string strCheckOwner;

        // Find smallest x
        vector vecSmallestX = vecPosition;
        
        integer depth = 0;

        do { vecSmallestX.x--;
             depth++;

             lstCheckParcel = llGetParcelDetails( vecSmallestX, lstDetails );

             strCheckName   = llList2String( lstCheckParcel, 0 );
             strCheckDesc   = llList2String( lstCheckParcel, 1 );
             strCheckOwner  = llList2String( lstCheckParcel, 2 );
             
        } while ( strCheckName == strName
               && strCheckDesc == strDesc
               && strCheckOwner == strOwner
               && depth < 1000 );
                
        llOwnerSay( "Parcel: " + strCheckName + " " + strCheckDesc + " " + strCheckOwner );

        llOwnerSay( "Smallest X: " + (string)vecSmallestX );
    }
}

it seems odd that parcel details would return clean from a prestart condition, but returns dirty from a looped call (not showing the next parcel info)...

and because it works when you pre feed the off parcel position I wouldn't expect permission issues... and I'll assume you've tested that the coordinate is properly incrementing...

the only other thing I could imagine is that it's somehow queueing the results of the first cal and just repeating them throughout the event... even after being fed different vectors.... whic makes no sense at all....

two things to try.... one hard code in some coordinates, two sets on clearly different properties and make sure both of those give different results from within the same event.

if they don't, try running your loop from a timer and see if it'll work that way...

I think it needs to check for sim border condition. (It would be more efficient if it only sampled the middle of each 4x4 square, but for one-time use, won't matter much.)

The issue here is that a sim's boundaries are set:

0 <= x|y <= 255

I'm right on the border of a sim. I could see my neighbour ... I just never twigged to the fact that he was on a different sim. So I didn't realize that negative numbers were bad. The function, instead of returning an error, just returned the last data it had in its buffers. Lovely bounds checking there LL!

So, adding a check for those conditions makes it work just fine.

Never EVER pass bad parameter values to a LSL function. Heck, they have enough difficulty figuring out how to handle "good" data....