ari-party/rojo
1
0
Fork 0
forked from rojo-rbx/rojo
Code Pull Requests Activity

Docs have moved to https://github.com/rojo-rbx/rojo.space

Browse Source
This commit is contained in:
Lucien Greathouse
2020-02-27 22:57:06 -08:00
parent cdfbebd637
commit cf5b72aa9a
23 changed files with 0 additions and 900 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
docs/extra.css
View File

@@ -1,13 +0,0 @@
.md-typeset__table {
width: 100%;
}
.feature-image img {
border: 1px solid rgba(0, 0, 0, 0.2);
box-shadow: 1px 1px 4px rgba(0, 0, 0, 0.2);
}
.codehilite {
border: 1px solid rgba(0, 0, 0, 0.2);
box-shadow: 1px 1px 4px rgba(0, 0, 0, 0.2);
}

11
docs/guide/existing-game.md
View File

@@ -1,11 +0,0 @@
**This page is under construction!**
## Summary
* Tools to port existing games are in progress!
* [rbxlx-to-rojo](https://github.com/rojo-rbx/rbxlx-to-rojo)
* `rojo export` ([issue #208](https://github.com/rojo-rbx/rojo/issues/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!

48
docs/guide/installation.md
View File

@@ -1,48 +0,0 @@
This is this installation guide for Rojo **0.5.x**.
[TOC]
## Overview
Rojo has two components:
* 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.
## Visual Studio Code Extension
If you use Visual Studio Code, you can install [the Rojo VS Code extension](https://marketplace.visualstudio.com/items?itemName=evaera.vscode-rojo), 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
### Installing from GitHub
If you're on Windows, there are pre-built binaries available from Rojo's [GitHub Releases page](https://github.com/LPGhatguy/rojo/releases).
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.
### Installing from Cargo
If you have Rust installed, the easiest way to get Rojo is with Cargo!
To install the latest 0.5.x release, use:
```sh
cargo install rojo
```
If you're upgrading from a previous version of Rojo, you may need to pass `--force` to tell Cargo to overwrite your existing version.
## Installing the Plugin
### Installing from GitHub
The Rojo Roblox Studio plugin is available from Rojo's [GitHub Releases page](https://github.com/LPGhatguy/rojo/releases).
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:
!['Plugins Folder' button in Roblox Studio](../images/plugins-folder-in-studio.png)
{: align="center" }
### Installing from Roblox.com
Visit [Rojo's Roblox.com Plugin page](https://www.roblox.com/library/1997686364) in Roblox Studio and press **Install**.

63
docs/guide/migrating-to-epiphany.md
View File

@@ -1,63 +0,0 @@
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.
[TOC]
## Supporting Both 0.4.x and 0.5.x
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
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:
```json
{
"name": "Rojo 0.4.x Example",
"partitions": {
"path": "src",
"target": "ReplicatedStorage.Source"
}
}
```
In 0.5.x, the project format is more explicit:
```json
{
"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
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
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](../../reference/sync-details) for more information about these new files.

90
docs/guide/new-game.md
View File

@@ -1,90 +0,0 @@
[TOC]
## Creating the Rojo Project
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:
```sh
mkdir my-new-project
cd my-new-project
```
Inside the folder, initialize a new Rojo project:
```sh
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!
```sh
mkdir src
```
Let's also add a Lua file, `hello.lua` to the `src` folder, so that we can make this project our own.
```sh
echo 'return "Hello, Rojo!"' > src/hello.lua
```
## Building Your Place
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`:
```sh
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
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](../installation) 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:
```sh
rojo serve
```
You should see output like this in your terminal:
```sh
$ 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:
![Rojo plugin connection dialog](../images/connection-dialog.png)
{: class="feature-image" align="center" }
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
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:
```sh
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](https://github.com/LPGhatguy/roads)

7
docs/help.md
View File

@@ -1,7 +0,0 @@
Rojo is a fairly complex tool to adopt, but there's a community willing to help!
The [Roblox Open Source Community Discord](https://discord.gg/wH5ncNS) 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](https://github.com/rojo-rbx/rojo/issues).
Rojo's primary maintainer is also available on Twitter, [@LPGhatguy](https://twitter.com/LPGhatguy).

BIN
docs/images/connection-dialog.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 13 KiB

BIN
docs/images/plugins-folder-in-studio.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 19 KiB

17
docs/images/sync-example-files.gv
View File

@@ -1,17 +0,0 @@
digraph "Sync Files" {
graph [
ranksep = "0.7",
nodesep = "0.5",
];
node [
fontname = "monospace",
shape = "record",
];
my_model [label = "MyModel"]
init_server [label = "init.server.lua"]
foo [label = "foo.lua"]
my_model -> init_server
my_model -> foo
}

38
docs/images/sync-example-files.svg
View File

@@ -1,38 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<!-- Generated by graphviz version 2.38.0 (20140413.2041)
-->
<!-- Title: Sync Files Pages: 1 -->
<svg width="258pt" height="132pt"
viewBox="0.00 0.00 258.00 132.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 128)">
<title>Sync Files</title>
<polygon fill="white" stroke="none" points="-4,4 -4,-128 254,-128 254,4 -4,4"/>
<!-- my_model -->
<g id="node1" class="node"><title>my_model</title>
<polygon fill="none" stroke="black" points="104,-87.5 104,-123.5 178,-123.5 178,-87.5 104,-87.5"/>
<text text-anchor="middle" x="141" y="-101.8" font-family="monospace" font-size="14.00">MyModel</text>
</g>
<!-- init_server -->
<g id="node2" class="node"><title>init_server</title>
<polygon fill="none" stroke="black" points="0,-0.5 0,-36.5 140,-36.5 140,-0.5 0,-0.5"/>
<text text-anchor="middle" x="70" y="-14.8" font-family="monospace" font-size="14.00">init.server.lua</text>
</g>
<!-- my_model&#45;&gt;init_server -->
<g id="edge1" class="edge"><title>my_model&#45;&gt;init_server</title>
<path fill="none" stroke="black" d="M126.632,-87.299C116.335,-74.9713 102.308,-58.1787 90.7907,-44.3902"/>
<polygon fill="black" stroke="black" points="93.4435,-42.1065 84.3465,-36.6754 88.0711,-46.594 93.4435,-42.1065"/>
</g>
<!-- foo -->
<g id="node3" class="node"><title>foo</title>
<polygon fill="none" stroke="black" points="176,-0.5 176,-36.5 250,-36.5 250,-0.5 176,-0.5"/>
<text text-anchor="middle" x="213" y="-14.8" font-family="monospace" font-size="14.00">foo.lua</text>
</g>
<!-- my_model&#45;&gt;foo -->
<g id="edge2" class="edge"><title>my_model&#45;&gt;foo</title>
<path fill="none" stroke="black" d="M155.57,-87.299C166.013,-74.9713 180.237,-58.1787 191.917,-44.3902"/>
<polygon fill="black" stroke="black" points="194.659,-46.5681 198.451,-36.6754 189.317,-42.0437 194.659,-46.5681"/>
</g>
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 2.0 KiB

15
docs/images/sync-example-instances.gv
View File

@@ -1,15 +0,0 @@
digraph "Sync Files" {
graph [
ranksep = "0.7",
nodesep = "0.5",
];
node [
fontname = "monospace",
shape = "record",
];
my_model [label = "MyModel (Script)"]
foo [label = "foo (ModuleScript)"]
my_model -> foo
}

28
docs/images/sync-example-instances.svg
View File

@@ -1,28 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<!-- Generated by graphviz version 2.38.0 (20140413.2041)
-->
<!-- Title: Sync Files Pages: 1 -->
<svg width="173pt" height="132pt"
viewBox="0.00 0.00 173.00 132.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 128)">
<title>Sync Files</title>
<polygon fill="white" stroke="none" points="-4,4 -4,-128 169,-128 169,4 -4,4"/>
<!-- my_model -->
<g id="node1" class="node"><title>my_model</title>
<polygon fill="none" stroke="black" points="8,-87.5 8,-123.5 157,-123.5 157,-87.5 8,-87.5"/>
<text text-anchor="middle" x="82.5" y="-101.8" font-family="monospace" font-size="14.00">MyModel (Script)</text>
</g>
<!-- foo -->
<g id="node2" class="node"><title>foo</title>
<polygon fill="none" stroke="black" points="0,-0.5 0,-36.5 165,-36.5 165,-0.5 0,-0.5"/>
<text text-anchor="middle" x="82.5" y="-14.8" font-family="monospace" font-size="14.00">foo (ModuleScript)</text>
</g>
<!-- my_model&#45;&gt;foo -->
<g id="edge1" class="edge"><title>my_model&#45;&gt;foo</title>
<path fill="none" stroke="black" d="M82.5,-87.299C82.5,-75.6626 82.5,-60.0479 82.5,-46.7368"/>
<polygon fill="black" stroke="black" points="86.0001,-46.6754 82.5,-36.6754 79.0001,-46.6755 86.0001,-46.6754"/>
</g>
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 1.4 KiB

17
docs/images/sync-example-json-model.gv
View File

@@ -1,17 +0,0 @@
digraph "Sync Files" {
graph [
ranksep = "0.7",
nodesep = "0.5",
];
node [
fontname = "monospace",
shape = "record",
];
model [label = "My Cool Model (Folder)"]
root_part [label = "RootPart (Part)"]
send_money [label = "SendMoney (RemoteEvent)"]
model -> root_part
model -> send_money
}

38
docs/images/sync-example-json-model.svg
View File

@@ -1,38 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<!-- Generated by graphviz version 2.38.0 (20140413.2041)
-->
<!-- Title: Sync Files Pages: 1 -->
<svg width="390pt" height="132pt"
viewBox="0.00 0.00 390.00 132.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 128)">
<title>Sync Files</title>
<polygon fill="white" stroke="none" points="-4,4 -4,-128 386,-128 386,4 -4,4"/>
<!-- model -->
<g id="node1" class="node"><title>model</title>
<polygon fill="none" stroke="black" points="75,-87.5 75,-123.5 273,-123.5 273,-87.5 75,-87.5"/>
<text text-anchor="middle" x="174" y="-101.8" font-family="monospace" font-size="14.00">My Cool Model (Folder)</text>
</g>
<!-- root_part -->
<g id="node2" class="node"><title>root_part</title>
<polygon fill="none" stroke="black" points="0,-0.5 0,-36.5 140,-36.5 140,-0.5 0,-0.5"/>
<text text-anchor="middle" x="70" y="-14.8" font-family="monospace" font-size="14.00">RootPart (Part)</text>
</g>
<!-- model&#45;&gt;root_part -->
<g id="edge1" class="edge"><title>model&#45;&gt;root_part</title>
<path fill="none" stroke="black" d="M152.954,-87.299C137.448,-74.6257 116.168,-57.2335 99.0438,-43.2377"/>
<polygon fill="black" stroke="black" points="100.972,-40.2938 91.0147,-36.6754 96.5426,-45.7138 100.972,-40.2938"/>
</g>
<!-- send_money -->
<g id="node3" class="node"><title>send_money</title>
<polygon fill="none" stroke="black" points="176,-0.5 176,-36.5 382,-36.5 382,-0.5 176,-0.5"/>
<text text-anchor="middle" x="279" y="-14.8" font-family="monospace" font-size="14.00">SendMoney (RemoteEvent)</text>
</g>
<!-- model&#45;&gt;send_money -->
<g id="edge2" class="edge"><title>model&#45;&gt;send_money</title>
<path fill="none" stroke="black" d="M195.248,-87.299C210.904,-74.6257 232.388,-57.2335 249.677,-43.2377"/>
<polygon fill="black" stroke="black" points="252.213,-45.6878 257.783,-36.6754 247.809,-40.2471 252.213,-45.6878"/>
</g>
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 2.1 KiB

18
docs/index.md
View File

@@ -1,18 +0,0 @@
This is the documentation home for **the Rojo `master` branch**.
!!! warning
Documentation here may not apply to the latest release of Rojo yet.
For documentation for the latest stable release series, 0.5.x, go to:
[https://rojo.space/docs/0.5.x](https://rojo.space/docs/0.5.x)
Available versions of these docs:
* [Latest version from `master` branch](https://rojo.space/docs/latest)
* [0.5.x](https://rojo.space/docs/0.5.x)
* [0.4.x](https://rojo.space/docs/0.4.x)
**Rojo** is a tool designed to enable 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 [Rojo's issue tracker](https://github.com/rojo-rbx/rojo/issues)!

45
docs/internals/overview.md
View File

@@ -1,45 +0,0 @@
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!
[TOC]
## CLI
### RbxTree
Rojo uses a library named [`rbx_tree`](https://github.com/LPGhatguy/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)
Relevant source files:
* [`server/src/imfs.rs`](https://github.com/LPGhatguy/rojo/blob/master/server/src/imfs.rs)
* [`server/src/fs_watcher.rs`](https://github.com/LPGhatguy/rojo/blob/master/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
Relevant source files:
* [`server/src/snapshot_reconciler.rs`](https://github.com/LPGhatguy/rojo/blob/master/server/src/snapshot_reconciler.rs)
* [`server/src/rbx_snapshot.rs`](https://github.com/LPGhatguy/rojo/blob/master/server/src/rbx_snapshot.rs)
* [`server/src/rbx_session.rs`](https://github.com/LPGhatguy/rojo/blob/master/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
Relevant source files:
* [`server/src/web.rs`](https://github.com/LPGhatguy/rojo/blob/master/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
TODO

37
docs/reference/full-vs-partial.md
View File

@@ -1,37 +0,0 @@
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
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
* Fully reproducible builds from scratch
* Everything checked into version control
### Cons
* 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](https://github.com/LPGhatguy/rojo/issues/164))
* Rojo can't manage everything yet
* Refs are currently broken ([issue #142](https://github.com/LPGhatguy/rojo/issues/142))
## Partially Managed
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
* Easier to adopt gradually
* Integrates with Team Create
### Cons
* 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](https://github.com/LPGhatguy/rojo/issues/169))

151
docs/reference/project-format.md
View File

@@ -1,151 +0,0 @@
[TOC]
## Project File
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](#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
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](#instance-property-value).
* **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`](https://github.com/LPGhatguy/rojo/issues/179).
## Instance Property Value
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:
```json
"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](https://github.com/LPGhatguy/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](https://github.com/LPGhatguy/rbx-tree#property-type-coverage).
* `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:
```json
"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
This project bundles up everything in the `src` directory. It'd be suitable for making a plugin or model:
```json
{
"name": "AwesomeLibrary",
"tree": {
"$path": "src"
}
}
```
This project describes the layout you might use if you were making the next hit simulator game, *Sisyphus Simulator*:
```json
{
"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"
}
}
}
}
```

157
docs/reference/sync-details.md
View File

@@ -1,157 +0,0 @@
This page aims to describe how Rojo turns files on the filesystem into Roblox objects.
[TOC]
## Overview
| 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
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](https://github.com/rojo-rbx/rbx-dom#property-type-coverage).
This limitation may be solved by [issue #205](https://github.com/rojo-rbx/rojo/issues/205) in the future.
## Folders
Any directory on the filesystem will turn into a `Folder` instance unless it contains an 'init' script, described below.
## Scripts
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:
![Tree of files on disk](../images/sync-example-files.svg)
{: align="center" }
Will turn into these instances in Roblox:
![Tree of instances in Roblox](../images/sync-example-instances.svg)
{: align="center" }
## Localization Tables
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
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
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:
```json
{
"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:
![Tree of instances in Roblox](../images/sync-example-json-model.svg)
{: align="center" }
!!! 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
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](https://github.com/rojo-rbx/rbx-dom#property-type-coverage).
## Meta Files
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
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:
```json
{
"ignoreUnknownInstances": true
}
```
### Meta Files for Disabled Scripts
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:
```json
{
"properties": {
"Disabled": true
}
}
```
### Meta Files for Tools
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:
```json
{
"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!

3
docs/requirements.txt
View File

@@ -1,3 +0,0 @@
mkdocs
mkdocs-material
pymdown-extensions

23
docs/rojo-alternatives.md
View File

@@ -1,23 +0,0 @@
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](https://github.com/anaminus/rbxmk)
* [Rofresh by Osyris](https://github.com/osyrisrblx/rofresh)
* [RbxRefresh by Osyris](https://github.com/osyrisrblx/RbxRefresh)
* [Studio Bridge by Vocksel](https://github.com/vocksel/studio-bridge)
* [Elixir by Vocksel](https://github.com/vocksel/elixir)
* [RbxSync by evaera](https://github.com/evaera/RbxSync)
* [CodeSync by MemoryPenguin](https://github.com/MemoryPenguin/CodeSync)
* [rbx-exteditor by MemoryPenguin](https://github.com/MemoryPenguin/rbx-exteditor)
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.

44
docs/why-rojo.md
View File

@@ -1,44 +0,0 @@
Adding a tool like Rojo to your Roblox workflow can be daunting, but it comes with some key advantages.
[TOC]
## Rojo at RDC 2019
Nathan Riemer (Kampfkarren) gave a talk at RDC 2019 talking about some of the benefits of using a tool like Rojo.
<iframe style="margin: 0 auto; max-width: 100%" width="560" height="315" src="https://www.youtube-nocookie.com/embed/czlvzEyhaBc" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
## External Text Editors
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](https://code.visualstudio.com) and [Sublime Text](https://www.sublimetext.com).
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](https://marketplace.visualstudio.com/items?itemName=AmaranthineCodices.vscode-rbxlua)
* [Roblox Lua Autocompletes](https://marketplace.visualstudio.com/items?itemName=Kampfkarren.roblox-lua-autofills)
* [TabNine](https://tabnine.com)
## Version Control
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](https://git-scm.com) and [GitHub](https://github.com).
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
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](https://roblox-ts.github.io) 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](https://moonscript.org) and [Haxe](https://haxe.org).
## Other Tools
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](https://github.com/mpeterv/luacheck), a static analysis tool to help you write better Lua
* [ripgrep](https://github.com/BurntSushi/ripgrep), an extremely fast code search tool
* [Tokei](https://github.com/XAMPPRocky/tokei), a tool for statistics like lines of code

37
mkdocs.yml
View File

@@ -1,37 +0,0 @@
site_name: Rojo Documentation
repo_name: rojo-rbx/rojo
repo_url: https://github.com/rojo-rbx/rojo
theme:
name: material
palette:
primary: 'Red'
accent: 'Red'
nav:
- Home: index.md
- Why Rojo?: why-rojo.md
- Get Help with Rojo: help.md
- Guide:
- Installation: guide/installation.md
- Creating a Game with Rojo: guide/new-game.md
- Porting an Existing Game to Rojo: guide/existing-game.md
- Migrating from 0.4.x to 0.5.x: guide/migrating-to-epiphany.md
- Reference:
- Fully vs Partially Managed Rojo: reference/full-vs-partial.md
- Project Format: reference/project-format.md
- Sync Details: reference/sync-details.md
- Rojo Alternatives: rojo-alternatives.md
- Rojo Internals:
- Internals Overview: internals/overview.md
extra_css:
- extra.css
markdown_extensions:
- attr_list
- admonition
- codehilite:
guess_lang: false
- toc:
permalink: true