[BUG-234983] Feature Request: Function llInventoryObjectCoalesced()

[sl-service-account]

Information

This feature request is for the function:

integer llInventoryObjectCoalesced(string name)

returns TRUE if name is an inventory object and is a coalesced object, else returns FALSE

Currently we have no means of distinguishing if an inventory object is coalesced or not.

Scripts can rez either, but coalesced objects come with additional caveats depending on their cluster size and child object placement.

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-234983 | | Summary | Feature Request: Function llInventoryObjectCoalesced() | | Type | New Feature Request | | Priority | Unset | | Status | Closed | | Resolution | Unactionable | | Reporter | Lucia Nightfire (lucia.nightfire) | | Created at | 2024-01-15T04:14:27Z | | Updated at | 2024-01-26T03:08:32Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2024-01-17T11:03:27.789-0600', 'How would you like the feature to work?': 'This feature request is for the function:\r\ninteger llInventoryObjectCoalesced(string name)\r\n\r\nreturns TRUE if name is an inventory object and is a coalesced object, else returns FALSE\r\n\r\nCurrently we have no means of distinguishing if an inventory object is coalesced or not.\r\n\r\nScripts can rez either, but coalesced objects come with additional caveats depending on their size and child object placement.', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': '?', } ```

[sl-service-account]

JIRAUSER341305 commented at 2024-01-17T17:03:28Z, updated at 2024-01-17T17:08:22Z

So, why do we actually need this?  As in, what problem does it actually solve, other than telling the script "there be dragons here" (which it can't actually deal with anyhow).  Given this function, can the script actually tell if it can successfully rez the object or not, or provide it with any information that will help it ensure a successful rez?

Perhaps, a generally much better idea, would be a "check can rez" function, taking the position and rotation, and returning a set of flags indicating reasons the object can't be rezzed; rezzing not allowed, those caveats you mentioned, etc.  It'd likely still only be an estimate, but it's better than what we have now.  "too far away" could indicate (at least one contained) object can't be rezzed at that location.

Also, llInventoryObjectCoalesced as defined above, can just go into llRequestInventoryData (BUG-232877), rather than being a distinct function (since it's a property unique to that one kind of inventory item).  What would be very useful, would be llRID returning a CSV of "number of objects", and "(estimated) total rezzed LI".  Perhaps, information giving the bounding box of contained object centres (a simple object would be the zero point).

Though the real problem, seems to just be that coalesced objects shouldn't have those caveats over regular objects — when rezzed by a script, they should either rez, or not.

(To be clear, I'm all for more information for scripts…  so all for this feature…  this just seems like a woefully short-sighted "solution" to a problem that shouldn't exist, which will get in the way of something better down the road.)

 

[sl-service-account]

Lucia Nightfire commented at 2024-01-17T17:28:37Z

@Blue, this isn't a solution to the caveats to allow successful rezzing of any coalesced object.

This is a minimum gatekeeper for rezzer scripts to allow/disallow rezzing of coalesced objects because of the caveats.

We would need an additional function that is capable of reading the local positions of all child clusters objects within the coalesced object, something that is more complex and would take longer to implement.

Until then, this is much simpler first step in the overall process.

[sl-service-account]

JIRAUSER341305 commented at 2024-01-22T06:14:26Z, updated at 2024-01-22T10:34:28Z

Well, that was a complete non-response — you've already said all that, and I already covered all that in my comment above.  So, you're agreeing that this command is pretty much a useless "nice to have", then, as I suggested?  Always good when we agree on things.  :)

I hate the over-used "show me your use case" tripe, but, in this case it seems warranted.  So, show us your use case.

And it's not a "simpler first step", either; until the script is able to actually do something about it, the only sane "minimum gatekeeper" is still the user (yes, it makes me shudder too) — keep the fancy new command for when we figure out what would actually be useful.  Like, at least, returning some information on the distribution of component objects, or something (with a readily identifiable response that indicates a simple object).

-The one place I can see this command maybe being vaguely useful (and that's a very dubious maybe), is if the script will be watching the rezzed object, in which case it's not going to be watching the "whole object" it rezzed, but only a part of it, which could be problematic, maybe.  Though I see that as a fringe case (and most often work-around-able at that) that needs an actual proper solution, too.-  (Edit: Actually, scratch that, that's no different to any suggested use so far — nada.)  The only real practical use I can see for this command as you've presented it, is a "are you really really sure?" dialog, or something — and that sounds more annoying than actually useful.  (Unfortunately, it's also likely in the "low hanging fruit" category, so it'll probably happen anyhow.)

That said, as above, it could get shoved into llRequestInventoryData just fine — that's the proper place for a "nice to have" on inventory items — and we desperately need LL to add info regarding textures (aspect), sound (length), animation (length, priority), etc., so they can hopefully toss this in there too while they're at it.

[sl-service-account]

Lucia Nightfire commented at 2024-01-23T14:39:01Z

That's nice Blue. Everyone has an opinion on what they think SL needs.

I wouldn't mind a means of getting coalesced object cluster locations either, but that is not what I filed here.

I filed this for a means of literally knowing if an inventory object is coalesced or not.

If my rezzer apps had access to the flag, I would script them to either tell the end-user that coalesced objects cannot be rezzed or alert them to the caveats of rezzing coalesced objects and ask if they wish to continue. I would still use this feature first before doing repeated dataserver checks on the number of cluster objects and each of their localized positions and doing parcel owner/group/flag checks for each location before a rez attempt, had we also had that capability.

Instead of belittling this request for its usefulness to you, why not just file a feature request for what you want/need, instead?

[sl-service-account]

JIRAUSER341305 commented at 2024-01-24T06:26:02Z, updated at 2024-01-24T08:42:47Z

And I presented what I see as a better means of doing the {}exact the same thing{}, which you've been hell-bent on not even acknowledging, let alone discussing.  But, this isn't the place for that discussion.

Do understand that I completely agree with having this capability, just not the form in which you present it — I see the method you've suggested as heavy-handed and problematic, and would rather such a limited utility function either be a side effect of a more useful command, or be filed away elsewhere (or both) — personally, I'd specifically rather it be filed away in a corner that already exists, is woefully underutilised, and quite ready-made for it (though perhaps the slightest sliver less so, as I'll mention again next).

There's no good reason llRID would have to do an actual dataserver request if the sim already has the information, though it is restricted to generating a dataserver event still, so I do agree it's an imperfect fit in that regard, but I see that as fairly minor ({}that{} is, however, merely an opinion, as you say).  On the other hand, if it requires a dataserver request, then so does your llInventoryObjectCoalesced — either the sim has the answer (and can generate the llRID event immediately), or it has to go out to get it, and your llIOC command as specified here won't be possible anyhow.

Given your significantly better memory than mine, and all up closer contact with LL, I was actually rather hoping you'd clue in and respond with any practical insight you have into the matter, if you have any, but neglected to specifically ask.  Though, now I think about it a little more, I think I might change my stance to leaning towards the likelihood that the sim does have that information…  In any case, I still think your request here is overly heavy-handed for such a limited utility, and would rather hold off and get some better discussion happening.

And, yes, your use case, is exactly what I specified in my original comment, and re-iterated in my second, too — so you could have just said something to the effect of, "yeah, just that, I still think it's worth it though", and that'd likely have been the end of it, rather than coming across as obtuse, and as though you had some big mysterious use case I hadn't thought of (I did explicitly present that {}twice{}, hoping you'd take the opportunity to confirm that was what you'd intended).

Lastly, my name's Bleu, not Blue (I know, you always get that wrong, so much so I suspect it's intentional, I think it's kinda cute, though), and I already did file a feature request for what I want/need instead (BUG-235004) — I think that does a much better job of addressing the actual problem you seem to be trying to solve here.

 

 

 

[sl-service-account]

Lucia Nightfire commented at 2024-01-24T16:46:25Z

I simply want scripts to know if an inventory object is coalesced or not.

That isn't heavy handed at all.

I'm just going to chalk the back and forth up to simple creative difference, but clearly there is an impasse.

I leave it in LL's hands.

Also, "blue" was a mistake, not intentional, even if I keep getting it wrong.

[sl-service-account]

JIRAUSER341305 commented at 2024-01-25T02:11:43Z

(y)

[sl-service-account]

Kyle Linden commented at 2024-01-26T03:08:33Z

Issue copied to https://feedback.secondlife.com/feature-requests/p/feature-request-function-llinventoryobjectcoalesced