It’s a temporary gamepass for a very early access feature. Last one to defend Roblox Corp when it’s not due, but from how it seems, they have to make several modifications.
Asset privacy here is moreso ensuring that nobody can download your asset except when they’re connected to youi experience. It’s a very basic fact that you can’t prevent a mesh, sound, or anything, from being leaked 100% as it’s just not how computers work, sadly.
Finally that figure of $400, the target for this early access is people who see 30k as pocket change, so that most likely DevEx, count more like $100.
roblox did the exact same thing with group transfers. paywalling features that require human intervention is nothing new for them, I do not see how people are making a big deal out of this when they have stated they intend to make it completely free. their intentions are pretty clear here
It’s about Roblox using a GAMEPASS in ROBUX for people to TEST their stupid BETA feature. does that seem professional?
that safeguard already exists. it just prevents developers from using other developers assets, but any exploiter could circumvent it by joining a game and having their asset in memory.
I’m not sure if GDPR would affect this; if so, it would make it even more complicated to solve.
On another note, extending my idea, they could allow creators to choose if they want to agree to the rule. If they don’t agree, they should still be able to publish the asset, but it should affect games that already added the asset and become blank when made private. There should be transparency to other creators that this asset can affect experiences that added the once public asset, making it blank in those experiences. This would create a division between assets with completely controlled privacy (when not agreeing to the term) and safer assets for other creators (when the creator of the asset agrees to the term). Although this division may complicate matters, if you have a more proper reasoning and solution, please let us know.
To be fair, blocking the loading of assets entirely is a breaking change since when an asset fails to load, there are side effects to that. If a contributor decides to revoke their asset (which could theoretically be for any size of reason, big or small), they could unknowingly break the entire experience depending on how well the experience is developed, or it could be a key-asset used in several places leading to missing geometry and an unhappy fan-base. At that point, some creators of experiences may prefer to require all contributions be made through assets uploaded by them, revoking your permission to revoke access anyway and being much more inconvenient for everyone.
Just before it is said, yes I’m aware that the archive feature can be used however this can’t currently be used on Images (not decals, they are different) which this update covers and is more of a last-resort for most since it affects everyone involved rather than revoking access on-the-fly to a specific experience.
Perhaps more protections should be put in place before you grant permission, as so that ‘hacker’ case is solved, but just given how reliant Roblox is on assets being able to load, having on-the-fly asset granting and revoking is unfortunately a liability to many developers and experiences’ longevity.
Any chance we’ll also see the ability to whitelist specific non-owned experiences to use our assets? This has been a massive pitfall with the current audio permission system since you need to either have full edit access to the experience or be friended. One of which is very risky to grant, and the other only has a limited number of slots.
I can only hope this is a requirement and not just ‘advice’ because otherwise, I can’t wait to have my error log filled with “asset failed to load”…
Wait, will it be possible to directly set the privacy of “Image” assets (not Decals)?
Does this mean I can finally restrict access of all my Images that can’t be archived (because they aren’t attached to Decals/MeshParts), and essentially “delete” old clothing assets by just privating the underlying template Image?
unpopular opinion given the majority of replies in this thread; this is honestly a good beta and it is understandable to charge 30,000 Robux for it ($105 USD) to offset the costs for manual support given by engineers; i feel like the point most people miss in this thread is that it is still in a very early stage, it is severely limited and will require a lot of manual support, it isn’t all about flipping an FFlag and enabling it on an account. it isnt a feature that is going to be used by the vast majority of developers at the moment however it would only really be used by larger companies that have a requirement to protect assets (think studios doing brand work)
How about you allow users the option to make privates audio assets to public again before you roll with this change? It’s been 2 years and there hasn’t been a change with that. How would we be able to trust that the same lack of update on the previous system wouldn’t happen again?