llGetInventoryLastOwner
Naughty Puppy
(or llGetInventoryAddedBy, or - ... But I'll stick to the semantics of "last owner" for presentation's sake)
Scripts can act on object inventory and objects can be configured to accept inventory from any source (llAllowInventoryDrop), as well as from agents with permission to modify the owner's objects. Being able to interrogate object inventory entries for their last owner would be good addition to scripting - it would make CHANGED_INVENTORY and CHANGED_ALLOWED_DROP events more able to richly react to the users causing them, as well as allowing for (slightly) better behavior security.
Objects have a property OBJECT_LAST_OWNER_ID but this can only be interrogated (in script land) with llGetObjectDetails, while the object exists in the world.
It would be nice if this property was:
- available on all kinds of asset,
- for inventory, set when it is added to an object's inventory,
- accessible via a key llGetInventoryLastOwner(string item)function; the same theme as llGetInventoryCreator.
----
Snipped from a followup- I think this additional surface would help put inventory metadata stuff to bed. They're less important since the information can be determined by holding state and introspection, but I feel reasonable in assuming keeping this stuff transiently in the event queue versus many disparate user implementations and in memory + serializations would be cheaper for everyone.
If inventory changed event triggers don't batch the count + index stuff is unecessary, but I haven't checked and I feel like dropping a folder into an object will be counted as as single event. These would be meaningful only within CHANGED_INVENTORY and CHANGED_ALLOWED_DROP events in the same vein as llDetected*.
integer llGetInventoryRemoveCount()
-- 0..N, the number of removed inventory entries.string llGetInventoryRemoveName(integer index)
-- "" or when llGIRC is nz and 0 <= i < N, the name of removed entry i. At this point the entry is no longer present in the object.integer llGetInventoryRemoveType(integer index)
-- INVENTORY_NONE or when llGIRC is nz and 0 <= i < N, the INVENTORY_TYPE of the removed entry i. At this point the entry is no longer present in the object.integer llGetInventoryAddCount()
-- 0..N, the number of added inventory entries.string llGetInventoryAddName(integer index)
-- "" or when llGIAC is nz and 0 <= i < N, the name of added entry i. integer llGetInventoryAddType(integer index)
-- INVENTORY_NONE or when llGIAC is nz and 0 <= i < N, the INVENTORY_TYPE of the added entry i.Log In
Lucia Nightfire
Last owner might not actually be the one that dropped an object into an allowinventorydrop object, though.
The Last Owner metadata mostly changes with set group change or owner change while the object is rezzed/attached.
An object can change hands dozens of times while the Last Owner metadata remains the same as long as it happens between object/user inventories.
What you would need is a "who added this inventory item to this object" metadata.
Naughty Puppy
Lucia Nightfire
I've been thinking about this exactly as a property set at object inventory add time, on the added entries, that holds the agent or group uuid that caused the add - since either an agent or owned object will have instigated the change.
I've written "Last Owner" because OBJECT_LAST_OWNER_ID already chose those semantics. As you say, that's currently only relevant to objects that are spawned in the world; extending it with "any asset but only relevant in object inventory" doesn't feel like a collision but I'm not married to it, it just duck tests well in my head. llGetInventoryAddedBy would work just as well. :B
Allegory Malaprop
Does OBJECT_LAST_OWNER_ID really update last owner properly? I've seen what I would consider to be incorrect results from trying to track owner chains in the past, it does not seem reliable from objects that have stayed in a user's inventory and have not been rezzed by all owners. This behavior would also make a certain amount of sense to me (scripts just don't do things in inventory, they only do things when rezzed)- in which case this would not necessarily track who dropped objects in things, but potentially might tell you who gave THAT user the object (or multiple hops back the chain) instead.
In other words- I'm not sure the way scripts or assets work would make this a reliable function. (Like Jeremy Dupont, I'd potentially propose an alteration to changed that tracks more specifically what changed and how instead, which might also end up with some other useful additions to that event.)
Naughty Puppy
Allegory Malaprop The wiki notes a couple of gotchas with the object property, but the proposed behavior of setting it on assets entering object inventory seems pretty cut and dried to me - any change that's accepted will come from a user or an object owned by a user or group. I bring it up as an existing example, but one that seems eminently extensible to the aims of the FR!
Paired
with the other changed event additions you refer to from a few hours back, it would make every non-malicious use-case I can think of much friendlier - in some cases achievable-at-all. 🫡Allegory Malaprop
Naughty Puppy I suppose my issue comes from the question of how the entire system is currently created- and it seems to me that certain features only "happen" once an item leaves an inventory and is realized in the world. (And even then only finish actually happening when they are detached correctly and the current functioning state is saved.) llGetInventoryLastOwner(string inventory) expects that inventory object to know what has happened to IT, while it was inactive- which is why OBJECT_LAST_OWNER_ID can already give incorrect results. And there's no reason to explicitly add more features with incorrect results!
If that is the case, attaching something to an existing event/trigger like changed to actively track something that, at least to me, seems to be something it could be reasonably expected to be able to find a way to query (what is that? where did it come from?), requiring less reworking of the entire system in which inventory items remain somewhat...I guess you could say imaginary, full of unrealized potential until they are rezzed and that potential is actually applied and given real values. I could be wrong about how assets work entirely, but for a lot of different reasons, it's a theory I've developed from observing how assets react to the "world," and how they (do not) react when they haven't touched it.
tldr: Put the active scripting onus all on the part of the changed event- not expecting the inventory object that was passed around to actually do anything. Which I think is what you are now proposing!
Peter Stindberg
I had the very same issue a few years ago, with items dropped by llLallowInventoryDrop. I ended up with a very complex process of determining a probability who the last owner (or the dropper) might have been. It works fine and is correct most of the time, but a proper last-owner setting would make all this unnecessary.