In my opinion, the CommandBar and UserPlugin run contexts should be allowed to bypass this block, theres some cool stuff I want to make with these APIs in the plugin space but cant if 99.9% of games cant even enable the API to begin with.
Plugins supersede what a game can do anyway, and if these instances are unarchivable, there’s no real concern to allowing plugins unrestricted access to these APIs.
Been following for the past months what is arguably one of the best Roblox updates ever to this day. Glad it’s finally available in published experiences!
Like other developers, I understand the reasoning behind limited permissions to modify assets. But it would be frustrating to re-import and re-organize hundreds of meshes to be able to use the new APIs on them. Some use cases would be assets published in an alt account of the same developer, or by different developers working in the same studio or group.
Perhaps it would be reasonable to enable mesh & image APIs for assets created by all users with experience editing permissions in a single group. Could we have a more flexible update on this soon?
Also,
yay
Thank you all for the hard work behind these updates!
Is there a way to lock an EditableMesh by exporting it to a MeshPart to get that memory back?
In a game of mine, I plan on featuring them quite often where certain generated meshes will not need to be updated/changed and will remain static versus others that will remain dynamic.
I don’t care how many features Roblox gates behind ID verification, I’m not doing it.
Alas, poor Yorick… refusal to give your ID to ROBLOX has locked you yet behind another feature… can we stop this?
Under Studio Edit mode (not in play solo or testing) you should be able to call these APIs in command bar and through plugin without turning the toggle button on.
If it’s giving you an error, it’s a bug. Please let me know how to reproduce this.
this is a cool feature cant wait for it to be released how do I join the roblox app beta on Mac and mobile
Editable Meshes and Editable Images are awesome. Keep it up Roblox!!!
I managed to make this in under a day with a single paper. I was able to do everything other game engines could do on Roblox with nearly no issue. it’s extremely impressive. Running at 240 fps with ~116 million triangles
Enough to make me not bother using Editable* already.
Under no circumstances I’m doing this. Ever.
Write a script to create an image and apply a random pixel to it, save it as a plugin, open a game with the APIs off.
local AssetService = game:GetService("AssetService")
local Image = AssetService:CreateEditableImage { Size = Vector2.new(1, 1) }
local pxl = buffer.fromstring("MEOW") -- idk i just needed a four byte string
Image:WritePixelsBuffer(
Vector2.zero,
Vector2.one,
pxl
)
It should emit the error, I should add, this is a team create enabled server if that might be the root of the issue. (it is)
Two of these examples (source code and StringValues) are on-platform and presumably moderated by the developer who inputted the data; am I reading into this wrong? DataStores also seem like a common use-case to save user-generated creations for future-use; is there any reason why these are not considered “best practice”?
I would have been under the assumption that as long as the source of the asset is from a Roblox-moderated source (for example; thumbnails API, or similar); or a developer controlled source (for example; to store user-created images on my external database in-which I have informed the user of the fact and have set up proper security permissions); I would be fine, assuming that I take the steps to moderate violative user-creations on my side of the equation. Am I correct in saying that?
I will commend the team for listing these as “best practices” rather than more rules though, it shows that the team is aware that there are a wide variety of use-cases and are willing to act as “guides” to following the ToS rather than acting as “law-makers” trying to force us into doing so (by cutting-off any possible iffy use-case, with new and unnecessary rules).
I’m still really hoping for the permission restrictions on loading assets to be calmed down quite a bit in the future, though. 
Oh man.
The only thing holding me back from ID-Verifying is the one id per account limitation, I wanna verify my alt (group holder) to access features like these, while also verifying my main (this one) to access features like Voice Chat.
Is there any ways to verify two accounts with the same id yet?
Does this mean I cant save UGC assets in DataStores then load them up for usage again at another time. I should add a report feature will exist and I’ll also make it so I can review anything in this datastore, and optionally purge it.
I believe this is the position taken for in-game UGC right now so it would be a little backwards to not allow it for editable objects.
I want EditableMesh to be able to use with mesh that having a bone also(make it animatable)
Happy to see these APIs finally released!
Are we going to be seeing any bulk API methods for EditableMesh in particular? Current speeds are definitely good, but bulk methods would avoid a ton of extra overhead and scale much better for lower end devices for my particular use cases.
Is there a reason DrawTriangle on the images is still locked to roblox scripts? None of the other drawing methods currently are, so it makes no sense to me why this one is arbitrarily locked.
finally thx good update thank you 
It’s reasonable that you would need an ID to be able to use the API in live experiences, but I feel that it shouldn’t prevent you from using the API at all in Studio.
It doesn’t make sense that I am unable to work on scripts using this API that I could previously while it was in beta.
