Today, we’re releasing the Studio Beta for Auto-Reimport, which detects changes to the source file behind an instance and automatically reimports it whenever that file changes on disk, without manually needing to trigger the reimport action.
How To Use Auto-Reimport
To begin using the feature, enable “Auto-Reimport” from File>Beta Features in Studio.
Auto-Reimport is available on any instance that already has saved Reimport settings. To save these settings on an instance:
Right-click the instance in the Explorer, open the “Reimport” submenu, and select “Auto-Reimport”. If the option is not visible, you first need to configure the instance’s Reimport settings. An icon in the Explorer will indicate instances with this option enabled.
Turning Auto-Reimport on will run a reimport immediately.
When the file being watched by Auto-Reimport changes, the instance will automatically be reimported.
Reimport does not version assets: Every reimport or auto-reimport uploads new meshes and textures and produces new asset IDs.
Auto-Reimport is enabled per-session: Auto-Reimport is not saved with your place. This means that if you restart Studio, it needs to be re-enabled for each instance.
What’s Next
We’re working on asset versioning for meshes and images, so that new asset IDs are not created on every iteration. Please share any feedback with us below. Thank you!
For exporting the closest thing is probably PluginManager:ExportSelection(), but that only works with .obj files. There’s also Plugin:PromptSaveSelectionAsync(), but similarly, that only works with .lua, .rbxm, and .rbxmx. Even if you could get the raw data through EditableImages and EditableMeshs, I don’t think you’d have any way of exporting it *.
* Technically, so long as you’re willing to write a custom application you install to your computer (or even something like a simple NodeJS script, or you might be able to find a Lua runtime that works for you too), you actually can export files by running your application in the background, having it act as a local HTTP server, and then using HTTPService to talk with that locally running server and have it perform arbitrary tasks, including creating a new file. I’m pretty sure this is actually how Rojo works internally. This is also excessively convoluted though, and a proper solution would be nice.
If there’s anyone at Roblox who works with plugins that happens to see this, I’ve said it before, but please, can we get these APIs unified under a single service (or group related APIs into a single service, all three functions above deal with the user’s local filesystem, yet they’re spread out across three different services / classes). I knew about most of these APIs off the top of my head, and yet it still took me awhile just to figure out which service they happened to be under, and this gets even worse if you don’t know about these APIs in the first place. At the very least, could we get something like a “See also” section on the Plugin page please?
Would you ever consider temporary/preview/local assets that aren’t really published, to prevent clogging the inventory or roblox servers with prototype versions of meshes and textures?
does this mean that every reimport change results in the mesh/image being moderated? if so, what prevents false moderations from appearing from the reimport? why not treat the reimported mesh/image as an editablemesh/image instead of uploading each time?
Yes, I am aware of those APIs, but i figured that this would require the user to select a export directory manually, and that is not something you want from an Auto Sync plugin.
The route I am probably going to take, is to have an option that turns all meshes into editable meshes and exports that data and then rebuilds the mesh from that data locally.
This way, I should be able to export both the meshes and all image data from a Roblox place to the local machine of the user.
Or a different way would be to create a temp editable mesh with the same content as the original mesh, and then extract the mesh data from the editable mesh, before deleting it, however this would not let the user edit the mesh locally and have it update in Roblox, thus also not being ideal for two-way sync.
I am aware that that is how Rojo works since that is also the same way my project Pesto works, I recommend you check it out and even try the free version for yourselves.
And I also agree that the way some APIs are sorted in the documentation is very weird and makes some of them hard to find, a semantic index would be really nice and could fix this.
who is the new team that is pumping out all of these amazing updates ??? They deserve all the recognition in the world. I love them. Roblox dev team please continue on that trajectory
flooding the uploads page