llGiveInventoryList requires copy and transfer

to quote from the wiki, "llGiveInventoryList can only give items which the object owner has copy permission on.

can someone please explain this restriction to me?

it neglects to mention that no-transfer items may not be given, and indeed they can not be given to anyone except the owner. but this is intuitive.

[ i did search, but found nothing helpful ]

When you use it to give out your own items, then the next owner permissions do not apply. You can give away any object you made regardless of what you set the next owner permissions to be.

When you use it to give out an item that has been made by someone else, then the objects permissions DO apply. No-copy means it will give away the one and only item exactly once.
no-transfer means it will not be able to give out that item and instead shout an error message when trying.

while that is what i would want, my experience is that it does not give out the object, period. as it clearly states this in the doc, i suspect my test is valid.as i said, this is intuitive. i even tested that it will give the item out to its owner, i.e. not a transfer.

fwiw, i am trying to make a costume stash/dispenser for second life ballet. think props/costume room in a theater.

other wiki: http://wiki.secondlife.com/wiki/LlGiveInventoryList

llGiveInventoryList is a copy function. Therefore it requires copy permission of what is to copy.

Otherwise any prim with allowinventorydrop could be forced to give out free copies remotely.

I think you CAN still use llGiveInventory(). I believe you'll just lose the item though.

Note: Without the "...List".

possibly. but as a costume can have 20 or so pieces, we really need llGiveInventoryList(). the dancers can not be asked to scrape 20 pieces out of scattered places (body parts, clothes, attachments, ...) together out of inventory.

i just do not understand why llGiveInventoryList() will not give out the single copy of a no-copy item. should i whine on jira, lotta good it'll do?

Oh, I can guess why they've done it that way.

Say that you have 3 items, and the 2nd is no-copy. So llGiveInventoryList() counts the number of items to give - 3. Then, it gives the item on position 1. Then it gives the item on position 2 (if it worked that way)... and a curious thing happens. It can't give the item on position 3 since there are now only 2 items in a prim.

So the smarter llGiveInventoryList() would have to check object permissions for every item, and on no-copy items, decrement the counter and total... so the poor programmer who implemented it probably left it the way it is now since I bet he had some other pressing issue to attend to.

If you're for it, create JIRA entry and let us know the issue number - I'm sure going to vote for that one.

Also, there is one issue I opened regarding llGiveInventory() and no-copy items - if a user declines no-copy item, it vanishes forever and is not returned to the prim inventory; please vote for it:
http://jira.secondlife.com/browse/SVC-1128

And while I'm at it, I'm going to pimp this issue too (llRenameInventory proposal):
http://jira.secondlife.com/browse/SVC-1132


Oh, and regarding your problem - why don't you box your items, and then give the box? Or simply sell them (for L$0?) directly from a prim?

As far as I can tell there isn't any clear reason from a use case perspective. It was either a weird design choice, a defect they decided to make into a feature, an easy workaround, or whatever. But it's clearly documented (as well as anything is), so getting it changed would probably take an enhancement request, not a bug report.

it is now issue http://jira.secondlife.com/browse/SVC-1715. i would not be unhappy if it garnered a few votes.

Easiest way around it would be to package your items, give them the object and set it to "open" in the "when left clicked" option.

That way they get the object in question - with all of your items in it - and just rez it and touch it. That's it, they pick the button to copy to inventory, or copy and wear and that's all there is to it.

Take care - Hap

the downside to this is that customers cant examine the contents before hand (so can't see things like individual item permissions) from a buy option.

Ah, I see. I didn't realize the recipients would be needing to know the perms on the items. Yes, that would basically nullify my idea lol.

not in all cases, for instance, pay vendors you don't get to see the items before hand, and if it's free, who cares? I'm trying to work out an idea for a distrubted buy vendor system though, because it does have that ability to let people see in advance the permissions on objects, although I can't yet get around delivery of objects since there is no give for objects between sims (plus the annoyance of script permissions affecting item displaed permissions)

Usually the vendors receive product and price info from a central object server (either via e-mail or through an external web interface), and then communicate purchases back to that server so the server can send the items to the buyer. There's no reason the product info received and displayed can't include next-owner permissions, indicated through float-text, an ad texture, chat, or whatever. They buyer really has to trust the seller anyway; there's no reason to believe a vendor is necessarily going to give the things in its object inventory.

don't get me wrong, it's not a necessary feature, just a nice one, especial when selling multiple items...

although I just realized that give inventory list is pointless in a but vendor, since buying will either give a copy, original, or contents, in all cases obviating the need for the function call. whereas pay would use it, but not show the individual items... so it's a non-issue...

my bad =S