I can use this information to prevent the error I suppose. But why wouldn’t these be allowed?
They’re public assets from the toolbox, so I believe they should be able to be uploaded with. If there’s no way to tell that it’s for public use, and you can’t private them, then I understand if that’s not possible. Otherwise, all public assets should be allowed to be uploaded inside packages ingame!
hey excuse me what exactly is instance:new()?
Does it make a new anything?
I know this is off topic but I can’t post anywhere else
hi @vopwn55 we are trying to start with limited functionality as we launch this new capability on the platform so that we can evaluate all aspects of the user experience. We plan to support GUI in the future!
hi @bluebxrrybot you are exactly right - we want to ensure that only the assets that creators/users want to share publicly are allowed to work with functionalities like in-exp creation saves.
Currently, another team is working on adding permissions to the asset system so that asset access can be controlled on the platform. As this new functionality lights up, we expect APIs to respect the level of access specified at the asset level. For now, we are starting with more restrictions on the API to ensure we are protecting users’ content as we learn and grow the new in-experience creation functionality.
hi @L3gendary_pr0 this currently doesn’t exist. I’d love to learn more about your use case here - when do you think creators would need to delete in-experience created assets? Do you think this requirement changes if users “buy” to save from in-experience?
Hello,
I am receiving errors:
This feature used to work upon release and does not work as expected anymore.
Are there plans to change this behavior? If not, are there workarounds for my scenario of exporting player’s builds again?
Edit:
Please try using the API and leave your thoughts in the comments below!
Ah. Well, my thoughts are as follows:
This is an extremely restrictive change and prevents exporting a hand-built model that happens to have a safe simple roblox-uploaded face texture.
Is there a rough ETA on “Allowing the ability to import creations back into an experience”? Knowing if this feature is around a month away vs around a year away would help tremendously with current large scale developments.
doesn’t seem to work when the model is a npc that has any UGC content on it
hi @Vurse we’re focused on expanding the functionality to Avatar items first. Our exploration of importing creations back into experiences will be sometime next year. Can you tell me more about what kind of experience you want to enable with the import?
Saving player-made unions. Since we have no way to access union IDs we can’t save & load player-made unions back into the game unless we have each player sit in a loading screen for a few hours while we re-union all their data every time they join the game.
Is it really necessary to have this strict of restrictions for packages?
If a game already includes a mesh or texture, it should be assumed these assets are already available publicly, otherwise where would they be from? If someone released their item on the marketplace, why would they have a problem with it being included in a package? Its simply an extension of it being publicly available.
Of course, in some cases certain meshes / textures could be taken that aren’t public, but I see this as a rare scenario that could be dealt with simply by moderation and reports.
Having the game owner be required to own every mesh/texture in a game heavily limits the usefulness of this feature. It also makes overall asset usage from the marketplace much more tedious if you plan on using it - you would have to manually put every asset you need in your inventory, instead of just copying an ID or sliding it into studio.
In my case, I was hoping to use this feature for a game where you use ingame tools to create a scene, and that entire scene could be saved via the use of packages. Because many of the assets I use have textures / meshes / catalog items I don’t own, this would make my entire idea impossible, and for reasons I don’t think are really necessary.
This was a new feature I was really looking forward to, now just disappointed with the restrictions.
Ok. So. This could be used to make In-Game Game Engines, that you could Export into packages and then load into Roblox Studio!
Hey! I’m also interested in the ability to import packages back into experiences.
The game I’m working on currently revolves around UGC, and the build tools I provide players with are very granular. Previous versions of my game have had problems with players building inappropriate objects, and I could never figure out a scalable way to discourage this.
When I first learned about this API, I was hoping it’d allow me to offload my moderation concerns, since:
The packages created from in-experience are subject to the same moderation rules as any other Packages or Models on the platform. As part of save, the package will be automatically submitted to moderation.
My game can’t utilize this if players aren’t able to load packages back in, however.
I’m having a hard time coming up with any use cases for this API that don’t involve the ability to import things back into experiences. What does your team envision developers using this for?
Any progress on allowing different AssetTypes to be used with the function (PromptCreateAssetAsync)?
This will be interesting to use…
We have temporarily disabled this feature to resolve an issue. We will follow up once it has been enabled again.
Will the people who were affected by the exploit be brought back?
Most likely, if they appeal, i hope they brought those account back
Is there an expected ETA of when this feature will be re-enabled?
How was this exploit possible though? Did an engineer accidentally set the CoreGui ZIndex for the prompt UI below or on the same level as other UIs? Or did the exploiters find a way to render their UI above CoreGui?
