• View
• Edit
• History
• Print

Contributing

So, you want to contribute to TetraStation? Good on ya!

Prior warning: TetraStation is mostly a personal project, and some of the decisions therein won't necessarily make sense or even really have much of an obvious goal. I will openly say this is my ship, and it's my befuddled hand on the wheel while I'm holding the map upside down. If you disagree with the decisions I'm making, though, feel free to either (politely, please!) argue your point; or just clone the code and go your own way regardless of what I want! (After all, that's how this project started...)

Please do get in touch, via GitHub or via the Discord (if that's your bag. NBD, if not!) Do be aware, though, that I am -- and the people also currently involved are -- unashamedly leftist, mostly queer, and most likely furry. If you're going to butt heads over that, you will not be made welcome.

If you don't want to become part of a bit of a community around the project, but just want to send in bug-fixes or feature upgrades, that's cool too! (Though if you're planning on a *big* feature, it'd be nice if you were part of the community so we can bounce the idea around a bit.)

TetraStation is forked from an older version of TGStation, so if you've already had some code-diving experience there you won't be far wrong; though there has been a fair bit of divergence between the two since then.

For a giggle, or what I'm intending to poke at: my rough TODO list

Source Control

• TetraStation is developed using git for source control, and I would highly recommend also using it. (You don't have to know everything about how to use it, I certainly don't. I just skimmed the basics...)
• I'd strongly recommend doing your development work in a side-branch, and leave the master branch as your 'clean' copy of the main repository. Branches are effectively free, so you can create & discard them willy-nilly as you go along.
• Ideally, git rebase against master whenever you get to a major checkpoint in your development; but definitely before sending a pull-request or a patch, please.
• When making changes to tgui, put the updated compiled tgui bundles (tgui-common.chunk.js, tgui-panel.bundle.js, and tgui.bundle.js) in a separate commit
• I would prefer to receive contributions via github pull requests. If, however, you want to email patches in because you're old-school like that, that's fine too.
• (Optional) Navigate your git command line to the project folder, and git config blame.ignoreRevsFile .git-blame-ignore-revs (This makes git, when finding out what commits have changed what lines, ignore the commits listed in the .git-blame-ignore-revs file; which is a list of commits that make large amounts of changes to whitespace, and can safely be ignored in order to declutter git blame) It's a nice quality-of-life thing.

Code & Developing

• There are some good reference material and resources available for developing in DM code, and BYOND in general: http://www.byond.com/developer/articles/resources; they can also be quite helpful to go through and refresh your memory occasionally, especially as BYOND is updated as time goes on.