Use Built-in Plugin Injection for Improved Live-Sync

[Kampfkarren]

Right now, Rojo runs on the same security level as every other plugin which has its limitations. Things like Terrain and Union importing are going to need to go through the internal pipeline to become features that normal plugins to use. At the same time, these features are available right now hidden behind CoreScript APIs like InsertService:LoadLocalAsset. Theoretically, Rojo could install a companion plugin into BuiltInPlugins and use the content folder for symlinks, but this is a notable shift in mindset on how the plugin is developed. The steps can all be condensed to a basic command (as part of a rojo install perhaps) but the major issue is whether this is worth pursuing.

[NobleDraconian]

If it is pursued, this would allow rojo to have almost full support for loading instances from the file system. This would be beneficial because it would not only save time when converting projects to rojo (no need to seperate instances from scripts), but it would also open the possibility of version control for instances.

With this we could theoretically save a map model file to a repository, thus allowing for version control on game assets as well as game source code. This is quite common outside of Roblox, games made with unreal/unity/some engine store their game assets on the filesystem, and typically use a VCS to manage asset versions.

So from a benefits standpoint, I would say it's worth pursuing something like this.
I don't have much say on the technical standpoint, but from what I understand of how rojo works it should be feasible.

[Kampfkarren]

With this we could theoretically save a map model file to a repository, thus allowing for version control on game assets as well as game source code.

You already can, look at roads. rbx-xml has basically 100% type coverage from what I know and something like #165 would let Rojo sync things like Tags easily. I specifically mentioned Terrain and Unions as things that are completely infeasible to sync for Rojo.

[NobleDraconian]

At the moment, instance support in rojo is flakey from what I've experienced when trying to save models to the filesystem - it typically errors with ScreenGUIs and the likes.

Terrain and Unions

Yeah that's definitely another reason to do this, a lot of maps are bound to have terrain, unions and meshes. Saving these to the filesystem is not possible (or is highly unfeasible) at the moment.

[Kampfkarren]

At the moment, instance support in rojo is flakey from what I've experienced when trying to save models to the filesystem - it typically errors with ScreenGUIs and the likes.
That's solved with something like #165.

Saving these to the filesystem is not possible (or is highly unfeasible) at the moment.
Saving them to the filesystem is easy. Getting them from the filesystem is impossible.

[NobleDraconian]

Saving them to the filesystem is easy. Getting them from the filesystem is impossible

Oh, I thought it was the other way around, my mistake.
But yes, a bidirectional method of saving/loading models would be highly useful, as mentioned previously for special instances that cannot be easily serialized (unions, terrain, any other instances with 'special data').

[ozzyDrive]

Hi. Is there any update on this issue? Syncing models containing MeshParts is the only issue we've got in including Rojo with our development process.

We've got 3 options:

1. Find a way to exclude a folder from the Rojo syncing procedure and create a new folder for all mesh models in both, the client and server, partitions
2. Create folders for mesh models out of the client and server partitions
   • Will break the structure and consistency. The models cannot be imported with the current get module.
3. Don’t have mesh models until Rojo fixes the issue.
   • No idea how long it’ll take

The client and server folders (partitions) are meant to hold the whole client/server game directories with no exceptions. That's why I'd like to avoid number 2 as an option but it could work as a temporary solution, if this issue is going to be closed in the near future.

Number 1 has nothing to do with this issue but is that a possibility in any way?

[Kampfkarren]

Find a way to exclude a folder from the Rojo syncing procedure and create a new folder for all mesh models in both, the client and server, partitions
You can use .meta.json for this. Create a folder named what the folder is and put a file inside called init.meta.json with the following code:

{
    "ignoreUnknownInstances": true
}

https://rojo.space/docs/0.5.x/reference/sync-details/#meta-files

[ozzyDrive]

You can use .meta.json for this. Create a folder named what the folder is and put a file inside called init.meta.json

This doesn't seem to work. Roblox still complains: Invalid property MeshPart.MeshId: Error(Roblox: Unable to assign property MeshId. Script write access is restricted, no matter where the .meta.json file is located, or whatever name it is prefixed with (I'm not clear on whether it should be init or the folder/model's name, tried everything). I also tried "$ignoreUnknownInstances": true in the project file with the same results.

The client folder is the partition, meshAssets being the folder I'd like ignored.

Again, the second option in my original post would seem like the obvious (temporary) solution here but it doesn't fit the structure.

I also realized my question would've better fit #205

[Kampfkarren]

Oh my bad, I misread. Yes, it's impossible to sync MeshParts in any form right now.

[LPGhatguy]

It looks like built-in plugins may be on track to be locked down in the future for security concerns.

Additionally, the primary use case for escalating to a built-in plugin can be covered with a stable API, game:GetObjects().

I'm going to close this issue in favor of #205!