Allow animations to be used by UUID like many other asset types
tracked
Darl Pawprint
Please make animations usable with their UUID like many other asset types already are. Currently animations are a lone wolf in that they cannot be referenced by UUID when they intuitively should be.
Currently with scripts:
- Textures able to be displayed with their UUID
- Sounds can be played with their UUID
- Notecards can be read with their UUID
- Materials, a brand new asset type, is able to be displayed with UUID
- Animations: 🙃
llGetInventoryKey and llGetPrimitiveParams/etc already implement protection against obtaining UUIDs without the proper asset permissions.
I do not think that an arcane limitation like "no animations by UUID" is appropriate especially with the upcoming improvements to animated mesh with the GLTF project, and to server-side scripting with the Lua VM project.
Log In
itoibo Resident
I have wanted anims to use UUIDs for a long time, especially for updating and selling. You can sell UUIDs from your own site, on MP, inside of SL, etc..
The problem is this getanimlist function. As long as UUIDs can be ripped using it, how do you use UUIDs? They really went weird with that one. People work hard to make anims, but they also work hard to make textures, sounds, etc., and there are no LSL functions that get those UUIDs without having perms.
If they cannot get rid of getanimlist, perhaps there could be an alternative UUID that getanimslist would not get, i.e. the anim has a regular UUID and a secondary UUID that can be used to call it.
RohanaRaven Zerbino
To all participants supporting this suggestion: Yes, please, do enlighten an animator with 15 years of experience in the full-perm business on how UUID playable animations are beneficial for us. Clearly, after all these years of dealing with various forms of theft, we need to be educated by residents with zero experience in the animation business about the benefits of a feature that enables easy theft and sends us, along with the rest of SL, down to the rabbit hole.
Darl Pawprint
RohanaRaven Zerbino You deal in full permission animations, and are concerned with theft? Your business model relies on people being honest and following the license terms you set forth, no technical measure in the world will help that.
An example use case would be a dance ball system, that like the K.R. Engineering Game System (awesome product!) allows the use of licensed content. It relies on external servers and infrastructure to manage IP licensing. This proposed dance ball system would never need to be updated, or have plug-ins installed, but the creator could easily sell "dance packs" to owners of the core system who could enable those dances without any further setup. This puts the creator of the animations in the highest seat of control, and offers an exceptionally simple setup process for the customer.
Fifteen years in the animation business you say, and this example was formed in about fifteen seconds on my part where you seem to have come up blank.
RohanaRaven Zerbino
Darl Pawprint I appreciate your thorough explanation of my own business. I wasn't aware of full-perm business risks until you kindly took it upon yourself to explain it to me!
The example you gave is truly reflective of 15 seconds of thinking. Thank you for the effort!
Your account shows very low marketplace activity, so I will take the liberty to assume you have little to no experience with SL business and economy. Yet, you are giving yourself the freedom to lecture animators with long-term SL businesses who are against this suggestion on what is good for their business. Therefore, allow me to explain a few basic things.
First of all, running a full-perm business doesn’t make us naïve or stupid. We are fully aware of the risks and nearly all the ways something can be stolen in SL, and this applies to non-full-perm items as well. With minimal protection from LL, we are largely on our own. Thanks to builders and other full-perm creators, we manage to combat theft to a certain extent. Next time a full-perm creator mentions XY years in the business, be assured they have a strong loyalty base and know how to handle theft, as it is a never-ending war zone.
Now, back to your suggestion. Let's move beyond dance ball systems, which, percentage-wise, are among the least used animation systems compared to those used for furniture and AOs. These more prevalent systems rely heavily on full-perm notecards. The most widely used animation system is, as you should know, AvSitter, which requires full-perm notecards for the script to read. Any AO notecard should be modifiable to allow users to control the settings and add animations of their choice
(Part 2 is below)
RohanaRaven Zerbino
In your original post, you didn’t mention anything about external servers or offer ideas on how that might work with animations. You simply asked for animations to be played by UUID, which would make every setting I've mentioned an open field for theft, as the UUID would have to be included somewhere in the setup. I can't even predict how long it would take for someone to create entirely new furniture animation systems or AO system scripts, and how long it would take for these to be widely adopted by builders.
After your explanation regarding outside servers, your original suggestion now sounds like you started from the wrong end by simply asking for UUID playable animations, while in fact, you have an entirely different system in mind. No wonder you received negative reactions from animators. For a start, I would suggest that you ask for new features that would support or change the entire SL animation system and wait for a couple of decades for changes to be implemented before dropping the UUID playable animation bomb.
The P system tried using setups on external servers, but it didn’t last long, and now they’re back to the classic in-world notecard setups. I’m not sure about the specific reasons for dissatisfaction with the external server setup—you might want to speak with the creator about that. From a builder's perspective, it was hell, as server setups were not reusable. Ultimately, the servers experienced an outage, causing the entire system to stop working for end users for some time.
Let’s not even start with layering animation systems.
For the limited and specific example you gave, and taking into account the time required for wide, basic implementation in the grid, it's not worth the risk and effort.
Not having full insight into the consequences of your request, nor knowledge of the various techniques and methods of animation usage, I would say your suggestion is not well thought out.
Darl Pawprint
RohanaRaven Zerbino With or without your support this request has become rather popular and tracked by Linden Lab as there is clear interest from the broader creator community. Not every change to Second Life requires each and every user to sign off. Previously I've addressed every concern of this proposal with a reasonable implementation solution to prevent theft; which you may or may not have read, who knows if you were too busy making an animation.
I appreciate the length of your response, but it's ultimately you who lack the insight into the scope and considerations of this request. The model I just described could be applied to anything from furniture to AOs which control a much larger segment of the market.
Reliance on external infrastructure is nothing new to products sold on the Second Life economy, and many of the most popular products on the platform today do so whether you see it or not. For some it is too difficult or costly to manage, but for others it's an approach to offer a higher tier of service to their customers that having that sort of capability enables. Products of this nature that are older than a decade, which are still around and kicking are examples of this.
You seem to have misunderstood the tone of my response and responded with what you think is a tone appropriate rebuttal, I'm actually shocked that someone with your claimed level of experience so easily overlooked the actual potential of this proposal, and understood that it would not create any new permission exploit vectors if implemented in many possible ways, one of which I have freely provided a specification for.
This proposal directly elevates the capabilities of your customers and stands to increase your business as a result, I think it is hasty to so quickly write it off as being authored by an inexperienced and naive nobody without consideration for how it will actually be used when it's clear that's not the case with how I've presented all of this supporting information.
I'm happy for you that you take pride in your work, but I don't feel the need to boast my experience or resort to personal attacks to support my argument for this proposal. I wish you and your business many years of increased future success under this implementation of proposal and the capabilities it will open up for your customers.
Aglaia Resident
RohanaRaven Zerbino i agree with you.
Darl Pawprint
To those clutching their pearls at a request such as this, I want to offer a reminder that the subversion of animations permissions is NOT the request here, nor is it in the interest of Linden Lab or any upstanding member of the community to ask for such.
I cannot tell you what the implemented version of this feature would look like, or explain to you what protections will be in place to protect your IP, but I can assure you that as with every other addition to Second Life that the Lindens have provided us with, it will be a well-considered balance that checks as many boxes as feasible.
I freely admit that I had a "brain fart" and forgot that llGetAnimationList existed when writing this request, but I do maintain that its existence does not at all preclude a system being implemented that allows both to exist harmoniously without violating the IP of Second Life's creators.
I gave this a moment of thought and already arrived at one hypothetical, silly and narrow-minded path way forward for this request; that being to have a public "fingerprint" UUID and a private "asset" UUID where newly uploaded animations get both and existing animations will continue being referred to by a "fingerprint" key but may also have an "asset" key copied via a button in the viewer interface that relies on server permissions to provide. This would allow any existing and future checks for animations being played to continue working while rendering any UUIDs returned by that LSL function useless to a would-be IP thief as they'd only be seeing "fingerprints" and not playable.
I ultimately trust Linden Lab to intuitively understand without being reminded that all sides to this discussion have valid concerns, and to decide on the ultimate path forward for this request in a way that makes the platform the best it can be.
gliese581 Resident
NO, NO & more NO, im animator in Sl, making animations is sort of pain in the ass, takes hours and hours of hard work, and im not wiling my animations goes all over the place by UUID, if this is gonna happens im afraid none of us( animators) will have no interest to create any more, wil be worthless
Madi Melodious
The only way I can see this working if you owned the animations to start with, or if the creator set the animations to copy/trans when up loading them.
Woolfyy Resident
Frankly the argument of robbery is a false argument. Those who want to rob know how to circumvent any protection and most of the time you find those products on opensim servers, with no way to change it as they are often based in countries where it is impossible to start any prosecution (moreover who has time and money to spend on it ?).
More globally a simple solution is to have an explicit notecard saying for example what is authorized or not, as it is already done for textures.
And at the end, the best solution is to have life upgrades with real users who pay to get up-to-date products (or new products). Those who don't pay will not pay anyway whatever we do ... It's a problem that has been known for decades in rl may it be for fashion, music etc.
Aglaia Resident
Woolfyy Resident And then???? Because there is a little back door behind your house that a robber can break illegally, that means you should give away everything to the first person who comes? It is non sense.
You are saying that because something can be done now in an illegal way, then Linden should offer an easy and legal way to do it?
And please stop teaching us again (you did it already in the feedback about copybotth) what is the "best solution" and how to run a business, this is not the place for that.
Woolfyy Resident
Aglaia Resident There are much more efficient ways to check it from server side ... Anyway go and have a sleep and you will be much more relax ... and stop interpreting what i say when you don't understand it. Good night LOL PS: FYI as far as an animation is loaded on a viewer it can be robbed the same way as copybots do, as otherwise no avatar could play an anim, dance and so on. So the problem is not on hiding anims (as no method is efficient) but tracking who uses anims illegally.
Aglaia Resident
Woolfyy Resident I'm not gona have a sleep now do you know why? because i am working on an animation, as i do every day of the year, as all my business, and thus all my RL incomes, rely on animation. That's the difference between a hobbyist and someome who struggles to try to make a decent living of their work: we are bit more worried about this subject, and yes i won't sleep very good after seing that this feature has been marked as tracked.
PS: You obviously love to teach people but i know how a viewer works, thanks.
Woolfyy Resident
Aglaia Resident To give you an idea of what would be really efficient i added this feed : https://feedback.secondlife.com/feature-requests/p/tokenize-right-transmission-to-control-users-not-respecting-distribution-rights
In modern times only tokens are efficient, UUID being a feature not done to follow use rights.
Good night !
SL Feedback
Hello, and thank you for your feature request regarding the use of animations by UUID. This particular suggestion has been brought up in the past and is currently tracked. We have no estimate when it may be implemented, but please keep an eye on future updates. We appreciate your input and encourage you to continue sharing your ideas to help improve Second Life.
Aglaia Resident
SL Feedback Are you serious? I hope this is just an automatic message. As mentionned and explained, this feature would mean the end of quality animations in SL, because no animator will make animation anymore if anybody can play them without buying them. Can you please tell us more about it and you plan to do? Will you first deprecate the llGetAnimationList? As long as this function exists and returns uuids of played anims (even if not full perms), i don't see how you can allow to play anims with uuids without killing the animation market on the spot.
gliese581 Resident
SL Feedback , How can you guys espect we animators gonna survive?? also whats gonna happens when we do not sell anymore in Marketplace (since anyone car rip our animations via UUID?) and Linden Labs do not get any commision of our sales??, I pretty much believe, Animations is possibly one of the most turn overs of marketplace selling, this is not a good idea is a suicide!, do you consider we will want to create more new animations all the time when we upload a new animation , a new proyect is just send out to open public for free?? , I really hope you guys do not make this, will kill us all and will be no new animations in SL again.
SL Feedback
tracked
RohanaRaven Zerbino
From the point of full perm animation creator - absolutely not!
Madi Melodious
RohanaRaven Zerbino Yeah, this is not a good idea. When you first read it from a non-animator point of view it seems like a good idea.
As a scripter, "Hey I can write a dance hud, buy one batch of animations, and then just hand it out to everyone and they never have to buy animations." Sweet!.
When you sit down and think about it, no. The fact that you would be able to do that is not a good thing. I prefer to support animators and buy animations. It encourages them to make more.
Grace7 Ling
I agree with Aglaia. Animations are different from textures and sounds in that llGetAnimationList would get you the UUID of the animation even if you don't have full perms to the animation. So unless LL can protect the IPR of the animation creators, the OP's suggestion cannot be allowed.
What if the suggestion was changed slightly: allow animation to be used by UUID if the script owner also owns the animation.
Load More
→