Why not just always use this for rbxm/rbxmx files?

Performance, and support for stuff not managed by Rojo. If we always save to a model and load from a model, delete the existing model, and replace it, changes will be super noticeable.

So while we could use GetObjects for models or for everything, I think we can do a better job with individual property updates instead.

You could also abuse the fact that Studio can run custom CoreScripts and utilize the VSCode extension to inject one into Studio, thus granting access to the RobloxScriptSecurity tagged APIs.

@DBReinitialized That's basically the same as #169

I'm not sure how we should try to detect models that fall into this scenario

rbx_dom and check scriptability?

Any update on this @LPGhatguy ?

Not being able to sync MeshId properties with .rbxmx files from our Rojo project to Rblx Studio is a deal breaker for us, and we're limited to only syncing scripts. Are there currently any other ways to handle MeshParts?

I recommend using fully-managed Rojo to work with MeshParts right now, which is currently the only way to have Rojo manage lots of things. This will likely mostly work for people to live sync things that they're already using rojo build for!

This will likely mostly work for people to live sync things that they're already using rojo build for!

Can confirm, it does.