integer llGetInventoryUpdateTime(string inventory);
PARAMS:
inventory = the name or key for an inventory item within the object where this script resides
RETURNS: a unix time-stamp indicating when this inventory item was added to the object in which this script resides, or was last updated (ie due to renaming/saving etc)
Reasoning for this is simple; currently to look for updated items in an object we have to maintain our own lists of names, keys and so-on. But this is not very memory efficient, and makes it impossible to cope with objects with any number of inventory items. As such this function would allow us to simply skim through inventory and look for items which return a timestamp greater than that corresponding to the last time that we looked. This quite neatly then allows us to deal only with these updated items, ignoring unchanged items completely.
. I hope either one could get implemented. 
New Feature
Open
Normal
llGetInventoryUpdateTime()
time), it only has to process those that actually updated, and can do so without maintaining an internal list, which for 200+ items would easily eat up the memory of an object. Even for low numbers of items the amount of wasted memory and processing time because we don't have this function is pretty ridiculous.
Basically the changes amount to:
With it to perform some action on an object with 200 notecards you can do the following:
// START_SCRIPT
integer lastUpdateTime = 0;
default {
state_entry() { state loading; }
changed(integer x) { if (x & CHANGED_INVENTORY) state loading; }
}
state loading {
state_entry() {
integer x = llGetInventoryNumber(INVENTORY_NOTECARD);
integer i; string s;
for (i = 0; i < x; ++i) {
s = llGetInventoryName(INVENTORY_NOTECARD, i);
if (llGetInventoryUpdateTime(s) >= lastUpdateTime) { // >= because we can't rely on the precision of seconds llOwnerSay(s+" has been added or updated"); }
}
lastUpdateTime = llGetUnixTimestamp();
state default;
}
}
// END_SCRIPT
In an object with 200 notecards, while it still has to go through all of them (O
time), it only has to process those that actually updated, and can do so without maintaining an internal list, which for 200+ items would easily eat up the memory of an object. Even for low numbers of items the amount of wasted memory and processing time because we don't have this function is pretty ridiculous.
Basically the changes amount to:
There seems no con to this besides the relatively small amount of work required to implement it, as object inventory is not updated frequently enough to present any real increase in overhead due to update timestamps etc.