Right of Instantiation

I've mentioned this before in threads on other topics, but I'm planning to eventually make a voting proposal for it, so this is a discussion thread specifically for the topic.

Summary: This feature would allow any user (as a Fair Use right) to make any number of inventory references (called "instances" to an item that they own. Instances are functionally equivalent to the original item and tied inextricably to it ... they merely allow it to be listed in multiple places in inventory.

Purpose: To enable better inventory organization and using features like folder-dropping to better effect, to make no-copy items less annoying.

Additional benefits: Make the choice between copy and transfer easier, and to reduce asset server load


Description:
I'm pretty sure the programmers and unix users will have a good grasp of the concept here already. It's a pointer/symbolic link that you can't keep if you sell the item.


For anyone who doesn't understand that, say that I have purchased (perhaps as part of a larger ensemble) a no-copy wearable, such as a jacket. Or perhaps it is a skin, and I want to set up folders for several different "characters" that use it.

I believe it is my right to mix and match anything in my inventory with other pieces in order to create unique combinations. Indeed, I can currently do that. It just requires that I move items from folder to folder, or hunt it down manually each time I change clothes.

That is tedious, prevents me from using the "folder dropping" method of wearing items to good effect, and muddies up my otherwise logical inventory organization ("I bought this piece as part of this outfit, but I use it here, here, and here as well.".

What would be more efficient and useful is to allow me to put a pointer of sorts to that jacket with each custom outfit, or that skin with each character's folder. A stand-in, if you will, which is functionally identical to having the actual item there.

This functionality is useful even if the item is copy-enabled ... maintaining completely independent copies of items is hard on the asset server for no good reason when the user merely wants the item to appear in multiple places in inventory.


Details:

* All actions performed on an instance are instead performed on the original. Say we have an asset, A, and two instances thereof, iA1 and iA2. We have full perms to A.

- Normally, copying A creates B, a completely new asset with independent existence. Similarly, copying iA1 creates B. It does not turn iA1/iA2 into iB1/iB2, nor does it create iB1; if you want instances of the new asset, you make them yourself.

- Normally, modifying A ... modifies A. Likewise, modifying iA2 actually modifies A. Thereafter, both iA1 and iA2 will reflect the change.

- Normally, selling A removes it from the seller's inventory (or takes it out of world and into the buyer's inventory). Selling iA1 not only transfers A to the buyer in this fashion, it also breaks or deletes both iA1 and iA2 in the seller's inventory (this is to prevent Instances from bypassing copy permissions).

- The action of creating an instance, if you applied it to another instance, would just make a new instance of the original. That is, instancing iA2 merely creates iA3. It doesn't produce i(iA2).

* Just as I can always move my items, I can always create instances of my items, regardless of their permissions. I see no good reason for creators to restrict it.

* Permissions of an instance are identical to the original. Thus, if I can't modify A, I can't modify iA1 or iA2 either.

* Rezzing an instance in-world, or attaching one, rezzes or attaches the original. (Instances only live in inventory, and have no independent existence.)

* Instances would need to be drawn in a unique way in inventory, for clarity. A different color and/or text decoration.

* Copy permission is still useful ... for example, allowing customized variants of a vehicle, or the usual "backup copy" in case a mod object lost in a mishap or broken by user tinkering. It's just less necessary ... probably a good thing, because it's sometimes a needless choice between transfer or copy.


Alternate terminology: Standins, Mirrors, Pointers.

Thoughts?

I'm absolutely agreeing that symlinking in the inventory would be a great concept. I have that one in my personal "killer features" list I want to post some time, when I checked all of them for duplicates

Please create a voting for it, you have my voice!

Or 'link' for Windows users?

"Shortcut".

The computer programming/filesystem analogies were added mostly as an afterthought because I realized that it'd be simpler to sum it up that way for people who knew such things. There are a number of similar features I could pick.


Anyway, I'm just holding off on adding a voting proposal to see if there's anything else I need to include in it.

I support this proposal... not just because it would be cool, and not just because I know Dyne from wayback... but because I really like the word 'Instantiation'. Right of Instantiation sounds like something Catholics would do during Mass.

I don't reall think we need it. Just make clothes and such copy but no transfer..and allow them to buy no copy but transfer enabled for gifts..

You can't force vendors to sell their products copy enabled, thus the symlinking idea would be great for items, that are no copy.

Besides, if the item is modifiable, you can simply modify the master copy and all links will follow, no need to copy them all over again into your various outfits or objects.

Er...well that I was seem to be confused somethings =P

Great proposal, I hope to see it added to the voting site soon

I like this.
*personal stamp of approval*

mmm "rite of instantiation" : inauguration to main from teen grid ?

.. and I'd vote for this proposal.

There's been about 40 Feature Suggestion threads like this.

How about something to vote on?

And call them aliases or shortcuts, please, or you'll end up with something weird... remember how the Linden response to the "invisible in IM" request was something about making the avatars invisible.

If there have, I've never seen them.

I know most people create the voting proposal first and the discussion thread second, but the voting page recommends the other way around, which makes sense to me (I've seen too many cases where the thread isn't linked from the proposal ... and the thread has better ideas than the original proposal does). So I was waiting a few days to see if anybody mentioned anything that needed elaboration or clarification or more thought...



... and that's a good example of something I'll have to ponder. I called them instances because I needed a term and that's what made the most sense to me. But I can see how that could be confused with instancing in MMOs, and lead LL to think we are talking about instancing our parcels or something.

On the other hand, 'aliases' might be misinterpreted as "I want the ability to have more than one name" and 'shortcuts' as "Make the avatar walking speed faster". Trying to second-guess how people are going to misread you can backfire or be pointless.

lol. from what you say, Alias seem to be the least misinterpreted though =P I don't need walking faster while I can run and fly, but people can make use of multiple names object.

"Inventory alias" or "inventory shortcut".

Yes, it's possible they'd get confused, but it's a lot less likely than if you pick a weird name that only geeks like us ever use.

Proposal #1165 has been created.

I went with inventory shortcuts, because that makes the most sense to me.

Awesome! You get my votes for sure. Spread the word. This is a great idea.

I had a huge reply written up to this, and then the fuse blew, and now that I'm back to reply, it's already a proposal..
Well bugger. That said, I still want to comment on the idea.

First off, to make this idea work, I think a couple changes would need to be made.

1. Don't let them do things like choose "edit" or other item specific actions. Only let them choose things like wear, attach, etc.

2. Instances of objects should be rezzable, so that no copy objects are impossible to lose in the world.


That said, if #2 isn't possible, then an alternate to the idea as a whole would be to make a totally new object type, call it an outfit. Outfits would simply be a list of objects that compose the outfit, including attachments. That way, a single outfit file could be "worn" and it would automatically wear the associated objects.

That's the short version anyway.

No, I *want* to be able to edit once and get every instance updated.

I think that would be almost impossible to implement without opening holes in the system.

It's called a "folder".

I like this idea.
As for editing a rezzed symlinked object, there are two ways it can be done:
Instance and Reference.
A modded instance chages all the instances.
A modded reference becomes a new object.
Both would be useful.

An interesting (but crucial!) side-effect of this suggestion is that it would allow a set of objects to have always the same UUID. This is quite a nuisance at the moment for handling/setting up certain kinds of objects that *need* a 'fixed' UUID to work properly — like llEmail to objects.

It wouldn't be *perfect* but it should work.

Also, one thing I loathe is the current issue of merchants having to sell copyable, non-transfer items (like hair, attachments, and clothes — besides vehicles) just for you to create outfits and have a copy of each item on every folder you use for your outfit. Not only it's a waste of asset server resources (to ovecome a limitation on the way the inventory is handled), but it also means you can't sell/give away an item you don't use any more, but that a friend (or a newbie!) could benefit, if it weren't non-transfer. I lost the count of how many clothes/hair/attachments I've got that somehow looked much better on the pictures, the vendor spelled out loud and clear NO REFUNDS, and I'm not allowed to give them away...

One vote for me on proposal #1165!

This proposal wouldn't have any effect at all on objects in-world. Only in the inventory.

Every time an object is rezzed from inventory to world it gets a new UUID.

Originally known as the Macintosh "Alias," (and probably some Unix doo-hickey before that)

I'll add my vote to this, since I've been asking for symbolic links since 2004

Sad, sad news

So we need an 'unique UUID' system beyond that. Ah well. We need so many things in LSL, that the list will never stop from growing...

And in any case, having 'aliases' or 'symbolic links' will still be highly useful beyond tidying up inventory... imagine updating an object in-world, and all 'copies' would reflect the change immediately... it would be wonderful to do updates of certain objects! (imagine how Starax's wand could benefit from that!)