This is a great tool and a wonderful patch to fill in the gaps. Everyone can now have a good simple way to make secure backups of their builds. Thanks very much!

Way to be two faced greg.

jk, I <3 you.

Anyways I am going to be badass and tell what LL has already released in their source code just no one uses it. So with this you should be able to get textures of your own avatar and other avatars. And thanks to dream for releasing copybot but no ability to download textures. Here is that ability. Your welcome xox.
in llviewermenu.cpp

class LLAvatarTextures : public view_listener_t
{
bool handleEvent(LLPointer<LLEvent> event, const LLSD& userdata)

};//neil

go down the page add this

addMenu(new LLAvatarTextures(), "Avatar.Textures");

if you know how to create a viewer you should be able to add it to the pie menu.xml

and if you want to be even more badass. Go to lltexturectrl.cpp and make it so u can either copy the asset uuid
append(mTexturep->getID().asString());

or even download the texture . Its your choice.

So there you have it now you can download the textures instead of recieving a key which has no use other then putting the texture on the object.

I would rather have the real texture.

Rock on to LL's destroyers thanks griffers and friends and descrete and now me.

If you don't have anything constructive to contribute, please don't look at this issue.

This is really excellent code, thank you again discrete ^ ^

I am just saying they have the ability to view textures in copybots well here you go. LL already contributed to it in their main binary source code.

Yes thanks again descrete. But thanks to me a patch to view textures and possible download if you know how to. That should also be implemented in the LL source code under file-save texture as.

Your welcome for my contribution as being constructive as discrete.

heres another patch...

on the .xml files do this instead of their way
<menu_item_call enabled="true" label="Export" mouse_opaque="true" name="Object Export">
<on_click function="Object.Export" />
<on_enable function="Object.EnableExport" />
</menu_item_call>

You might feel oh so proud you wrote that but that is not a reason to publish it. Hacks like this should NOT
reach mainstream use. If it does, the ONLY effect it will have is that LL will take precautions to make it impossible;
and that spoils it for those who ARE being discreet, and for you, and for those that really only legitmately use it
to make backups of their OWN work (that they have full permissions for thus).

Be professional; hack away - but don't make your work public.

I've had this code for months, and up until now, I indeed did not decide to publish it, despite the fact that copybot already exists and performs almost all of this functionality, if not more in some ways.

I decided to publish it at this time because some public viewers also already have this feature available for all, and some who do not are planning their own homebrew solutions. I figure that adding my own solution to the mix will help to either standardise things or at least provide some more options for the implementation.

Yes, it is too simple to circumvent permissions, and it always has been. No one has needed this patch to accomplish the duplication of prims.
I didn't publish this patch because I'm 'proud' of it. In fact, IMO, the code looks like ass and could be written much better.

If you think it's too simple to circumvent, or have code improvements for it, why not post those then? We could even have the original stricken from the site. Your current comment contains none of those, and adds nothing to the conversation.

no I add nothing to the conversation in terms of code. That is exactly what I am NOT doing!
I am calling upon everyone to STOP posting patches like this.

I know of several hackers (in the positive meaning of the word: "excellent coders") that wrote their own version of
this and ALL of them based their code on VWR-4165. Imagine what would be the case if that was never posted?
This patch makes it ever easier for not-so-good-coders to actually start USING it (the wrong way). Good coders
could already do that, you opened the way to a much larger group of people.

The argument that other "viewers" already implement this or are going to implement it is NOT an arguement;
if those viewer respect the ownership of objects and only allow people to make backups of their own full-perm
stuff than I only welcome that. If their source code is open source however, then I strongly discourage them to add features beyond what you you posted. In this case open source (available patches, or code) means that you can laugh about that "respecting". I wonder what you were thinking when posting this here saying it respects the ownership. Surely you're not THAT naive? I think you knew that people will use it without that protection and you are obviously ok with it or you would never have posted it.

Oh, PS: The patch at top checks if you're trying to export a full-perm object.

What Discrete is getting at is that there are freely available viewers out there with NO permission check, anyone already has access to this import/export functionality for any object. There isn't anything LL can do because prim information needs to be sent to the viewer in order to display the prims, if they could, they would have done it when copybot was originally created.

Saying not to publish this code is nothing but security through obscurity, it's best that this is out in the open and everyone knows it's possible, instead of it coming as a surprise when it happens.

The assets are there in everyone's viewer for the taking, and they have to be there for SL to work. Copying them or not is not a technological hurdle, but merely a reflection of one's social responsibility and worldview.

Nothing has changed. Those people who want to grab assets from their viewers have always been able to do so ever since libsecondlife was created by reverse engineering SL protocols, which was long before the viewer was open-sourced. And those of us who have preferred to respect permissions out of social responsibility have always done so despite knowing how easy it was not to.

The only difference now is that at long last the few remaining content creators who apparently didn't know about this have to face the facts. Well that can only be good, especially if it stops their doom-mongering.

Did SL collapse when libsecondlife (now libomv) was created? No. Did SL collapse when the viewer went open source? No. Will SL collapse now that a few more people will have permissive clients? No, because the vast majority of people are willing to pay a reasonable price for a useful item from a merchant they value. There's no reason for that to change.

SL is safe. The sky really isn't falling, at least not for that reason.

If creaters are not paid for their work, they will stop creating. Without creaters SL will be very boring.

QUIT !

Actually posted to the wrong, tho related JIRA.

</snip>

Actually, they're not leaving at all, because the vast majority of content creators understand perfectly well how SL is designed to work, and they happily do their business under these conditions since this is the norm for all digital content.

It's only a very few who superglue blinkers to their eyes and then announce our imminent destruction by imaginary monsters. While entertaining, it's not grounded in reality.