Torque 3D's source code lives at GarageGames/Torque3D. To clone a copy of the source code, you will need a git client. We recommend the official client. Once you have installed Git, you should follow GitHub's forking tutorial to make your own repository to which you can commit your code.
The repository has two main branches:
recommend that you do not commit any of your own code into these branches, but
simply pull down changes from GarageGames' repository into them. You can maintain
your own branch (perhaps named after your GitHub username, or the game you're working on)
and merge changes into it as you see fit.
We also have a repository for Torque 3D's Github wiki.
Feel free to fork and pull-request to its
master branch if you
want to submit new documentation, tutorials, or make corrections to existing
Pull requests are the way that community members like you can get your code pulled into the official Torque 3D repository for everyone else to use. We accept community contributions that align with our vision for the engine - especially bug fixes, enhancements to existing features, and revisions of old, slow, or ugly code. Pull requests are the way that code gets reviewed before it's accepted into the engine - even code that we, the Steering Committee, write ourselves. For a technical tutorial on how to submit a pull request, check out this page in our wiki, or this tutorial by GitHub.
In order to ensure the quality of the engine code going into the future, we have strict rules about what code we can and cannot accept. We also have some soft guidelines that inform our decision-making progress in trickier cases.
Pull requests not adhering to these rules cannot be accepted, so pay attention!
In many cases, if any of these rules are breached, we will first ask the contributor to resubmit their pull request, or add commits to it that resolve our issues. In exceptional cases (i.e., we really really like your work), a committee member may perform that work themselves.
Here are some of the things we look for in a great pull request. These aren't hard-and-fast rules, but following these guidelines will increase the chances that your request is pulled!
We maintain an X.Y.z version scheme similar to that of Semantic Versioning. However, since our API is less well-defined, the table below describes what we mean by the three version number components.
Note that this new versioning policy is different to the one adopted by the first and second Steering Committees, and applies only to engine versions 3.5.2 and above.
Major version number
|The major version number denotes a single version of our client-facing API, which refers to the script and editor capabilities exposed to binary-only users of the engine, as well as major parts of the internal C++ API, such as the class hierarchy.|
Minor version number
|The minor version number refers to the set of features in a given API. Across a minor version number change, we may refactor code, fix bugs, or introduce new features, but we will not make breaking changes to existing ones.|
|Patches denote minor updates to stability or correctness that do not change the engine API in a significant way.|
If you find a bug in the engine that you're sure you didn't cause (don't worry, we cause bugs all the time ourselves!), please use the GitHub issue tracker to let us know. Please have a bit of a look at recent issues before you do, in case someone has already noticed the same problem. And remember to provide the following information:
We use a UserVoice forum to monitor feature requests from users. Before making a forum post or starting a new request, check to see if your feature has already been requested.