rojo
rojo copied to clipboard
Abuse game:GetObjects for live-sync
This would solve #161 and be an alternative to #169.
There's a great API that loads models out of the content folder I didn't know about!
game:GetObjects("rbxasset://models/AvatarContextMenu/AvatarContextArrow.rbxm").Parent = workspace
Just like what we wanted to solve with a RobloxScript security API in #169, we should be able to use this to load in models that Rojo isn't able to live-sync. I'm not sure how we should try to detect models that fall into this scenario, and some exotic service properties like Lighting.Technology
are still in a rough spot.
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.