| 1 |
- {"config":{"lang":["en"],"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"This is the documentation home for Rojo, a tool that enables Roblox developers to use professional-grade software engineering tools. This documentation is a continual work in progress. If you find any issues, please file an issue on the Rojo website issue tracker ! New to Rojo? Check out Installation or Why Rojo? .","title":"Home"},{"location":"help/","text":"Rojo is a fairly complex tool to adopt, but there's a community willing to help! The Roblox Open Source Community Discord currently hosts a Rojo support channel, #rojo , that is a great place to get help as problems come up. If you find anything that looks like a bug or have ideas for how to improve Rojo, feel free to file an issue on Rojo's GitHub issue tracker . Rojo's primary maintainer is also available on Twitter, @LPGhatguy .","title":"Get Help with Rojo"},{"location":"installation/","text":"Overview VS Code Extension Installing the CLI With Foreman From GitHub From Crates.io Installing the Plugin Installing from GitHub Installing from Roblox.com Overview \u00b6 Rojo has two halves that need to be installed: The command line interface (CLI) The Roblox Studio plugin Info It's important that your installed version of the plugin and CLI are compatible. The plugin will show errors in the Roblox Studio output window if there is a version mismatch. VS Code Extension \u00b6 If you use Visual Studio Code, you can install the Rojo VS Code extension , which will install both halves of Rojo for you. It even has a nifty UI to sync files and start/stop the Rojo server! Installing the CLI \u00b6 With Foreman \u00b6 Foreman is a toolchain manager that is useful for managing tools like Rojo for Roblox projects. To install from the latest stable release channel, currently 0.5.x, add an entry to the [tools] section of your foreman.toml : rojo = { source = \"rojo-rbx/rojo\", version = \"0.5\" } From GitHub \u00b6 If you're on Windows, there are pre-built binaries available from Rojo's GitHub Releases page . The Rojo CLI must be run from the command line, like Terminal.app on MacOS or cmd.exe on Windows. It's recommended that you put the Rojo CLI executable on your PATH to make this easier. From Crates.io \u00b6 It's also possible to install Rojo releases using Rust . This will compile Rojo from source and install it on your machine. To install from the latest stable release channel, currently 0.5.x, use: cargo install rojo To install a different version, like the latest 0.4.x release, use: cargo install rojo --version ^0.4 Installing the Plugin \u00b6 Installing from GitHub \u00b6 The Rojo Roblox Studio plugin is available from Rojo's GitHub Releases page . Download the attached rbxm file and put it into your Roblox Studio plugins folder. You can find that folder by pressing Plugins Folder from your Plugins toolbar in Roblox Studio: Installing from Roblox.com \u00b6 Rojo has a separate Roblox.com plugin for each release channel. Make sure you install the correct one! v0.6.x plugin v0.5.x plugin v0.4.x plugin Press the 'Install' on the plugin page to add it to Roblox Studio.","title":"Installing Rojo"},{"location":"installation/#overview","text":"Rojo has two halves that need to be installed: The command line interface (CLI) The Roblox Studio plugin Info It's important that your installed version of the plugin and CLI are compatible. The plugin will show errors in the Roblox Studio output window if there is a version mismatch.","title":"Overview"},{"location":"installation/#vs-code-extension","text":"If you use Visual Studio Code, you can install the Rojo VS Code extension , which will install both halves of Rojo for you. It even has a nifty UI to sync files and start/stop the Rojo server!","title":"VS Code Extension"},{"location":"installation/#installing-the-cli","text":"","title":"Installing the CLI"},{"location":"installation/#with-foreman","text":"Foreman is a toolchain manager that is useful for managing tools like Rojo for Roblox projects. To install from the latest stable release channel, currently 0.5.x, add an entry to the [tools] section of your foreman.toml : rojo = { source = \"rojo-rbx/rojo\", version = \"0.5\" }","title":"With Foreman"},{"location":"installation/#from-github","text":"If you're on Windows, there are pre-built binaries available from Rojo's GitHub Releases page . The Rojo CLI must be run from the command line, like Terminal.app on MacOS or cmd.exe on Windows. It's recommended that you put the Rojo CLI executable on your PATH to make this easier.","title":"From GitHub"},{"location":"installation/#from-cratesio","text":"It's also possible to install Rojo releases using Rust . This will compile Rojo from source and install it on your machine. To install from the latest stable release channel, currently 0.5.x, use: cargo install rojo To install a different version, like the latest 0.4.x release, use: cargo install rojo --version ^0.4","title":"From Crates.io"},{"location":"installation/#installing-the-plugin","text":"","title":"Installing the Plugin"},{"location":"installation/#installing-from-github","text":"The Rojo Roblox Studio plugin is available from Rojo's GitHub Releases page . Download the attached rbxm file and put it into your Roblox Studio plugins folder. You can find that folder by pressing Plugins Folder from your Plugins toolbar in Roblox Studio:","title":"Installing from GitHub"},{"location":"installation/#installing-from-robloxcom","text":"Rojo has a separate Roblox.com plugin for each release channel. Make sure you install the correct one! v0.6.x plugin v0.5.x plugin v0.4.x plugin Press the 'Install' on the plugin page to add it to Roblox Studio.","title":"Installing from Roblox.com"},{"location":"rojo-alternatives/","text":"There are a number of existing plugins for Roblox that move code from the filesystem into Roblox. Besides Rojo, you might consider: rbxmk by Anaminus Rofresh by Osyris RbxRefresh by Osyris Studio Bridge by Vocksel Elixir by Vocksel RbxSync by evaera CodeSync by MemoryPenguin rbx-exteditor by MemoryPenguin So why did I build Rojo? Each of these tools solves what is essentially the same problem from a few different angles. The goal of Rojo is to take all of the lessons and ideas learned from these projects and build a tool that can solve this problem for good. Additionally: I think that this tool needs to be built in a compiled language without a runtime, for easy distribution and good performance. I think that the conventions promoted by other sync plugins ( .module.lua for modules, as well a single sync point) are sub-optimal. I think that I have a good enough understanding of the problem to build something robust. I think that Rojo should be able to do more than just sync code.","title":"Rojo Alternatives"},{"location":"why-rojo/","text":"Adding a tool like Rojo to your Roblox workflow can be daunting, but it comes with some key advantages. Rojo at RDC 2019 External Text Editors Version Control TypeScript Other Tools Rojo at RDC 2019 \u00b6 Nathan Riemer (Kampfkarren) gave a talk at RDC 2019 talking about some of the benefits of using a tool like Rojo. External Text Editors \u00b6 Rojo opens the door to use the absolute best text editors in the world and their rich plugin ecosystems. Some very popular editors include Visual Studio Code and Sublime Text . These advanced text editors have features like multi-cursor editing, go-to symbol, multi-file regex find and replace, bookmarks and much more. Many Rojo VS Code users also use extensions like: vscode-rbxlua Roblox Lua Autocompletes TabNine Version Control \u00b6 By building your game (or just the scripts) as individual files on the filesystem, it becomes easy to start using professional-grade version control tools like Git and GitHub . Hundreds of thousands of companies and individual developers use Git to version their software projects. With Rojo, Roblox developers can take advantage of the best collaboration tool around. Using a repository hosting service like GitHub or GitLab brings powerful features to Roblox developers like code reviews and issue tracking that professional engineers can't live without. TypeScript \u00b6 TypeScript enables static type safety, which helps prevent typos and adds unparalleled autocompletion. It also brings features like arrow functions, object destructuring, functional programming methods, and more! With Rojo, you can use roblox-ts to compile TypeScript to Lua and take advantage of a huge ecosystem of TypeScript tooling. It's also possible to use other languages that compile to Lua like MoonScript and Haxe . Other Tools \u00b6 There are decades of excellent tools available that operate on files. With Rojo, it's possible to take advantage of any of them! Popular tools include: luacheck , a static analysis tool to help you write better Lua ripgrep , an extremely fast code search tool Tokei , a tool for statistics like lines of code","title":"Why Rojo?"},{"location":"why-rojo/#rojo-at-rdc-2019","text":"Nathan Riemer (Kampfkarren) gave a talk at RDC 2019 talking about some of the benefits of using a tool like Rojo.","title":"Rojo at RDC 2019"},{"location":"why-rojo/#external-text-editors","text":"Rojo opens the door to use the absolute best text editors in the world and their rich plugin ecosystems. Some very popular editors include Visual Studio Code and Sublime Text . These advanced text editors have features like multi-cursor editing, go-to symbol, multi-file regex find and replace, bookmarks and much more. Many Rojo VS Code users also use extensions like: vscode-rbxlua Roblox Lua Autocompletes TabNine","title":"External Text Editors"},{"location":"why-rojo/#version-control","text":"By building your game (or just the scripts) as individual files on the filesystem, it becomes easy to start using professional-grade version control tools like Git and GitHub . Hundreds of thousands of companies and individual developers use Git to version their software projects. With Rojo, Roblox developers can take advantage of the best collaboration tool around. Using a repository hosting service like GitHub or GitLab brings powerful features to Roblox developers like code reviews and issue tracking that professional engineers can't live without.","title":"Version Control"},{"location":"why-rojo/#typescript","text":"TypeScript enables static type safety, which helps prevent typos and adds unparalleled autocompletion. It also brings features like arrow functions, object destructuring, functional programming methods, and more! With Rojo, you can use roblox-ts to compile TypeScript to Lua and take advantage of a huge ecosystem of TypeScript tooling. It's also possible to use other languages that compile to Lua like MoonScript and Haxe .","title":"TypeScript"},{"location":"why-rojo/#other-tools","text":"There are decades of excellent tools available that operate on files. With Rojo, it's possible to take advantage of any of them! Popular tools include: luacheck , a static analysis tool to help you write better Lua ripgrep , an extremely fast code search tool Tokei , a tool for statistics like lines of code","title":"Other Tools"},{"location":"0.4.x/sync-details/","text":"Sync Details \u00b6 This page aims to describe how Rojo turns files on the filesystem into Roblox objects. Folders \u00b6 Any directory on the filesystem will turn into a Folder instance in Roblox, unless that folder matches the name of a service or other existing instance. In those cases, that instance will be preserved. Scripts \u00b6 Rojo can represent ModuleScript , Script , and LocalScript objects. The default script type is ModuleScript , since most scripts in well-structured Roblox projects will be modules. File Name Instance Type *.server.lua Script *.client.lua LocalScript *.lua ModuleScript If a directory contains a file named init.server.lua , init.client.lua , or init.lua , that folder will be transformed into a *Script instance with the contents of the init file. This can be used to create scripts inside of scripts. For example, this file tree: my-game init.client.lua foo.lua Will turn into these instances in Roblox: Models \u00b6 Rojo supports a JSON model format for representing simple models. It's designed for instance types like BindableEvent or Value objects, and is not suitable for larger models. Rojo JSON models are stored in .model.json files. Starting in Rojo version 0.4.10 , model files named init.model.json that are located in folders will replace that folder, much like Rojo's init.lua support. This can be useful to version instances like Tool that tend to contain several instances as well as one or more scripts. Info In the future, Rojo will support .rbxmx models. See issue #7 for more details and updates on this feature. Warning Prior to Rojo version 0.4.9 , the Properties and Children properties are required on all instances in JSON models! JSON model files are fairly strict; any syntax errors will cause the model to fail to sync! They look like this: hello.model.json { \"Name\" : \"hello\" , \"ClassName\" : \"Model\" , \"Children\" : [ { \"Name\" : \"Some Part\" , \"ClassName\" : \"Part\" }, { \"Name\" : \"Some StringValue\" , \"ClassName\" : \"StringValue\" , \"Properties\" : { \"Value\" : { \"Type\" : \"String\" , \"Value\" : \"Hello, world!\" } } } ] }","title":"Sync Details"},{"location":"0.4.x/sync-details/#sync-details","text":"This page aims to describe how Rojo turns files on the filesystem into Roblox objects.","title":"Sync Details"},{"location":"0.4.x/sync-details/#folders","text":"Any directory on the filesystem will turn into a Folder instance in Roblox, unless that folder matches the name of a service or other existing instance. In those cases, that instance will be preserved.","title":"Folders"},{"location":"0.4.x/sync-details/#scripts","text":"Rojo can represent ModuleScript , Script , and LocalScript objects. The default script type is ModuleScript , since most scripts in well-structured Roblox projects will be modules. File Name Instance Type *.server.lua Script *.client.lua LocalScript *.lua ModuleScript If a directory contains a file named init.server.lua , init.client.lua , or init.lua , that folder will be transformed into a *Script instance with the contents of the init file. This can be used to create scripts inside of scripts. For example, this file tree: my-game init.client.lua foo.lua Will turn into these instances in Roblox:","title":"Scripts"},{"location":"0.4.x/sync-details/#models","text":"Rojo supports a JSON model format for representing simple models. It's designed for instance types like BindableEvent or Value objects, and is not suitable for larger models. Rojo JSON models are stored in .model.json files. Starting in Rojo version 0.4.10 , model files named init.model.json that are located in folders will replace that folder, much like Rojo's init.lua support. This can be useful to version instances like Tool that tend to contain several instances as well as one or more scripts. Info In the future, Rojo will support .rbxmx models. See issue #7 for more details and updates on this feature. Warning Prior to Rojo version 0.4.9 , the Properties and Children properties are required on all instances in JSON models! JSON model files are fairly strict; any syntax errors will cause the model to fail to sync! They look like this: hello.model.json { \"Name\" : \"hello\" , \"ClassName\" : \"Model\" , \"Children\" : [ { \"Name\" : \"Some Part\" , \"ClassName\" : \"Part\" }, { \"Name\" : \"Some StringValue\" , \"ClassName\" : \"StringValue\" , \"Properties\" : { \"Value\" : { \"Type\" : \"String\" , \"Value\" : \"Hello, world!\" } } } ] }","title":"Models"},{"location":"0.4.x/getting-started/creating-a-project/","text":"Creating a Project \u00b6 To use Rojo, you'll need to create a new project file, which tells Rojo what your project is, and how to load it into Roblox Studio. New Project \u00b6 Create a new folder, then run rojo init inside that folder to initialize an empty project. mkdir my-new-project cd my-new-project rojo init Rojo will create an empty project file named rojo.json in the directory. The default configuration doesn't do anything. We need to tell Rojo where our code is on the filesystem, and where we want to put it in the Roblox tree. To do that, open up rojo.json and add an entry to the partitions table: { \"name\" : \"your-project-name-here\" , \"servePort\" : 8000 , \"partitions\" : { \"src\" : { \"path\" : \"src\" , \"target\" : \"ReplicatedStorage.Project\" } } } Warning Make sure that the src directory exists in your project, or Rojo will throw an error! Warning Any objects contained in the target of a partition will be destroyed by Rojo if not found on the filesystem! A Rojo project has one or more partitions . Partitions define how code should be transferred between the filesystem and Roblox by mapping directories and files to Roblox objects. Each partition has: A name (the key in the partitions object), which is used for debugging path , the location on the filesystem relative to rojo.json target , the location in Roblox relative to game Syncing into Studio \u00b6 Once you've added your partition to the project file, you can start the Rojo dev server by running a command in your project's directory: rojo serve If your project is in the right place, Rojo will let you know that it was found and start an HTTP server that the plugin can connect to. In Roblox Studio, open the plugins tab and find Rojo's buttons. Press Test Connection to verify that the plugin can communicate with the dev server. Watch the Output panel for the results. Info If you see an error message, return to the previous steps and make sure that the Rojo dev server is running. After your connection was successful, press Sync In to move code from the filesystem into Studio, or use Toggle Polling to have Rojo automatically sync in changes as they happen. Importing an Existing Project \u00b6 Rojo will eventually support importing an existing Roblox project onto the filesystem for use with Rojo. Rojo doesn't currently support converting an existing project or syncing files from Roblox Studio onto the filesystem. In the mean time, you can manually copy your files into the structure that Rojo expects. Up-to-date information will be available on issue #5 as this is worked on.","title":"Creating a Project"},{"location":"0.4.x/getting-started/creating-a-project/#creating-a-project","text":"To use Rojo, you'll need to create a new project file, which tells Rojo what your project is, and how to load it into Roblox Studio.","title":"Creating a Project"},{"location":"0.4.x/getting-started/creating-a-project/#new-project","text":"Create a new folder, then run rojo init inside that folder to initialize an empty project. mkdir my-new-project cd my-new-project rojo init Rojo will create an empty project file named rojo.json in the directory. The default configuration doesn't do anything. We need to tell Rojo where our code is on the filesystem, and where we want to put it in the Roblox tree. To do that, open up rojo.json and add an entry to the partitions table: { \"name\" : \"your-project-name-here\" , \"servePort\" : 8000 , \"partitions\" : { \"src\" : { \"path\" : \"src\" , \"target\" : \"ReplicatedStorage.Project\" } } } Warning Make sure that the src directory exists in your project, or Rojo will throw an error! Warning Any objects contained in the target of a partition will be destroyed by Rojo if not found on the filesystem! A Rojo project has one or more partitions . Partitions define how code should be transferred between the filesystem and Roblox by mapping directories and files to Roblox objects. Each partition has: A name (the key in the partitions object), which is used for debugging path , the location on the filesystem relative to rojo.json target , the location in Roblox relative to game","title":"New Project"},{"location":"0.4.x/getting-started/creating-a-project/#syncing-into-studio","text":"Once you've added your partition to the project file, you can start the Rojo dev server by running a command in your project's directory: rojo serve If your project is in the right place, Rojo will let you know that it was found and start an HTTP server that the plugin can connect to. In Roblox Studio, open the plugins tab and find Rojo's buttons. Press Test Connection to verify that the plugin can communicate with the dev server. Watch the Output panel for the results. Info If you see an error message, return to the previous steps and make sure that the Rojo dev server is running. After your connection was successful, press Sync In to move code from the filesystem into Studio, or use Toggle Polling to have Rojo automatically sync in changes as they happen.","title":"Syncing into Studio"},{"location":"0.4.x/getting-started/creating-a-project/#importing-an-existing-project","text":"Rojo will eventually support importing an existing Roblox project onto the filesystem for use with Rojo. Rojo doesn't currently support converting an existing project or syncing files from Roblox Studio onto the filesystem. In the mean time, you can manually copy your files into the structure that Rojo expects. Up-to-date information will be available on issue #5 as this is worked on.","title":"Importing an Existing Project"},{"location":"0.5.x/guide/existing-game/","text":"This page is under construction! Summary \u00b6 Tools to port existing games are in progress! rbxlx-to-rojo rojo export ( issue #208 ) Can port as much or as little of your game as you like Rojo can manage just a slice of your game! Some Roblox idioms aren't very well supported Redundant copies of scripts don't work well with files Having only a couple places with scripts simplifies your project dramatically!","title":"Porting an Existing Game to Rojo"},{"location":"0.5.x/guide/existing-game/#summary","text":"Tools to port existing games are in progress! rbxlx-to-rojo rojo export ( issue #208 ) Can port as much or as little of your game as you like Rojo can manage just a slice of your game! Some Roblox idioms aren't very well supported Redundant copies of scripts don't work well with files Having only a couple places with scripts simplifies your project dramatically!","title":"Summary"},{"location":"0.5.x/guide/migrating-to-epiphany/","text":"Rojo underwent a large refactor during most of 2018 to enable a bunch of new features and lay groundwork for lots more in 2019. As such, Rojo 0.5.x projects are not compatible with Rojo 0.4.x projects. Supporting Both 0.4.x and 0.5.x Upgrading Your Project File Migrating Unknown Files Migrating init.model.json files Supporting Both 0.4.x and 0.5.x \u00b6 Rojo 0.5.x uses a different name for its project format. While 0.4.x used rojo.json , 0.5.x uses default.project.json , which allows them to coexist. If you aren't sure about upgrading or want to upgrade gradually, it's possible to keep both files in the same project without causing problems. Upgrading Your Project File \u00b6 Project files in 0.5.x are more explicit and flexible than they were in 0.4.x. Project files can now describe models and plugins in addition to places. This new project file format also guards against two of the biggest pitfalls when writing a config file: Using a service as a partition target directly, which often wiped away extra instances Defining two partitions that overlapped, which made Rojo act unpredictably The biggest change is that the partitions field has been replaced with a new field, tree , that describes the entire hierarchy of your project from the top-down. A project for 0.4.x that syncs from the src directory into ReplicatedStorage.Source would look like this: { \"name\" : \"Rojo 0.4.x Example\" , \"partitions\" : { \"path\" : \"src\" , \"target\" : \"ReplicatedStorage.Source\" } } In 0.5.x, the project format is more explicit: { \"name\" : \"Rojo 0.5.x Example\" , \"tree\" : { \"$className\" : \"DataModel\" , \"ReplicatedStorage\" : { \"$className\" : \"ReplicatedStorage\" , \"Source\" : { \"$path\" : \"src\" } } } } For each object in the tree, we define metadata and children . Metadata begins with a dollar sign ( $ ), like $className . This is so that children and metadata can coexist without creating too many nested layers. All other values are considered children, where the key is the instance's name, and the value is an object, repeating the process. Migrating Unknown Files \u00b6 If you used Rojo to sync in files as StringValue objects, you'll need to make sure those files end with the txt extension to preserve this in Rojo 0.5.x. Unknown files are now ignored in Rojo instead of being converted to StringValue objects. Migrating init.model.json files \u00b6 In Rojo 0.4.x, it's possible to create a file named init.model.json that lets you describe a model that becomes the container for all of the other files in the folder, just like init.lua . In Rojo 0.5.x, this feature has been replaced with init.meta.json files. See Sync Details for more information about these new files.","title":"Migrating from 0.4.x to 0.5.x"},{"location":"0.5.x/guide/migrating-to-epiphany/#supporting-both-04x-and-05x","text":"Rojo 0.5.x uses a different name for its project format. While 0.4.x used rojo.json , 0.5.x uses default.project.json , which allows them to coexist. If you aren't sure about upgrading or want to upgrade gradually, it's possible to keep both files in the same project without causing problems.","title":"Supporting Both 0.4.x and 0.5.x"},{"location":"0.5.x/guide/migrating-to-epiphany/#upgrading-your-project-file","text":"Project files in 0.5.x are more explicit and flexible than they were in 0.4.x. Project files can now describe models and plugins in addition to places. This new project file format also guards against two of the biggest pitfalls when writing a config file: Using a service as a partition target directly, which often wiped away extra instances Defining two partitions that overlapped, which made Rojo act unpredictably The biggest change is that the partitions field has been replaced with a new field, tree , that describes the entire hierarchy of your project from the top-down. A project for 0.4.x that syncs from the src directory into ReplicatedStorage.Source would look like this: { \"name\" : \"Rojo 0.4.x Example\" , \"partitions\" : { \"path\" : \"src\" , \"target\" : \"ReplicatedStorage.Source\" } } In 0.5.x, the project format is more explicit: { \"name\" : \"Rojo 0.5.x Example\" , \"tree\" : { \"$className\" : \"DataModel\" , \"ReplicatedStorage\" : { \"$className\" : \"ReplicatedStorage\" , \"Source\" : { \"$path\" : \"src\" } } } } For each object in the tree, we define metadata and children . Metadata begins with a dollar sign ( $ ), like $className . This is so that children and metadata can coexist without creating too many nested layers. All other values are considered children, where the key is the instance's name, and the value is an object, repeating the process.","title":"Upgrading Your Project File"},{"location":"0.5.x/guide/migrating-to-epiphany/#migrating-unknown-files","text":"If you used Rojo to sync in files as StringValue objects, you'll need to make sure those files end with the txt extension to preserve this in Rojo 0.5.x. Unknown files are now ignored in Rojo instead of being converted to StringValue objects.","title":"Migrating Unknown Files"},{"location":"0.5.x/guide/migrating-to-epiphany/#migrating-initmodeljson-files","text":"In Rojo 0.4.x, it's possible to create a file named init.model.json that lets you describe a model that becomes the container for all of the other files in the folder, just like init.lua . In Rojo 0.5.x, this feature has been replaced with init.meta.json files. See Sync Details for more information about these new files.","title":"Migrating init.model.json files"},{"location":"0.5.x/guide/new-game/","text":"Creating the Rojo Project Building Your Place Live-Syncing into Studio Uploading Your Place Creating the Rojo Project \u00b6 To use Rojo to build a game, you'll need to create a new project file, which tells Rojo how to turn your files into a Roblox place. First, create a new folder to contain the files for your game and open up a new terminal inside of it, like cmd.exe or Bash. It's convenient to make the folder from the command line: mkdir my-new-project cd my-new-project Inside the folder, initialize a new Rojo project: rojo init Rojo will make a small project file in your directory, named default.project.json . It matches the \"Baseplate\" template from Roblox Studio, except that it'll take any files you put in a folder called src and put it into ReplicatedStorage.Source . Speaking of files, make sure to create a directory named src in this folder, or Rojo will be upset about missing files! mkdir src Let's also add a Lua file, hello.lua to the src folder, so that we can make this project our own. echo 'return \"Hello, Rojo!\"' > src/hello.lua Building Your Place \u00b6 Now that we have a project, one thing we can do is build a Roblox place file for our project. This is a great way to get started with a project quickly with no fuss. All we have to do is call rojo build : rojo build -o MyNewProject.rbxlx If you open MyNewProject.rbxlx in Roblox Studio now, you should see a Folder named \"Source\" containing a ModuleScript under ReplicatedStorage . Info To generate a binary place file instead, use rbxl . Note that support for binary model/place files ( rbxm and rbxl ) is very limited in Rojo presently. Live-Syncing into Studio \u00b6 Building a place file is great for starting to work on a game, but for active iteration, you'll want something faster. In Roblox Studio, make sure the Rojo plugin is installed. If you need it, check out the installation guide to learn how to install it. To expose your project to the plugin, you'll need to start a new live sync session from the command line: rojo serve You should see output like this in your terminal: $ rojo serve Rojo server listening on port 34872 Switch into Roblox Studio and press the Connect button on the Rojo plugin toolbar. A dialog should appear: If the port number doesn't match the output from the command line, change it, and then press Connect . If all went well, you should now be able to change files in the src directory and watch them sync into Roblox Studio in real time! Uploading Your Place \u00b6 Aimed at teams that want serious levels of automation, Rojo can upload places to Roblox.com automatically. You'll need an existing game on Roblox.com as well as the .ROBLOSECURITY cookie of an account that has write access to that game. Warning It's recommended that you set up a Roblox account dedicated to deploying your game instead of your personal account in case your security cookie is compromised. Generating and publishing your game is as simple as: rojo upload --asset_id [ PLACE ID ] --cookie \"[SECURITY COOKIE]\" An example project is available on GitHub that deploys to Roblox.com from GitHub and Travis-CI automatically: https://github.com/LPGhatguy/roads","title":"Creating a Game with Rojo"},{"location":"0.5.x/guide/new-game/#creating-the-rojo-project","text":"To use Rojo to build a game, you'll need to create a new project file, which tells Rojo how to turn your files into a Roblox place. First, create a new folder to contain the files for your game and open up a new terminal inside of it, like cmd.exe or Bash. It's convenient to make the folder from the command line: mkdir my-new-project cd my-new-project Inside the folder, initialize a new Rojo project: rojo init Rojo will make a small project file in your directory, named default.project.json . It matches the \"Baseplate\" template from Roblox Studio, except that it'll take any files you put in a folder called src and put it into ReplicatedStorage.Source . Speaking of files, make sure to create a directory named src in this folder, or Rojo will be upset about missing files! mkdir src Let's also add a Lua file, hello.lua to the src folder, so that we can make this project our own. echo 'return \"Hello, Rojo!\"' > src/hello.lua","title":"Creating the Rojo Project"},{"location":"0.5.x/guide/new-game/#building-your-place","text":"Now that we have a project, one thing we can do is build a Roblox place file for our project. This is a great way to get started with a project quickly with no fuss. All we have to do is call rojo build : rojo build -o MyNewProject.rbxlx If you open MyNewProject.rbxlx in Roblox Studio now, you should see a Folder named \"Source\" containing a ModuleScript under ReplicatedStorage . Info To generate a binary place file instead, use rbxl . Note that support for binary model/place files ( rbxm and rbxl ) is very limited in Rojo presently.","title":"Building Your Place"},{"location":"0.5.x/guide/new-game/#live-syncing-into-studio","text":"Building a place file is great for starting to work on a game, but for active iteration, you'll want something faster. In Roblox Studio, make sure the Rojo plugin is installed. If you need it, check out the installation guide to learn how to install it. To expose your project to the plugin, you'll need to start a new live sync session from the command line: rojo serve You should see output like this in your terminal: $ rojo serve Rojo server listening on port 34872 Switch into Roblox Studio and press the Connect button on the Rojo plugin toolbar. A dialog should appear: If the port number doesn't match the output from the command line, change it, and then press Connect . If all went well, you should now be able to change files in the src directory and watch them sync into Roblox Studio in real time!","title":"Live-Syncing into Studio"},{"location":"0.5.x/guide/new-game/#uploading-your-place","text":"Aimed at teams that want serious levels of automation, Rojo can upload places to Roblox.com automatically. You'll need an existing game on Roblox.com as well as the .ROBLOSECURITY cookie of an account that has write access to that game. Warning It's recommended that you set up a Roblox account dedicated to deploying your game instead of your personal account in case your security cookie is compromised. Generating and publishing your game is as simple as: rojo upload --asset_id [ PLACE ID ] --cookie \"[SECURITY COOKIE]\" An example project is available on GitHub that deploys to Roblox.com from GitHub and Travis-CI automatically: https://github.com/LPGhatguy/roads","title":"Uploading Your Place"},{"location":"0.5.x/internals/overview/","text":"This document aims to give a general overview of how Rojo works. It's intended for people who want to contribute to the project as well as anyone who's just curious how the tool works! CLI RbxTree In-Memory Filesystem (IMFS) Snapshot Reconciler HTTP API Roblox Studio Plugin CLI \u00b6 RbxTree \u00b6 Rojo uses a library named rbx_tree as its implementation of the Roblox DOM. It serves as a common format for serialization to all the formats Rojo supports! Rojo uses two related libraries to deserialize instances from Roblox's file formats, rbx_xml and rbx_binary . In-Memory Filesystem (IMFS) \u00b6 Relevant source files: server/src/imfs.rs server/src/fs_watcher.rs Rojo keeps an in-memory copy of all files that it needs reasons about. This enables taking fast, stateless, tear-tree snapshots of files to turn them into instances. Keeping an in-memory copy of file contents will also enable Rojo to debounce changes that are caused by Rojo itself. This'll happen when two-way sync finally happens. Snapshot Reconciler \u00b6 Relevant source files: server/src/snapshot_reconciler.rs server/src/rbx_snapshot.rs server/src/rbx_session.rs To simplify incremental updates of instances, Rojo generates lightweight snapshots describing how files map to instances. This means that Rojo can treat file change events similarly to damage painting as opposed to trying to surgically update the correct instances. This approach reduces the number of desynchronization bugs, reduces the complexity of important pieces of the codebase, and makes writing plugins a lot easier. HTTP API \u00b6 Relevant source files: server/src/web.rs The Rojo live-sync server and Roblox Studio plugin communicate via HTTP. Requests sent from the plugin to the server are regular HTTP requests. Messages sent from the server to the plugin are delivered via HTTP long-polling. This is an approach that uses long-lived HTTP requests that restart on timeout. It's largely been replaced by WebSockets, but Roblox doesn't have support for them. Roblox Studio Plugin \u00b6 TODO","title":"Internals Overview"},{"location":"0.5.x/internals/overview/#cli","text":"","title":"CLI"},{"location":"0.5.x/internals/overview/#rbxtree","text":"Rojo uses a library named rbx_tree as its implementation of the Roblox DOM. It serves as a common format for serialization to all the formats Rojo supports! Rojo uses two related libraries to deserialize instances from Roblox's file formats, rbx_xml and rbx_binary .","title":"RbxTree"},{"location":"0.5.x/internals/overview/#in-memory-filesystem-imfs","text":"Relevant source files: server/src/imfs.rs server/src/fs_watcher.rs Rojo keeps an in-memory copy of all files that it needs reasons about. This enables taking fast, stateless, tear-tree snapshots of files to turn them into instances. Keeping an in-memory copy of file contents will also enable Rojo to debounce changes that are caused by Rojo itself. This'll happen when two-way sync finally happens.","title":"In-Memory Filesystem (IMFS)"},{"location":"0.5.x/internals/overview/#snapshot-reconciler","text":"Relevant source files: server/src/snapshot_reconciler.rs server/src/rbx_snapshot.rs server/src/rbx_session.rs To simplify incremental updates of instances, Rojo generates lightweight snapshots describing how files map to instances. This means that Rojo can treat file change events similarly to damage painting as opposed to trying to surgically update the correct instances. This approach reduces the number of desynchronization bugs, reduces the complexity of important pieces of the codebase, and makes writing plugins a lot easier.","title":"Snapshot Reconciler"},{"location":"0.5.x/internals/overview/#http-api","text":"Relevant source files: server/src/web.rs The Rojo live-sync server and Roblox Studio plugin communicate via HTTP. Requests sent from the plugin to the server are regular HTTP requests. Messages sent from the server to the plugin are delivered via HTTP long-polling. This is an approach that uses long-lived HTTP requests that restart on timeout. It's largely been replaced by WebSockets, but Roblox doesn't have support for them.","title":"HTTP API"},{"location":"0.5.x/internals/overview/#roblox-studio-plugin","text":"TODO","title":"Roblox Studio Plugin"},{"location":"0.5.x/reference/full-vs-partial/","text":"Rojo is designed to be adopted incrementally. How much of your project Rojo manages is up to you! There are two primary categories of ways to use Rojo: Fully Managed , where everything is managed by Rojo, and Partially Managed , where Rojo only manages a slice of your project. Fully Managed \u00b6 In a fully managed game project, Rojo controls every instance. A fully managed Rojo project can be built from scratch using rojo build . Fully managed projects are most practical for libraries, plugins, and simple games. Rojo's goal is to make it practical and easy for every project to be fully managed, but we're not quite there yet! Pros \u00b6 Fully reproducible builds from scratch Everything checked into version control Cons \u00b6 Without two-way sync, models have to be saved manually This can be done with the 'Save to File...' menu in Roblox Studio This will be solved by Two-Way Sync ( issue #164 ) Rojo can't manage everything yet Refs are currently broken ( issue #142 ) Partially Managed \u00b6 In a partially managed project, Rojo only handles a slice of the game. This could be as small as a couple scripts, or as large as everything except Workspace ! The rest of the place's content can be versioned using Team Create or checked into source control. Partially managed projects are most practical for complicated games, or games that are migrating to use Rojo. Pros \u00b6 Easier to adopt gradually Integrates with Team Create Cons \u00b6 Not everything is in version control, which makes merges tougher Rojo can't live-sync instances like Terrain, MeshPart, or CSG operations yet Will be fixed with plugin escalation ( issue #169 )","title":"Fully vs Partially Managed Rojo"},{"location":"0.5.x/reference/full-vs-partial/#fully-managed","text":"In a fully managed game project, Rojo controls every instance. A fully managed Rojo project can be built from scratch using rojo build . Fully managed projects are most practical for libraries, plugins, and simple games. Rojo's goal is to make it practical and easy for every project to be fully managed, but we're not quite there yet!","title":"Fully Managed"},{"location":"0.5.x/reference/full-vs-partial/#pros","text":"Fully reproducible builds from scratch Everything checked into version control","title":"Pros"},{"location":"0.5.x/reference/full-vs-partial/#cons","text":"Without two-way sync, models have to be saved manually This can be done with the 'Save to File...' menu in Roblox Studio This will be solved by Two-Way Sync ( issue #164 ) Rojo can't manage everything yet Refs are currently broken ( issue #142 )","title":"Cons"},{"location":"0.5.x/reference/full-vs-partial/#partially-managed","text":"In a partially managed project, Rojo only handles a slice of the game. This could be as small as a couple scripts, or as large as everything except Workspace ! The rest of the place's content can be versioned using Team Create or checked into source control. Partially managed projects are most practical for complicated games, or games that are migrating to use Rojo.","title":"Partially Managed"},{"location":"0.5.x/reference/full-vs-partial/#pros_1","text":"Easier to adopt gradually Integrates with Team Create","title":"Pros"},{"location":"0.5.x/reference/full-vs-partial/#cons_1","text":"Not everything is in version control, which makes merges tougher Rojo can't live-sync instances like Terrain, MeshPart, or CSG operations yet Will be fixed with plugin escalation ( issue #169 )","title":"Cons"},{"location":"0.5.x/reference/project-format/","text":"Project File Instance Description Instance Property Value Example Projects Project File \u00b6 Rojo projects are JSON files that have the .project.json extension. They have the following fields: name : A string indicating the name of the project. This name is used when building the project into a model or place file. Required tree : An Instance Description describing the root instance of the project. Required servePort : The port that rojo serve should listen on. Passing --port will override this setting. Optional Default is 34872 servePlaceIds : A list of place IDs that this project may be live-synced to. This feature can help prevent overwriting the wrong game with source from Rojo. Optional Default is null Instance Description \u00b6 Instance Descriptions correspond one-to-one with the actual Roblox Instances in the project. $className : The ClassName of the Instance being described. Optional if $path is specified. $path : The path on the filesystem to pull files from into the project. Optional if $className is specified. Paths are relative to the folder containing the project file. $properties : Properties to apply to the instance. Values should be Instance Property Values . Optional $ignoreUnknownInstances : Whether instances that Rojo doesn't know about should be deleted. Optional Default is false if $path is specified, otherwise true . All other fields in an Instance Description are turned into instances whose name is the key. These values should also be Instance Descriptions! Instance Descriptions are fairly verbose and strict. In the future, it'll be possible for Rojo to infer class names for known services like Workspace . Instance Property Value \u00b6 There are two kinds of property values on instances, implicit and explicit . In the vast majority of cases, you should be able to use implicit property values. To use them, just use a value that's the same shape as the type that the property has: \"MyPart\" : { \"$className\" : \"Part\" , \"$properties\" : { \"Size\" : [ 3 , 5 , 3 ], \"Color\" : [ 0.5 , 0 , 0.5 ], \"Anchored\" : true , \"Material\" : \"Granite\" } } Vector3 and Color3 properties can just be arrays of numbers, as can types like Vector2 , CFrame , and more! Enums can be set to a string containing the enum variant. Rojo will raise an error if the string isn't a valid variant for the enum. There are some cases where this syntax for assigning properties doesn't work. In these cases, Rojo requires you to use the explicit property syntax. Some reasons why you might need to use an explicit property: Using exotic property types like BinaryString Using properties added to Roblox recently that Rojo doesn't know about yet The shape of explicit property values is defined by the rbx-dom library, so it uses slightly different conventions than the rest of Rojo. Each value should be an object with the following required fields: Type : The type of property to represent. Supported types can be found here . Value : The value of the property. The shape of this field depends on which property type is being used. Vector3 and Color3 values are both represented as a list of numbers, while BinaryString expects a base64-encoded string, for example. Here's the same object, but with explicit properties: \"MyPart\" : { \"$className\" : \"Part\" , \"$properties\" : { \"Size\" : { \"Type\" : \"Vector3\" , \"Value\" : [ 3 , 5 , 3 ] }, \"Color\" : { \"Type\" : \"Color3\" , \"Value\" : [ 0.5 , 0 , 0.5 ] }, \"Anchored\" : { \"Type\" : \"Bool\" , \"Value\" : true }, \"Material\" : { \"Type\" : \"Enum\" , \"Value\" : 832 } } } Example Projects \u00b6 This project bundles up everything in the src directory. It'd be suitable for making a plugin or model: { \"name\" : \"AwesomeLibrary\" , \"tree\" : { \"$path\" : \"src\" } } This project describes the layout you might use if you were making the next hit simulator game, Sisyphus Simulator : { \"name\" : \"Sisyphus Simulator\" , \"tree\" : { \"$className\" : \"DataModel\" , \"HttpService\" : { \"$className\" : \"HttpService\" , \"$properties\" : { \"HttpEnabled\" : true } }, \"ReplicatedStorage\" : { \"$className\" : \"ReplicatedStorage\" , \"$path\" : \"src/ReplicatedStorage\" }, \"StarterPlayer\" : { \"$className\" : \"StarterPlayer\" , \"StarterPlayerScripts\" : { \"$className\" : \"StarterPlayerScripts\" , \"$path\" : \"src/StarterPlayerScripts\" } }, \"Workspace\" : { \"$className\" : \"Workspace\" , \"$properties\" : { \"Gravity\" : 67.3 }, \"Terrain\" : { \"$path\" : \"Terrain.rbxm\" } } } }","title":"Project Format"},{"location":"0.5.x/reference/project-format/#project-file","text":"Rojo projects are JSON files that have the .project.json extension. They have the following fields: name : A string indicating the name of the project. This name is used when building the project into a model or place file. Required tree : An Instance Description describing the root instance of the project. Required servePort : The port that rojo serve should listen on. Passing --port will override this setting. Optional Default is 34872 servePlaceIds : A list of place IDs that this project may be live-synced to. This feature can help prevent overwriting the wrong game with source from Rojo. Optional Default is null","title":"Project File"},{"location":"0.5.x/reference/project-format/#instance-description","text":"Instance Descriptions correspond one-to-one with the actual Roblox Instances in the project. $className : The ClassName of the Instance being described. Optional if $path is specified. $path : The path on the filesystem to pull files from into the project. Optional if $className is specified. Paths are relative to the folder containing the project file. $properties : Properties to apply to the instance. Values should be Instance Property Values . Optional $ignoreUnknownInstances : Whether instances that Rojo doesn't know about should be deleted. Optional Default is false if $path is specified, otherwise true . All other fields in an Instance Description are turned into instances whose name is the key. These values should also be Instance Descriptions! Instance Descriptions are fairly verbose and strict. In the future, it'll be possible for Rojo to infer class names for known services like Workspace .","title":"Instance Description"},{"location":"0.5.x/reference/project-format/#instance-property-value","text":"There are two kinds of property values on instances, implicit and explicit . In the vast majority of cases, you should be able to use implicit property values. To use them, just use a value that's the same shape as the type that the property has: \"MyPart\" : { \"$className\" : \"Part\" , \"$properties\" : { \"Size\" : [ 3 , 5 , 3 ], \"Color\" : [ 0.5 , 0 , 0.5 ], \"Anchored\" : true , \"Material\" : \"Granite\" } } Vector3 and Color3 properties can just be arrays of numbers, as can types like Vector2 , CFrame , and more! Enums can be set to a string containing the enum variant. Rojo will raise an error if the string isn't a valid variant for the enum. There are some cases where this syntax for assigning properties doesn't work. In these cases, Rojo requires you to use the explicit property syntax. Some reasons why you might need to use an explicit property: Using exotic property types like BinaryString Using properties added to Roblox recently that Rojo doesn't know about yet The shape of explicit property values is defined by the rbx-dom library, so it uses slightly different conventions than the rest of Rojo. Each value should be an object with the following required fields: Type : The type of property to represent. Supported types can be found here . Value : The value of the property. The shape of this field depends on which property type is being used. Vector3 and Color3 values are both represented as a list of numbers, while BinaryString expects a base64-encoded string, for example. Here's the same object, but with explicit properties: \"MyPart\" : { \"$className\" : \"Part\" , \"$properties\" : { \"Size\" : { \"Type\" : \"Vector3\" , \"Value\" : [ 3 , 5 , 3 ] }, \"Color\" : { \"Type\" : \"Color3\" , \"Value\" : [ 0.5 , 0 , 0.5 ] }, \"Anchored\" : { \"Type\" : \"Bool\" , \"Value\" : true }, \"Material\" : { \"Type\" : \"Enum\" , \"Value\" : 832 } } }","title":"Instance Property Value"},{"location":"0.5.x/reference/project-format/#example-projects","text":"This project bundles up everything in the src directory. It'd be suitable for making a plugin or model: { \"name\" : \"AwesomeLibrary\" , \"tree\" : { \"$path\" : \"src\" } } This project describes the layout you might use if you were making the next hit simulator game, Sisyphus Simulator : { \"name\" : \"Sisyphus Simulator\" , \"tree\" : { \"$className\" : \"DataModel\" , \"HttpService\" : { \"$className\" : \"HttpService\" , \"$properties\" : { \"HttpEnabled\" : true } }, \"ReplicatedStorage\" : { \"$className\" : \"ReplicatedStorage\" , \"$path\" : \"src/ReplicatedStorage\" }, \"StarterPlayer\" : { \"$className\" : \"StarterPlayer\" , \"StarterPlayerScripts\" : { \"$className\" : \"StarterPlayerScripts\" , \"$path\" : \"src/StarterPlayerScripts\" } }, \"Workspace\" : { \"$className\" : \"Workspace\" , \"$properties\" : { \"Gravity\" : 67.3 }, \"Terrain\" : { \"$path\" : \"Terrain.rbxm\" } } } }","title":"Example Projects"},{"location":"0.5.x/reference/sync-details/","text":"This page aims to describe how Rojo turns files on the filesystem into Roblox objects. Overview Limitations Folders Scripts Localization Tables Plain Text Files JSON Models Binary and XML Models Meta Files Meta Files to set Rojo metadata Meta Files for Disabled Scripts Meta Files for Tools Overview \u00b6 File Name Instance Type any directory Folder *.server.lua Script *.client.lua LocalScript *.lua ModuleScript *.csv LocalizationTable *.txt StringValue *.model.json Any *.rbxm Any *.rbxmx Any *.meta.json Modifies another instance Limitations \u00b6 Not all property types can be synced by Rojo in real-time due to limitations of the Roblox Studio plugin API. In these cases, you can usually generate a place file and open it when you start working on a project. Some common cases you might hit are: Binary data (Terrain, CSG, CollectionService tags) MeshPart.MeshId HttpService.HttpEnabled For a list of all property types that Rojo can reason about, both when live-syncing and when building place files, look at rbx-dom's type coverage chart . This limitation may be solved by issue #205 in the future. Folders \u00b6 Any directory on the filesystem will turn into a Folder instance unless it contains an 'init' script, described below. Scripts \u00b6 The default script type in Rojo projects is ModuleScript , since most scripts in well-structued Roblox projects will be modules. If a directory contains a file named init.server.lua , init.client.lua , or init.lua , that folder will be transformed into a *Script instance with the contents of the 'init' file. This can be used to create scripts inside of scripts. For example, these files: Will turn into these instances in Roblox: Localization Tables \u00b6 Any CSV files are transformed into LocalizationTable instances. Rojo expects these files to follow the same format that Roblox does when importing and exporting localization information. Plain Text Files \u00b6 Plain text files ( .txt ) files are transformed into StringValue instances. This is useful for bringing in text data that can be read by scripts at runtime. JSON Models \u00b6 Files ending in .model.json can be used to describe simple models. They're designed to be hand-written and are useful for instances like RemoteEvent . A JSON model describing a folder containing a Part and a RemoteEvent could be described as: { \"Name\" : \"My Cool Model\" , \"ClassName\" : \"Folder\" , \"Children\" : [ { \"Name\" : \"RootPart\" , \"ClassName\" : \"Part\" , \"Properties\" : { \"Size\" : { \"Type\" : \"Vector3\" , \"Value\" : [ 4 , 4 , 4 ] } } }, { \"Name\" : \"SendMoney\" , \"ClassName\" : \"RemoteEvent\" } ] } It would turn into instances in this shape: Warning Starting in Rojo 0.5.0 (stable), the Name field is no longer required. The name of the top-level instance in a JSON model is now based on its file name, and the Name field is now ignored. Rojo will emit a warning if the Name field is specified and does not match the file's name. Binary and XML Models \u00b6 Rojo supports both binary ( .rbxm ) and XML ( .rbxmx ) models generated by Roblox Studio or another tool. Support for the rbxmx is very good, while support for rbxm is still very early, buggy, and lacking features. For a rundown of supported types, check out rbx-dom's type coverage chart . Meta Files \u00b6 New in Rojo 0.5.0-alpha.12 are meta files, named .meta.json . Meta files allow attaching extra Rojo data to models defined in other formats, like Roblox's rbxm and rbxmx model formats, or even Lua scripts. This can be used to set Rojo-specific settings like ignoreUnknownInstances , or can be used to set properties like Disabled on a script. Meta files can contain: className : Changes the className of a containing Folder into something else. Usable only in init.meta.json files properties : A map of properties to set on the instance, just like projects Usable on anything except .rbxmx , .rbxm , and .model.json files, which already have properties ignoreUnknownInstances : Works just like $ignoreUnknownInstances in project files Meta Files to set Rojo metadata \u00b6 Sometimes it's useful to apply properties like ignoreUnknownInstances on instances that are defined on the filesystem instead of within the project itself. If your project has hello.txt and there are instances underneath it that you want Rojo to ignore when live-syncing, you could create hello.meta.json with: { \"ignoreUnknownInstances\" : true } Meta Files for Disabled Scripts \u00b6 Meta files can be used to set properties on Script instances, like Disabled . If your project has foo.server.lua and you want to make sure it would be disabled, you could create a foo.meta.json next to it with: { \"properties\" : { \"Disabled\" : true } } Meta Files for Tools \u00b6 If you wanted to represent a tool containing a script and a model for its handle, create a directory with an init.meta.json file in it: { \"className\" : \"Tool\" , \"properties\" : { \"Grip\" : [ 0 , 0 , 0 , 1 , 0 , 0 , 0 , 1 , 0 , 0 , 0 , 1 ] } } Instead of a Folder instance, you'll end up with a Tool instance with the Grip property set!","title":"Sync Details"},{"location":"0.5.x/reference/sync-details/#overview","text":"File Name Instance Type any directory Folder *.server.lua Script *.client.lua LocalScript *.lua ModuleScript *.csv LocalizationTable *.txt StringValue *.model.json Any *.rbxm Any *.rbxmx Any *.meta.json Modifies another instance","title":"Overview"},{"location":"0.5.x/reference/sync-details/#limitations","text":"Not all property types can be synced by Rojo in real-time due to limitations of the Roblox Studio plugin API. In these cases, you can usually generate a place file and open it when you start working on a project. Some common cases you might hit are: Binary data (Terrain, CSG, CollectionService tags) MeshPart.MeshId HttpService.HttpEnabled For a list of all property types that Rojo can reason about, both when live-syncing and when building place files, look at rbx-dom's type coverage chart . This limitation may be solved by issue #205 in the future.","title":"Limitations"},{"location":"0.5.x/reference/sync-details/#folders","text":"Any directory on the filesystem will turn into a Folder instance unless it contains an 'init' script, described below.","title":"Folders"},{"location":"0.5.x/reference/sync-details/#scripts","text":"The default script type in Rojo projects is ModuleScript , since most scripts in well-structued Roblox projects will be modules. If a directory contains a file named init.server.lua , init.client.lua , or init.lua , that folder will be transformed into a *Script instance with the contents of the 'init' file. This can be used to create scripts inside of scripts. For example, these files: Will turn into these instances in Roblox:","title":"Scripts"},{"location":"0.5.x/reference/sync-details/#localization-tables","text":"Any CSV files are transformed into LocalizationTable instances. Rojo expects these files to follow the same format that Roblox does when importing and exporting localization information.","title":"Localization Tables"},{"location":"0.5.x/reference/sync-details/#plain-text-files","text":"Plain text files ( .txt ) files are transformed into StringValue instances. This is useful for bringing in text data that can be read by scripts at runtime.","title":"Plain Text Files"},{"location":"0.5.x/reference/sync-details/#json-models","text":"Files ending in .model.json can be used to describe simple models. They're designed to be hand-written and are useful for instances like RemoteEvent . A JSON model describing a folder containing a Part and a RemoteEvent could be described as: { \"Name\" : \"My Cool Model\" , \"ClassName\" : \"Folder\" , \"Children\" : [ { \"Name\" : \"RootPart\" , \"ClassName\" : \"Part\" , \"Properties\" : { \"Size\" : { \"Type\" : \"Vector3\" , \"Value\" : [ 4 , 4 , 4 ] } } }, { \"Name\" : \"SendMoney\" , \"ClassName\" : \"RemoteEvent\" } ] } It would turn into instances in this shape: Warning Starting in Rojo 0.5.0 (stable), the Name field is no longer required. The name of the top-level instance in a JSON model is now based on its file name, and the Name field is now ignored. Rojo will emit a warning if the Name field is specified and does not match the file's name.","title":"JSON Models"},{"location":"0.5.x/reference/sync-details/#binary-and-xml-models","text":"Rojo supports both binary ( .rbxm ) and XML ( .rbxmx ) models generated by Roblox Studio or another tool. Support for the rbxmx is very good, while support for rbxm is still very early, buggy, and lacking features. For a rundown of supported types, check out rbx-dom's type coverage chart .","title":"Binary and XML Models"},{"location":"0.5.x/reference/sync-details/#meta-files","text":"New in Rojo 0.5.0-alpha.12 are meta files, named .meta.json . Meta files allow attaching extra Rojo data to models defined in other formats, like Roblox's rbxm and rbxmx model formats, or even Lua scripts. This can be used to set Rojo-specific settings like ignoreUnknownInstances , or can be used to set properties like Disabled on a script. Meta files can contain: className : Changes the className of a containing Folder into something else. Usable only in init.meta.json files properties : A map of properties to set on the instance, just like projects Usable on anything except .rbxmx , .rbxm , and .model.json files, which already have properties ignoreUnknownInstances : Works just like $ignoreUnknownInstances in project files","title":"Meta Files"},{"location":"0.5.x/reference/sync-details/#meta-files-to-set-rojo-metadata","text":"Sometimes it's useful to apply properties like ignoreUnknownInstances on instances that are defined on the filesystem instead of within the project itself. If your project has hello.txt and there are instances underneath it that you want Rojo to ignore when live-syncing, you could create hello.meta.json with: { \"ignoreUnknownInstances\" : true }","title":"Meta Files to set Rojo metadata"},{"location":"0.5.x/reference/sync-details/#meta-files-for-disabled-scripts","text":"Meta files can be used to set properties on Script instances, like Disabled . If your project has foo.server.lua and you want to make sure it would be disabled, you could create a foo.meta.json next to it with: { \"properties\" : { \"Disabled\" : true } }","title":"Meta Files for Disabled Scripts"},{"location":"0.5.x/reference/sync-details/#meta-files-for-tools","text":"If you wanted to represent a tool containing a script and a model for its handle, create a directory with an init.meta.json file in it: { \"className\" : \"Tool\" , \"properties\" : { \"Grip\" : [ 0 , 0 , 0 , 1 , 0 , 0 , 0 , 1 , 0 , 0 , 0 , 1 ] } } Instead of a Folder instance, you'll end up with a Tool instance with the Grip property set!","title":"Meta Files for Tools"}]}
|
