This is a great question (thanks!) and one I get quite a lot. So I wanted to break down our thoughts a little more here.
The core challenge is, although the DataModel is hierarchical, it is not a file system. Some differences:
No naming restrictions (non-unique names, special characters).
Allows parent-child relationships among instances (ie files nested under files).
Instances contain many properties, not one blob of data
Instances have complex metadata (attributes, tags etc.).
That’s not to say a Roblox project can’t be represented on the file system in such a way that it can be translated to a DataModel later, but doing this requires a lot of opinions and potentially configuration. Questions like this start to pop up:
Should a house model be one file or each brick part a separate file?
How should DataModel instances be structured on disk?
Should assets be stored with their references?
How to serialize a LocalizationTable—JSON, CSV, or another format?
Should data prioritize space, interoperability, or other factors?
Should a mesh file map to a mesh asset, an instance referencing a mesh asset, or a scene of instances in the data model referencing many assets
The Rojo devs have spent a lot of time on this problem, and has built a project format that adopts enough opinions to make this work great for their use cases. However - the range of use cases for external tools is enormous. We aren’t sure every use case needs (or benefits from) a file system source of truth, nor that the rules / conventions Rojo adopts are suitable for every workflow involving external tools.
We think we can best serve the community by:
Working to open up our platform so that tools like Rojo are easier for creators to build and maintain
Trusting the community, and not adopting our own complex opinions on how such workflows should work (we’ll get this wrong!)
Releasing first party features in this space, only when we think we have a clear value proposition and can do so in a generic way
Now… that being said. On our upcoming features list for Script Sync is Folder Sync, this will let you sync a Folder to a directory on disk. When you add a script to the Folder, it’ll automatically create the file on disk and vice-versa. The idea here being letting you sync code bases, not just individual scripts. This may address some of your use cases.
PS: Sorry for the word wall - we’re super passionate about this stuff!
You’ve caught me out! To the best of my knowledge ScriptEditorService.TextDocumentDidChange is the correct API for listening to open script documents, as it reflects the latest state as rendered in the script editor. ScriptEditorService also provides APIs for you to ‘submit’ transformations to the script document (even if others are writing to it) so if you want to write to a script it’s definitely encouraged you use this.
If you just want to listen to changes, subscribing to Script.Source should be fine. That being said, I don’t work on this stuff directly so if you see me delete this post later and change this that’s your signal I was wrong.
No plans at the moment. The challenge here is representing a Roblox project as files is non trivial. If you want a file based workflow, with your project checked into an external version control system, a tool like Rojo is the way to do this.
That being said - we know we need to do more work on the collaboration options that are built into Roblox Studio. Particularly when it comes to workflows where you want to isolate your work from each other. I can’t share any specific plans yet but this is something we’re actively thinking about.
Additionally, syncing updates between places for games such as a tower defenses or generally ones with a lot of maps that might be split-up into places becomes easier with this as well.
Do you have experience in doing that? I’m currently trying to sync a few modules between games and I have difficulty finding premade tools.
My first thought was to import every module into it’s own git project and automatically update the other git projects when code gets pushed to one.
…But that may just be a bit overkill
These changes just write to the Studio state like any change you made in Studio. It’s still up to you when you hit save / publish.
The other user would need to enable script sync to sync this file. We recommend against having two users attempt to sync to the same script at the same time. It’ll work, but if you aren’t careful you’ll overwrite each other’s work.
Okay, thank you for the reply. Really exciting update! I totally see why this isn’t straight forward for you. If I could give my humble opinion, I think attributes, tags etc. does not have to be shown in studio, but just have to appear in autocomplete, and then you have to edit the properties in studio (unless you do it via a script).
Do you have an (estimated) timeframe for when these 2 would be available? Right now they are the only things holding back my studio from using this new feature.
You can take advantage of Roblox Packages for this. Whenever you’d update the code within your main place, these changes will automatically be updated across all instances as long as auto updating is enabled.
Import, Export and Reload operations would be sufficient for my workflow. Additionally, the icon for file sync in the explorer pane should reflect which Instances have been modified (either in Roblox or on the file system) and not synced. Please refer to my subsequent reply for an image of the Lync widget which contains these features (“Revert” = Reload, “Save” = Export.)
This achieves the result I’m aiming for. Only concern I have is how syncing raw file contents to a ModuleScript will create script errors. Perhaps the File instance could be modified to suit this purpose instead?
In the future, when more types of Instances can be synced, there must be a catch-all syncing/synced event; otherwise, it becomes tricky to listen to modifications to an instance tree of indeterminate composition, especially when some of the properties are inaccessible to plugins.
Additionally; listening to instance modifications won’t tell you if the change was made in Roblox or on the file system.
Take your time, we are all here waiting on it. We appreciate the transparency and this is looking super neat already. I already love Rojo and I can’t wait to see what you guys build with the deeper integration an official Roblox tool can provide.
To simplify the argument for external IDEs to a couple of sentences; A lot of the popular IDE programs like Visual Studio (and its sister program Visual Studio Code) are more robust when compared to what is provided by Roblox. When it comes to IDE programs such as the ones stated earlier, their entire purpose is to provide a good environment for development of scripts/code. This means that they generally are able to focus more on providing tools and features that Roblox realistically can’t since they have much more on their plate.
Question, I see people in this post use github a lot. If I remember correctly, it saves your scripts to a cloud. To save my scripts I save them to file, especially if I’ve done any substantial scripting. Am I right about the cloud saving? & Are there any other features that make github useful to you?
For the most part; you’re right – however, GitHub has a lot of features that help with project management and helps with saving time.
Branches
Imagine different folders with your entire codebase in all these folders, allowing developers to work on stuff, fix stuff, etc without conflicting edits from other developers. It’s very normal for developers to use branches whenever making a new feature/fixing quite a few bugs at once. Oh, and when you’re ready you can merge these branches into others using pull requests.
Pull Requests
Pull requests are basically just gaining feedback and additional reviews from other developers on your team before pushing a piece of code (or a branch) to live production/to another branch. If I were to make a pull request changing a file, I could request reviewers, assign labels, etc. You can also keep track of all the pull requests you’ve made which helps with version control.
Teams
You can have your own teams on github, with access to certain repositories and actions, much like the in-built creator hub groups! This allows you to sync multiple repositories to certain games,external systems, etc. inside your organization ← (which are just glorified Roblox groups for development lol)
Repositories
This is literally just where your main code will be stored; can have a variety of repositories for different reasons though.
Workflow Integrations
Can sync your code with Rojo and work in external editors (such as the aforementioned Visual Studio Code) properly. Also allows support for Git (which you can read more about here! There’s alot more to this which would take way too long to unpack, but will let you find that out yourself if interested! One of my favorite things about VSC which ties in with Github are code snippets (might already be familiar with this, just leaving it incase you aren’t!)
Say you want a template for requiring a specific module but can’t remember exactly what the path was. Introducing, code snippets.
THANK YOU SO MUCH ROBLOX 