I find it hard to see what’s actually different then?
In my eyes your 2 response essentially mean the ‘private’ asset becomes public anyways if you add it to a game.
Is the only usecase where I have a game, upload a private asset into it and allow someone edit access, but no permission so they can’t see/steal my asset?
Being honest this all sounds very confusing to deal with (also very niche?).
I can’t set the Template using the AssetId, says I’m not authorized when I’m the one who uploaded it. Failed to load image. User is not authorized to access asset.
What happens if someone who hasn’t been granted permission to use a private asset (e.g. models and meshes) gains access to it–whether due to a technical oversight, incorrect sharing settings, or by obtaining the asset through unauthorized distribution (e.g. it being leaked or inserted into a game they don’t own or manage)? How does the current permissions system respond in such cases, and what safeguards are in place to prevent further misuse, especially when the asset ends up in experiences unfamiliar to the original creator?
I think there would be a workaround, for meshes that are set to be restricted, but are used in catalog items, where they could make them not show up in studio but allow them to show up in games.
This way people wouldn’t be allowed to download the meshes anymore or export them.
I’m sure it would be possible to make them show up in the roblox player client but not studio, because there’s many differences between the 2 versions already, so I don’t think this could be impossible.
So effectively asset permissions are meaningless because we cannot revoke permission given to people we no longer want to have access to assets.
Frankly its very weak reasoning for not including essential functionality. Why bother granting people permission to use your assets if you can NEVER revoke it?
Please consider changing this, the entire asset permission system is meaningless without it. Things happen, people can change or violate their contracts / terms etc. and should have asset permissions revoked.
If people cannot maintain a healthy relationship with someone who permits them to use their assets, its their fault if their game breaks because not only have they failed to maintain the relationship but also have a game that doesn’t perform checks and makes assumptions that assets exist, especially when simple scenarios such as APIs being down and thus assets being unable to be loaded could equally cause the same outcome for scripts that make such dangerous assumptions.
Sorry but frankly the logic makes no sense and only harms the entire purpose of the asset permission system.
And that’s ignoring the fact that many years later we STILL cannot private assets (especially audio assets) that were kept public because they were under 6 seconds in length. I am aware of a game that uses my audio without my permission and I cannot revoke their access to it. Please rectify these issues rather than using flawed logic to harm developers for developing on the platform.
Great to see expanded asset sharing! Thanks for this update.
Any possibility of similar sharing/selling features for ModuleScripts in the future?
Selling complex systems in ModuleScripts is hard due to lack of any code protection. A potential solution could be a sandboxed module whose code is not exposed (for core logic, no direct game state changes) that interfaces with a separate, readable script. This would let buyers see the interaction while protecting the module’s core code.
This could really help developers sell tools and boost creation efficiency. Are there plans for something like this?
I have some doubts about this. It seems like it broke the permissions for a lot of stuff… I made a post earlier about being unable to use classic shirts/pants in shirt/pants templates in studio.
Now I came to realize it might affect more than just that. I’ve been unable to use a FACE image that was previously usable.
Hi, May I request more informations, since shirt/pants is not in scope of our asset permissions, only tricky part is some legacy permission issues over the InsertService.
Would you mind share me the entire workflow to help me reproduce this issue if you don’t want to expose those information, you can DM me:
Asset Ids (both shirt, pants, images)
who own those, and how do you insert them?
experience(universe id) you are trying to insert to.
On other hand other, have you tried to use our new permission page under creator hub → creations → image → permission tab and grant experience permission to see whether your insertion will works or not. (sometime it require restart studio after permission grant done, given we saw some local cache issue before)
Whenever I import anything from toolbox, a ton of warnings appear (sometimes errors), even though I can still import the object just fine. It also appears to crash toolbox sometimes because of this.
hi for this issue, it’s also not a new issue, permission will unlikely work with a unsaved place, given unsaved place’s placeId is 0. Like the suggestion there, pls save your experience first to has a placeId first.
