Ability to delete multiple contents in a prim's inventory.

Nothing sucks more than having to clear out 50-60 items from a vendor.

I suggested this idea in an earlier thread.

Why don't you add the ability to use multiple inventory items everywhere? I hate moving things from a box into my inventory one-by-one. I would really like to be able to move objects in my inventory in large batches.

Please add this feature in the next minor update. How hard could it be?

Another way to solve this would be to let us place folders in objects, then hand someone the folder.

(Better still would be to allow us to have both folders and bulk select/drag/copy/paste, but letting us put folders in object contents solves two problems --or at least one and a half-- instead of just one.)

The problem with this is that they would need to revamp all object inventory LSL functions to include a subfolder parameter, unless they do something "magic" or "clever" with the way object inventory folders are implemented.
Like, for example, making the folders something that affects the UI only and handling the real data as if all the contents were in the same folder. This would be a very unmaintainable and potentially bug-attracting solution, since the way the inventory "looks" isnt the way the inventory is actually stored.

==Chris

I endorse these features.

Christopher, what about doing something like llIgnoreInventoryFolderStructure(TRUE/FALSE);

Having it TRUE would mean the script treats all the folders as one, like scripts do today.

Having it FALSE would mean the script treats the inventory as a folder system with multiple folder options.

I suppose however you would need to change some functions or add some.

Maybe instead of the above function add new functions for every current inventory related one that include directory links, like... llGiveInventory2(llGetOwner(), Content/Files/"OMGWTF";

Or even just add in compatability for directory links, say...

if llGiveInventory(llGetOwner(),"OMGWTF"; it looks in the whole Contents for it, sub directories inclueded, if multiple files are found in different directories and are of same name and type, it would give the first found. If they are of same name but different type (say an object in Content/Objects/"OMGWTF" and an image in Content/Images/"OMGWTF", it would give the first found of each type. Or you could even have this just look in the Content folder and ignore all other sub folders.

Else if llGiveInventory(llGetOwner(),Content/Files/"OMGWTF"; it looks in Content/Files for the item, and only gives that item.

So if you have specified a directory it looks there, otherwise it treats all folders as one. Not sure how plausable this would be to implement, but it seems like it would work, wouldn't break any currently existing scripts.

I would actualy go with my last idea there.

Sorry, kinda went off topic there, but I DO heavily endorse multi-select and delete in object inventories.

Yeah, actually, Oz's model was kind of what I was getting at. Sorry I didn't spell it out.

I kind of think you'd have to make the entire thing a string though -- "/Files/OMGWTF" versus /Files/"OMGWTF", I mean. I don't think rewriting the LSL parser to allow for that stuff would be a fun task.

If you think about it, we don't really need llIgnoreInventoryFolderStructure at all. If someone doesn't want to USE folders, they wouldn't have to.

So that way, you would only need to add an INVENTORY_FOLDER constant, and for scripts that wanted to use subfolders, they'd just use the new naming convention.
"foo" or "/foo" would be a script in the root. "/bar/foo" would be a script in another folder. We'd ignore relative paths altogether, since folders really would be just an illusion.

I don't know, it seems like it'd work just fine to me. It's useful and seems like one of those relatively minor features that ends up having a rather efficient "usefulness/efford" ratio for the Lindens.

Certain functions would still need to be revised to support subfoldering, namely llGetInventoryName and llGetInventoryNumber.

Not that I dont support object inventory subdirectories I just dont want LL to implement a feature that affects scripts, and leave the scripters without the ability to cope with it.
==Chris

I dunno, seems like a hard decision to me, if you have "Content/Files/OMGWTF" you may run into trouble with it thinking its looking for a file in Content named "Content/Files/OMGWTF".

So it may be worth to spend the time to include something like Content/Files/"OMGWTF" if you're going to spend the time writing something to determine the difference between a file name and a folder path.

But I dunno, I don't really care either, either way would be fine with me, as long as it works and knows what its doing, lol.

The llGetInventory functions could just ignore subdirectories all together, or you could add llGetInventorySub possabilities. I agree breaking any current scripts is bad, very bad. It would be a toss up, having it ignore subdirectories could present some problems, but do you really want to take up those function spaces with additions for sub directories?

Sounds like a coin toss.

Yes, but copying-and-pasting the existing llGetInventoryName and llGetInventoryNumber to llGetInventoryDirName or whatever, deprecating the older functions... that just doesn't seem that difficult.

Of COURSE this would require a rewrite of some LSL functions. That's why I want it.

Those all sound like nice ideas, but a solution at least for the mean time would make it somewhat easier, is to get rid of the delayed refresh of content items.

Like when you deleting objects one by one and you have to wait after a delete to click another and hit delete, or else you end up deleting your object (and cant ctrl-z it) due to the delayed refresh, which is very very frustrating!

I'd say: Allow folders, and just read the whole of the object's inventory as a flat list, ignore the folders for script purposes.

Or just make multiple selection and drag possible. Even to the world.

Yeah, but Tiger, what do you do if you have two inventory items with the same name, but in different directories? Keys are obviously not an issue, but names could be. For people who want to give a folder as a single, self-contained package, this could be annoying. Things like landmarks, notecards, etc, would need to be renamed many times over.

As inelegant as it may be, I favour adding a second set of inventory functions, each with a "directory" variable added. It's something that we should've had from the beginning, and it's better than breaking all the current llGiveInventory scripts.

i support this in full.

Also a way to set permissions of all contained inventory items would be grand.