Does llGetLandOwnerAt() fail ?

eg:

we know that g_land_owner has build turned on and allows objects to be rezzed ...


if ( llGetLandOwnerAt( pos ) == g_land_owner )
llRezObject( name, pos, vel, rot, 1);


but very occassionally I get an error message saying rez failed because landowner at x,y,z does not allow building.


Is it a bug or an error ?

Assuming that you get intermittent errors on the same, non-group owned parcels, my guess is that it is the asset server failing to return an answer in time to llGetLandOwnerAt() and the LSL function times out. If this guess is correct, I would guess that llGetLandOwnerAt() is returning NULL_KEY which you could test for and llSleep() for a little and try again.

This seems very similar to the mouse-over text on land and objects which shows something like "owner: retrieving..." and then "owner: unknown", where mousing over the same object a second later does obtain the owner. LL is hyper-aware of the asset server issues, so I would recommend coding around this for the short-term.

reallyGetLandOwnerAt(vector p) { // not compiled or tested
  integer tries = 5;
  key k = NULL_KEY;

  while(tries-- && (k == NULL_KEY)) {
    k = llGetLandOwnerAt(p);
    if(k == NULL_KEY)
      llSleep(1.0);
  }

  return k;
}

Thanks for the idea but if it returned NULL_KEY my existing test would work fine as it is. NULL_KEY would not be the same as g_land_owner and the object would not get rezzed.

pos is a fixed position and does not change between LSL calls.

I do see where you're coming from and it makes me wonder if perhaps llGetLandowner is sometimes returning its previous return value. I find it disturbing to think that it will timeout though !

It's effects like that that make me begin to wonder if something hasn't gone awry with the underlying event code... since about 1.6.1...

/esc

If my guess about the timeout on data requests (like llGetLandOwnerAt()) is correct, this would actually be a reasonable way to code the LSL API. I think it analogous to the Unix ETIMEDOUT error return on socket operations in that LSL has made a query which may never return as it has been dropped. The API designer has the choice of blocking the script infinitely (bad) or providing an error return (good). It may be that the llGetLandOwnerAt() failure is not being passed up to LSL level with a NULL_KEY return and instead returning some static buffer value as Laukosargas posits. I'd bug report that.

To ask the bleeding obvious, you say that "pos is a fixed position and does not change between LSL calls". I presume you mean for the purposes of this test, otherwise, just cache the boolean once. Ah you say, "but my first call may give me a bad value"; true, in which case I'd follow NASA procedure and ask 5 times and take the majority vote at least until the error return is fixed.

As the great Ezhar once told me, "It is not what you can do with LSL that makes it interesting, it is what is hard to do that is."

Lauko ... is the land group owned?