Right of Instantiation

You don't edit a "rezzed symlinked object". You rez an object

A symlink has to be purely a function of how objects are listed in the inventory. A pure reference that doesn't have any "in-world" component. Anything else would require massive changes to the asset system.

A symlink ahouldn't even have its own name.

If you wear it, all the symlinks show up as "worn".

If you rez it in-world and don't attach it, you've just created a copy.

If it's no-copy, and you rez it in-world, the symlinks all hide or get greyed out. They come back when you take it again (because the object comes back to the same spot in the inventory as it used to have). You'd have a mechanism to "purge" dead symlinks when you sell an object.

There's no other way to make this work wihout a huge amount of extra effort.

The way this proposal is worded, it doesn't have any affect on objects outside your inventory. If that's the case, then the only use for this is being able to organize outfits that include no copy objects.

The idea that a folder would serve the purpose of acting as a list of clothing and objects doesn't work for no copy objects. A new object type which is just a list of UUIDs to attach/wear would solve the problem nicely.

The major problem I see with symlinked/aliased/shortcut objects is that it over complicates things. It's a lot harder for the average user to understand the difference between an alias of an object and the actual object. Simply making a new object type that compiles an outfit into a single file would accomplish the same thing, but a lot less complicated.

Unless this proposal has some affect on objects outside of inventory, such as allowing you to keep the real object in inventory and rez a reference to it, it would only complicate matters and increase the learning curve.

Yes. It would also be useful for organizing objects that you want to keep identical in multiple outfits, so that changing it in one outfit changes them all. I have some scripted objects that I have to eventually copy to *60* folders when I update them.
Sure it does, because worn objects remain in your inventory and so can remain as the targets of symlinks.
That's called a "folder". You create one by selecting "save outfit as" in the appearance editor.
Yes, you would want "save outfit as" to save a *link* to unmodified and no-copy objects in the folder it creates.
I can not conceive of a way this could be implemented that wouldn't massively complicate the asset management system and open up new duplication exploits.

I'd favor greying them out. Otherwise, you wouldn't be able to move them around while the object was out in the world. And also because of what happens when you drag a folder containing one to your avatar ... if it's greyed out, you know that it also contains the linked item. If it's hidden, you'd have no way to tell ... or change that.

*stamps prop*

I've been looking for LL to implement this for a long time.

This would be EXTREMLY usefull.

I would probably use this for textures and such. I like keep an original archive of my textures in my texture folder, however when I create a project\build, I like dumping a copy of each texture I used in the project\build folder. This way if I ever think 'OMG what was that texture I used for [X] build' I can go in there and use it. I'm sure that currently LL hates me because i'm creating double, triple quadruple, (even more) assest when I copy stuff.

I currently also use that methode of various little props and objects, however if I change the master object or update it I have to change every other copy in my inventory.

*NOTE* These 'shortcuts' or 'symbolic links' would have to work both ways. If I replace an object with a abetter version I would want to be able to swtich all OLD pointers to the new object, (without having to mod all the pointers manually)

I wasn't actually thinking of this being used for updating stuff that you sold to others. Specifically, my thinking was:

* If your item was no-copy, the original and all links would all be deleted from your inventory when you sold the object or one of its pointers, and the buyer would just get the original.

* If it's copiable, the buyer would get a copy, and you'd keep the original and your links.

The reason is because that would open people up to buying objects that can be broken or completely changed in function by the creator ... such as quietly adding a spying function to the scripts.

The anonymity that SL offers residents can also be an impediment to us. Even if you trusted the original creator, accounts can be hacked, and apparently, can also be sold. Would you really trust a self-updating object? It'd be like Microsoft with mandatory updates, and an inability to be quite sure that Bill Gates' controls couldn't be quietly taken over by the disaffected, maladjusted 1337 script kiddies who released the latest grey goo attack.

If they're symbolic (ie, just contain a path to the new location) you won't need to change them all manually when you replace the object... but you won't be able to move the destination, and you'll have a problem if you have two objects with the same name in one folder.

What Apple does in this case in their aliases is to maintain both a hard link to the actual file and a symbolic link to the location of the file, and it tries both with the hard link given priority... and updates it if the hard link fails or the location changes. That would be the best mechanism to use.

Okay, so that makes... let's see... *counts*... at least 4 propositions all wanting the same thing now. That was all I could find in a quick search on some terms that come to mind when thinking about this. Can we just sort of agree on one of these to vote for? I've had my votes in #573 for quite a while now. (And I think I made this comment the last time I saw this thread too...)

Prop #1165: https://secondlife.com/vote/index.php?get_id=1165
Prop #737: https://secondlife.com/vote/index.php?get_id=737
Prop #591: https://secondlife.com/vote/index.php?get_id=591
Prop #573: https://secondlife.com/vote/index.php?get_id=573

And so would my version of the proposal. Since it is simply a list of the items you have in inventory already.


Sure, if the aliased object feature is created, but functionally, that wouldn't be necesarry if a simple Outfit object type was created. It would provide the same function as having copies of an object/Alias of objects in a folder, but would instead be a single object.



Except, outside of implementing the aliases of objects feature, it doesn't work for no copy objects. In addition to that, using the "Create an outfit" button creates copys of the objects, which doesn't allow you to change the object once for all outfits. A simple update to the button would instead create a new object that would be the whole outfit stored as one.

The outfit object would save space in inventory and on the servers. Instead of creating copies or even individual aliases for each object, you'd simply have a single object that contained a list of UUIDs of the objects in your inventory used for that outfit. Much like a Playist references the MP3 files, but is in reality only a list.

What I'm proposing is an alternative to implementing aliases. One that is MUCH easier for a user to understand, easier to program and does the exact same job.




Making it so the object rezzed in world is only an alias, an intance of an object in your inventory WOULD take a lot more work. I'm not suggesting this proposal should do that, even though it would be nice. What I'm saying is, creating Instances, aliases, shortcuts to individual objects would, in this case be used almost strictly for avatars and outfits. To accomplish the same goal, but make it easier to understand for the average user, a simple Outfit object would much better serve this goal.

I'm sorry Argent, but I'm getting the feeling you aren't really reading what I'm writing, but instead are writing me off as someone incapable of understanding the way Second Life works. The whole pointing out how a "Folder" is no different than having a new object for outfits feels rather condescending.

I would'nt use them for selling, only for managing my inventory. Wouldn't do much good selling stuff.

As for being the links... what if I had a but of 'shortcuts' pointing to 'Widget v1.0', then I update it and make a 'Widget v1.1' See what I mean by 'working both ways'? If it works like windows shortcuts, All the 'Widget v1.0' would be broken. I was a way to say... UPDATE ALL SHORTUTS='Widget v1.0' TO 'Widget v1.1'.

Again awsome prop. Keep the discussion going!

Well, to be fair, clothing and skins are two of the most universally owned items in SL. I imagine that most people's inventories consist primarily of such things.

Hmm. When I did that, I didn't get any.

This is one of the problems I've always had with the voting tool; it's too easy to wind up with duplicates, and thus split the votes. There needs to be a better way to merge dupes into one big proposal.


Personally, I think it'd be good for the proposal's author to have the ability to release the votes applied and either tenatively apply them elsewhere (subject to confirmation by the voters ... moved votes would not be counted with regular votes until confirmed) or else release them with a note to the voters as to why, and where they might go to put them instead. Or at least a note saying to check such and such URL for the explanation.

I'd tend to favor putting them in the most clearly worded and planned proposal, myself. Not having read all those yet, I couldn't tell you which that is.

Yes, but it would require a much more complexs user interface to implement. This would simply require one checkbox in the appearance editor, and a menu item "paste as alias". And it wouldn't allow you to have mixtures of aliased and unique objects, and it would make it much more complex to do things like taking an existing outfit and making a subset of it, or changing part of it... you'd have to open up the "outfit editor" instead of just copying folders.

I don't understand your second comment, so I'll skip it.

Huh? If the object is "no copy" it'd either move it (if you 'save as copy') or create an alias (if you 'save as alias').
That's what "save" or "save all" would do.
There's no difference between a folder containing a list of UUIDs (aliases) and an object containing a list of UUIDs. The savings from having a specialised folder object that can only contain aliases (which is what you're proposing) over a folder that can contain aliases and objects is very small, and having to create a second interface to do the same thing is silly.
There's MP3 players where a playlist is a folder containing symlinks. The Windows "start menu" is a folder containing symlinks.
It's harder to program, it only does part of the job, and the user will still have outfits that are folders as well as outfits that are outfits.
Maybe, maybe not. It's a useful general purpose organizing tool. I have copies of things all through my inventory, including *groups* of outfits, that could be aliases.

And even if they are, "outfits" are less useful for avatars and clothes and attachments. Let's say you want to make a new outfit with prim shoes in it. With folders, you copy the folder or "save as" into the folder, then drag the prim shoes in. If you want to change the prim shoes, you can do it through the inventory or through the appearance editor. If you want to put links to an AO HUD in all your outfits you can do it MUCH easier through the inventory than through the appearance editor. And you wouldn't have to change outfits to mix and match them.

But if you just want to do it through the appearance editor, you *could*.
I'm sorry, but it's not just the fact that a folder and a folder-like object are equivalent, it's that folders are *better*, they're more flexible, more versatile, and easier to deal with, and just as efficient. And this is a debate that has happened over and over and over again in every aspect of computing, and using a common folder mechanism wins out over building multiple specialised objects in so many ways that specialised objects should be a last resort.

Apple's gone from multi-fork files to application folders. Microsoft uses folders for the start menu and for favorites. Applications that use folders instead of special-purpose files are in general much more flexible and useful... even if they have tools (like the appearance editor, in this example) to hide the difference between the two.

One thing you could do for this would be to make it a shortcut to a folder, because when you wear a folder containing other folders you get all the objects in the contained folders as well. Then you could just change the widget in the folder.

Another advantage of aliases over special-purpose objects.