integer llCanRez() function
tracked
Blaise Timtam
I use this in scripts to know if rez is possible
integer canrez()
{
list parcelownerandgroup = llGetParcelDetails(llGetPos(),[PARCEL_DETAILS_OWNER,PARCEL_DETAILS_GROUP]);
list objectownerandgroup = llGetObjectDetails(llGetKey(),[OBJECT_OWNER,OBJECT_GROUP]);
integer parcelflags = llGetParcelFlags( llGetPos() );
integer result = FALSE;
if(llGetOwner() == llList2Key(parcelownerandgroup,0)) result = TRUE;
if(llList2Key(parcelownerandgroup,1) == llList2Key(objectownerandgroup,1)
&& (parcelflags &PARCEL_FLAG_ALLOW_CREATE_GROUP_OBJECTS)) result = TRUE;
if(parcelflags & PARCEL_FLAG_ALLOW_CREATE_OBJECTS) result = TRUE;
return result;
}
It not totally reliable.
It would be nice to have a llCanRez() or llCanrez(vector position)
Log In
Monty Brandenberg
Just an historical comment for consideration. A llCanRez() call distinct from the rezzing request itself has the same race problem that access()/open() have in Unix. The world can always change between the two calls leaving llCallRez()/access() as mostly a hint as to what will happen.
Maestro Linden
updated the status to
tracked
Oggy Fink
If I'm not mistaken, your code does not guarantee you can rez objects because the parcel may be full too.
We should get a return code from llRezAtRoot() and similair to know if the rezzing process succeeded instead.
Blaise Timtam
Oggy Fink yes that. It also gives false negative when only certain roles from the land group can rez
A return code instead of error could work but does it make sense to ask here for function modifications that could break existing content?
We could also dream of a try and catch error handling in LSL
Oggy Fink
Blaise Timtam I meant your proposal of a lllCanRez() function makes sense, but if it cannot guarantee the rezzing process will fully succeed well it is less useful than expected. And since it also depends on the object you want to rez, in addition to where, when and possibly how, this begs for a more complete implementation taking more parameters, just like llRezAtRoot().
And a success-type return value there (with llRezAtRoot()) would be most useful. Would it really break existing scripts to add it? I don't think so, because existing scripts will just ditch a return value the way they are now.
But maybe this relies on script-compilation details I am not aware of.
Bleuhazenfurfle Resident
This is still insufficient — things like the position and rotation of the rezzed object can influence whether it can be rezzed.
Which is why I suggested elsewhere, a REZ_DRY_RUN parameter to llRezObjectWithParams. It can go through the regular actual rez process, with all the same parameters, doing all the same real checks, with the same actual working code, but then just not actually rez anything, and give us a result code instead.
Though I don't think llCanRez is the right way to do it, the idea is still very much important; you can not determine all the reasons for which a rez can fail, and while getting those added to llGetParcelDetails and the likes is a good goal, it'll forever be a race between new failure reasons cropping up, and a suitable property being added to check for it — and won't help existing scripts.