With this API + being able to convert a camera or viewport frame into an editable image, I would be able to stop using expensive viewport frames in my UI to preview custom characters on small thumbnails. This would be a huge perf boost for me because I can have 20+ different characters in the UI at once. Would appreciate higher prio on this. I just need to take a snapshot of a viewport frame and upload the result with background transparency. That would be good enough and is honestly expected plugin functionality.
3 Likes
I have started rolling out a change to allow temporary images into EditableImage in the studio Edit DataModel. They still wonât be allowed in Play mode and for clients due to some privacy concerns with captures being put in EditableImage at runtime, but this should help with use cases for CreateAssetAsync!
3 Likes
What a cool plugin!! Yes, weâre super excited about the possibilities EditableMesh/Image open up for creator plugins. But we have to make sure we do it carefully.
Note that we are also investigating first-class Studio features for Editable* objects, which will, among other things, allow for the creation of assets from Editable*s through straight forward built-in UI.
If these features end up being good enough for you, your plugin might not even have to worry about creating assets for your users 
1 Like
A long time ago there was talk about being able to publish models to playersâ inventories from inside of an experience. I run a game about building, and my players are always asking for this export functionality. Whatâs the status on this? Is it still in the books or is it currently shelved?
1 Like
To clarify, I mean Models. Not meshes. That thread is about Editables iirc.
Ah yes, I believe we briefly had a beta in-experience Model publishing API that we had to roll back for security reasons. That API is very much still planned and as far as I know will be the same API that support Editable* publishing from in-experience.
1 Like
I believe you do, and Iâm hoping this comes to fruition sooner than later as well. Would love to use it for in-experience publishing of EditableImages.
Thanks for being open with us regarding what the plans for the future are.
1 Like
This method needs to be behind a prompt for each call, while I get why youâve disabled it for cloud plugins (which is a 
from me for now), the risk is still there with local plugins if theyâre just allowed to upload assets with no extra validation.
If the ultimate goal is to put this behind a plugin permission (or an evolution of that system), I still think we need a method to gracefully handle if a permission is granted or not. The current solution is to hackily use pcall to try and identify if the permission is given or not. This is especially an issue for methods that can fail for reasons other than a permission not being granted (ie HTTP).
1 Like
Hey Iâm trying to upload a Model but 2 of my newer UnionOperations are causing it to fail
However, it works fine when I destroy these UnionOperations
This could be related to this beta feature which I have now disabled
Thank you for the input, I agree, the functionality we are building for review of upload requests from cloud plugins could also be used for local plugins.
The API will not leave explicit opt-in beta (i.e. ignore the auto-enroll switch) until we have full, and safe, support for store plugins. So for now, you can guarantee you are safe by not enabling the beta.
We are also considering a switch to enable/disable the API entirely for local plugins too which would default to disabled; and I see no harm in having a Studio setting that would force the same review feature that will be available for Store plugins on local scripts/plugins too.
One thing that is important however, is that there is an option to enable unprompted upload, one of our goals is to make it such that user-plugins are able to re-implement asset features on par with our first-party features, like the 3D importer. It would be unfeasible for a custom import plugin to import large 3D scenes with potentially 100s of meshes/textures if each asset needed to be reviewed individually. We also recognize that these APIs are useful for automation, which prompts nullify.
But that does not preclude the ability to opt-into or out-of different settings matching different risk profiles!
Interesting, it is very unlikely to be related to that other beta feature.
For transparency, a few different Studio/engine features rely on uploading assets behind the scenes to work properly when a place is published. Sometimes, Studio will temporarily use local data that will be replaced by an asset id later.
Some examples of this are CSG unions, SurfaceAppearance (texture packs), or HSR (hidden surface removal) for layered clothing. When uploading a Model, the API traverses the subtree, and if any such data is in the temporary local state, it will error. This is to prevent you from unknowingly creating assets that will not function properly when used in the future.
In the case of CSG, in Studio, we should be able to trigger the creation of this âbehind the scenesâ data for you, but that has not yet been implemented.
I expected this error to impact Cloud Luau tasks for CSG, but not Studio, apologies for my oversight.
For now, I think this (unfortunate) workaround might work:
- Save the place to Roblox
- Try calling the API again without modifying the Unions
Apologies if I misunderstood your use-case, I am not using this as justification to not implement the functionality with EditableImage, but simply wanted to point you to CaptureService:CaptureScreenshot() in case it might be useful to you here
This is awesome! been wanting to update Packages with CI/CD for a while now
will provide feedback later when i get a chance to use it!
Am I understanding this correctly? would I be able to use this in CI/CD?
1 Like
Yes absolutely! Refer to the Open Cloud Luau Execution API Announcement for more info on the CI/CD execution context!
Hey, would this allow us to upload KeyframeSequences as Animations (that can be played back ingame)? Animation upload workflow is clunky right now and making a plugin to speed it up would be great, just not sure if that Model type would upload usable Animations or if theyâd just be uploaded as a model
1 Like
Yes, this is planned, I will need to better familiarize myself with the Animation system and distinction between KFS and Animation assets, but what matters is that we want to make it possible to create a working animation assets from scratch in pure-luau using this API.
2 Likes
For a real-world example, the Flipbook plugin is automatically published to the Creator Store via GitHub workflows when 1) a PR is merged to the main branch, which publishes to a development copy of the plugin, and 2) a GitHub release is made, which publishes to the production copy
Hereâs a link to the release workflow: flipbook/.github/workflows/release.yml at main ¡ flipbook-labs/flipbook ¡ GitHub
The meat of it is handled via Lune scripts (that call Python scripts, itâs a little all over the place atm). The publish-plugin script handles the bulk of the logic. What I wound up doing was repurposing the Python scripts supplied by Roblox in the place-ci-cd-demo repo to first upload an rbxl containing a built copy of the plugin to a Roblox experience, and then using this Luau execution task Iâm able to publish the plugin to the Creator Store.
In an ideal world Iâd do all this with Luau, but the Python scripts were able to get things up and running quickly.
Feel free to poke around and repurpose anything for your own work
2 Likes
I currently use this for my CI/CD as well, I have it build > test > publish the game to Roblox
Iâm currently looking for a way to upload/update Packages from .rbxm (model) file directly through HTTP request rather than running Luau execution task, although that is totally fine, I can make this work for my needs
thanks for sharing!
1 Like
This is amazing! Finally, I can throw away the code I wrote to convert EditableMesh to plain text .obj
1 Like