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.)

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-235004 | | Summary | llRezObjectWithParams option: REZ_FLAG_DRY_RUN | | Type | New Feature Request | | Priority | Unset | | Status | Closed | | Resolution | Unactionable | | Created at | 2024-01-22T07:04:04Z | | Updated at | 2024-01-26T03:14:12Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2024-01-25T21:14:12.120-0600', '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.\r\nWith 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).", 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', '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.)\r\nThe 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.\r\nThis 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.\r\nAn 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.', } ```

secondlife / jira-archive

[BUG-235004] llRezObjectWithParams option: REZ_FLAG_DRY_RUN #11822

How would you like the feature to work?

Why is this feature important to you? How would it benefit the community?