Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abuse game:GetObjects for live-sync #205

Open
LPGhatguy opened this issue Jun 28, 2019 · 8 comments · May be fixed by #786
Open

Abuse game:GetObjects for live-sync #205

LPGhatguy opened this issue Jun 28, 2019 · 8 comments · May be fixed by #786
Labels
impact: high Major blocker for Rojo users, or stops people from adopting Rojo. size: medium type: enhancement Feature or improvement that should potentially happen

Comments

@LPGhatguy
Copy link
Contributor

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.

@LPGhatguy LPGhatguy added the type: enhancement Feature or improvement that should potentially happen label Jun 28, 2019
@Kampfkarren
Copy link
Member

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

@LPGhatguy
Copy link
Contributor Author

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.

@LPGhatguy LPGhatguy added impact: high Major blocker for Rojo users, or stops people from adopting Rojo. size: medium labels Jun 30, 2019
@Reinitialized
Copy link

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.

@Kampfkarren
Copy link
Member

@DBReinitialized That's basically the same as #169

@Kampfkarren
Copy link
Member

Kampfkarren commented Aug 29, 2019

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

rbx_dom and check scriptability?

@fredgig
Copy link

fredgig commented May 26, 2021

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?

@LPGhatguy
Copy link
Contributor Author

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!

@Kampfkarren
Copy link
Member

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

Can confirm, it does.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
impact: high Major blocker for Rojo users, or stops people from adopting Rojo. size: medium type: enhancement Feature or improvement that should potentially happen
Projects
None yet
4 participants