llRezObjectWithParams option: REZ_FLAG_DRY_RUN
closed
Kyle Linden
How would you like the feature to work?
Scripts have a lot of difficulty figuring out reliably, whether they can rez objects, and there's a lot of failure cases a script simply can not test for (and even a few it arguably shouldn't be able to). And as raised recently, in the case of coalesced objects in particular, this can be especially problematic.
With this flag, the simulator should go through all the checks and other motions in rezzing the object, but not actually rez anything (nor consume any no-copy inventory) — instead, it should indicate why it failed (to whatever degree is possible).
Why is this feature important to you? How would it benefit the community?
For this purpose, about a decade ago I created a script that rezzes a phantom temp follower everywhere I go, and reports whether it was successful by chat channel to participating scripts. While it awesomely doubles as a TP poofer, that's still a bunch of rezzing the sim really doesn't need, and really not a generally applicable solution anyhow. (Recent improvements mean I can probably drop the temp flag now, saving a few rezzes at least.)
The point, is it's doing basically what I'm (minimally) asking for with this feature request (ie. "try it, and see"), but without the cost of actually rezzing an object. A positive response is still not a guarantee, things could change in the meantime, but I'm sure I'm not the only one presently using the "try it and see" method, and a flag such as this should be just as reliable, while being less of a burden on the sim — especially if your script needs to know ahead of time; in my case, it's so my general purpose HUD can disable features that require rezzing. This flag should also inhibit any error messages due to the failed rez.
This is also a topic that comes up quite frequently, with people wanting the ability to check this or that new edge case, and as noted, there are a couple which arguably shouldn't be available for checking, and this feature can handle those with a generic "other reasons" flag in it's failure response.
An object_rez_failed event (wasn't there already one planned?) giving as much detail as possible (at least, a bitmap of failure reasons) would be optimal. However, failing that, could just use a dataserver event with the failure response instead — while a little icky, it has the benefit of being somewhat extensible; just define the response as a CSV, so more information can be added later if needs be.
The associated object_rez command should probably not fire (since in fact no object was rezzed), so as not to confuse scripts (or otherwise require extra special handling), and should instead cause a "positive" response on the failure event. (This also fits with reporting "partial" success — I'd count that as still a failure, generally, though.)
Log In
Spidey Linden
closed
Hello, and thank you for your feature request.
Incoming suggestions are reviewed in the order they are received by a team of Lindens with diverse areas of expertise. We consider a number of factors: Is this change possible? Will it increase lag? Will it break existing content? Is it likely that the number of residents using this feature will justify the time to develop it? This wiki page further describes the reasoning we use: http://wiki.secondlife.com/wiki/Feature_Requests
This particular suggestion, unfortunately, cannot be tackled at this time. However, we regularly review previously deferred suggestions when circumstances change or resources become available.
We are grateful for the time you took to submit this feature request. We hope that you are not discouraged from submitting others in the future. Many excellent ideas to improve Second Life come from you, our residents. We can’t do it alone.
Thank you for your continued commitment to Second Life.
Kadah Coba
I mean, it would also be nice if no-copy items, upon failing to rez, aren't at risk of being banished to the shadow realm.
Honey Puddles
What part of llGetParcelFlags(llGetPos()) is not working that inspired this request?
PARCEL_FLAG_ALLOW_CREATE_OBJECTS will tell your script if 'everyone can build' is enabled.. PARCEL_FLAG_ALLOW_CREATE_GROUP_OBJECTS will tell your script if 'group only' build access is enabled.
Perhaps the author is unaware of the caveat with group-rez-permission that when only certain roles in the group have build permission, the rez fails if the rezzer's owner is offline/not present (and thus their group role can't be read by the region).
See caveats on https://wiki.secondlife.com/wiki/LlRezObject
I wonder if it wouldn't be more practical to try and fix THAT issue.
Bleuhazenfurfle Resident
Honey Puddles: Yes, that among them. But there are also other weird edge cases (right down to potentially the rounding of a float), this request also came out of the issue with rezzing coalesced objects (which brings it's own headaches), and so on. And there may well come new reasons in the future — the llRezObject variants get pretty much the final say so far as LSL goes, so this flag aught to catch them all, including future ones, long before anyone gets around to adding a new llGetParcelFlags entry.