A way to block avatars from being exported as resopackage while still allowing free usage ingame

[alexderpyfox]

Is your feature request related to a problem? Please describe.

Basically for free demo avatars that are for use ingame only that you don't want to be exportable as resopackage

Describe the solution you'd like

A way to make it not exportable but also allow others to use

Describe alternatives you've considered

I think this could be a Exportblock component that can only be removed by the person that added it but still allows others to use and save the avatar to own inventory

Additional Context

Avatar protection exportblock

Requesters

No response

[bdunderscore]

Related: #626, #1103

[ShrikeAlvaron]

Correct me if I'm wrong, but if your issue is that you want to ensure an avatar is only used in Resonite, exporting it as a .resonitepackage would still only be useful for importing back into Resonite anyway. And even if someone tried to extract the mesh from the package, it would be no different to trying to extract it from in-game and thus result in a static mesh without blendshapes or rigging. So, I'm unsure what the need for this is.

[ko-tengu]

I absolutely see this as part of the eventual harder permissions, but the obvious use to me is the stated demo avatars. Having a world where you can try on an avatar that has watermarked textures and notices that you're demoing it, but not being permitted to save it to your inventory so you can't go in and strip out the demo parts. There's also other things like licensing agreements where being able to give the avatar out as public is acceptable, but redistributing it as a package isn't permitted.

[Amunak]

Having a world where you can try on an avatar that has watermarked textures and notices that you're demoing it, but not being permitted to save it to your inventory

This is a bigger issue with the simple avatar protection not having any options currently. I think this could be solved easily by having an option to allow equipping a protecting avatar, but still preventing saving it (or exporting it).

With that being said...

There's also other things like licensing agreements where being able to give the avatar out as public is acceptable, but redistributing it as a package isn't permitted.

In my opinion you should always seek permission from avatar creators to put their limited license avatars into Resonite, explaining to them what it means and while there are some protections in place it really doesn't stop anyone even slightly dedicated. And let them decide if they want to allow it.

Then if they want to you might also come to some decent agreement, and they might event want a .resonitepackage to distribute on their store or whatever.

[epicEaston197]

Correct me if I'm wrong, but if your issue is that you want to ensure an avatar is only used in Resonite, exporting it as a .resonitepackage would still only be useful for importing back into Resonite anyway. And even if someone tried to extract the mesh from the package, it would be no different to trying to extract it from in-game and thus result in a static mesh without blendshapes or rigging. So, I'm unsure what the need for this is.

That's exactly what I was thinking

[lxw404]

The team has said repeatedly in the past¹ that SimpleAvatarProtection is not going to be expanded upon further since it has already well pushed past its original purpose. If you just want an avatar to demo in a world, you can already just lock down the permissions of the world itself to set all users to spectator, prevent export, save, and spawning additional items. There have been worlds that do this already to allow you to demo avatars.

Hard permissions will cover any other conceivable use case that you'd want to restrict.

Footnotes

1. https://discord.com/channels/1040316820650991766/1249823609401118901/1250238228477513799 ↩

[gentlecolts]

you want to ensure an avatar is only used in Resonite, exporting it as a .resonitepackage would still only be useful for importing back into Resonite anyway

this is missing a "for now"; if a resonite package has enough information for resonite, it has enough information for anything else, and could be reverse engineered. Additionally, I even personally opened up a ticket #2335 for expanding resonite package support to other applications (though it has since turned into a broader interop discussion), the format is not an impenetrable black box. This is fundamentally a security ticket and security cannot rely on the obscurity of the format.

I think the answer I'd expect from the team is that hard permissions are what we're looking for with this ticket (even if I have my grievances about how long it's been a vague hypothetical), as I believe that will serve as the more general idea of "preventing specific content from being re-exported without the author's consent" that this ticket seems to desire.