diff --git a/Jenkinsfile b/Jenkinsfile index a627ead7c5..15a40c7eb6 100644 --- a/Jenkinsfile +++ b/Jenkinsfile @@ -84,7 +84,7 @@ pipeline { } stage('Report Progress') { when { - branch 'master' + branch 'main' } steps { sh 'mkdir reports' @@ -96,7 +96,7 @@ pipeline { } stage('Update Progress') { when { - branch 'master' + branch 'main' } agent{ label 'zeldaret_website' diff --git a/README.md b/README.md index d94b47950a..89d651dbdb 100644 --- a/README.md +++ b/README.md @@ -2,8 +2,8 @@ [![Build Status][jenkins-badge]][jenkins] [![Decompilation Progress][progress-badge]][progress] [![Contributors][contributors-badge]][contributors] [![Discord Channel][discord-badge]][discord] -[jenkins]: https://jenkins.deco.mp/job/MM/job/master -[jenkins-badge]: https://img.shields.io/jenkins/build?jobUrl=https%3A%2F%2Fjenkins.deco.mp%2Fjob%2FMM%2Fjob%2Fmaster +[jenkins]: https://jenkins.deco.mp/job/MM/job/main +[jenkins-badge]: https://img.shields.io/jenkins/build?jobUrl=https%3A%2F%2Fjenkins.deco.mp%2Fjob%2FMM%2Fjob%2Fmain [progress]: https://zelda64.dev/games/mm [progress-badge]: https://img.shields.io/endpoint?url=https://zelda64.dev/assets/csv/progress-mm-shield.json diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 2a5578e4ed..f5a0428465 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -4,19 +4,19 @@ Thanks for helping us reverse engineer *The Legend of Zelda: Majora's Mask* for All contributions are welcome. This is a group effort, and even small contributions can make a difference. Some tasks also don't require much knowledge to get started. This document is meant to be a set of tips and guidelines for contributing to the project. -For general information about the project, see [our readme](https://github.com/zeldaret/mm/blob/master/README.md). +For general information about the project, see [our readme](https://github.com/zeldaret/mm/blob/main/README.md). Most discussions happen on our [Discord Server](https://discord.zelda64.dev) where you are welcome to ask if you need help getting started, or if you have any questions regarding this project and other decompilation projects. ## Useful Links -- [Installation guide](https://github.com/zeldaret/mm/blob/master/README.md#installation) - Instructions for getting this repository set up and built on your machine. +- [Installation guide](https://github.com/zeldaret/mm/blob/main/README.md#installation) - Instructions for getting this repository set up and built on your machine. - [Style Guide](STYLE.md) - Description of the project style that we ask contributors to adhere to. - [Code Review Guidelines](REVIEWING.md) - These are the guidelines that reviewers will be using when reviewing your code. Good to be familiar with these before submitting your code. - [Zelda 64 Reverse Engineering Website](https://zelda64.dev/games/mm) - Our homepage, with FAQ and progress graph :chart_with_upwards_trend:. - [MM decomp tutorial](tutorial/contents.md) Detailed tutorial for learning in general how decomp works and how to decompile a small, simple file. -- [Introduction to OOT decomp](https://github.com/zeldaret/oot/blob/master/docs/tutorial/contents.md) - The tutorial the MM one was based on. For OOT, but largely applicable to MM as well. Covers slightly different topics, including how to get your data OK with `vbindiff`. +- [Introduction to OOT decomp](https://github.com/zeldaret/oot/blob/main/docs/tutorial/contents.md) - The tutorial the MM one was based on. For OOT, but largely applicable to MM as well. Covers slightly different topics, including how to get your data OK with `vbindiff`. - The `#resources` channel on the Discord contains many more links on specific details of decompiling IDO MIPS code. ## Getting Started @@ -37,7 +37,7 @@ This project only uses *publicly available code*. ### Environment Setup -Get started by following the [installation guide in the readme](https://github.com/zeldaret/mm/blob/master/README.md#installation). +Get started by following the [installation guide in the readme](https://github.com/zeldaret/mm/blob/main/README.md#installation). You should be able to build a matching ROM before you start making any changes. ### First Contribution @@ -142,8 +142,8 @@ Project leads are responsible for ensuring that these conventions are followed. ### Some git notes -- You should work on a branch on your fork separate from your copy of master: it is always useful to have a clean master branch around if you need to fix something. -- When a PR is merged into master, it may conflict with your work. While your branch is private (in particular, not used for a PR), you can rebase, but when your branch is public/used for a PR always merge master instead of rebasing: it makes it much easier for people to understand what you changed since the last review. +- You should work on a branch on your fork separate from your copy of main: it is always useful to have a clean main branch around if you need to fix something. +- When a PR is merged into main, it may conflict with your work. While your branch is private (in particular, not used for a PR), you can rebase, but when your branch is public/used for a PR always merge main instead of rebasing: it makes it much easier for people to understand what you changed since the last review. - We squash commits when merging, so your commit history does not have to be completely spotless. Throughout the PR process, you (the author) should update the rows on the appropriate Google Sheets with the appropriate information as the decompilation process progresses. diff --git a/docs/REVIEWING.md b/docs/REVIEWING.md index b7f97bdea9..3fc160729e 100644 --- a/docs/REVIEWING.md +++ b/docs/REVIEWING.md @@ -5,7 +5,7 @@ We encourage all contributors to participate in code review: this is your codeba Every review submitted helps us keep code quality high and code merged in more quickly. This document is meant to be a set of tips and guidelines for reviewers of pull requests to the project. -For general information about the project, see [our readme](https://github.com/zeldaret/mm/blob/master/README.md). +For general information about the project, see [our readme](https://github.com/zeldaret/mm/blob/main/README.md). Most discussions happen on our [Discord Server](https://discord.zelda64.dev) where you are welcome to ask if you need help getting started, or if you have any questions regarding this project and other decompilation projects. diff --git a/docs/tutorial/beginning_decomp.md b/docs/tutorial/beginning_decomp.md index 591f12a2b2..2685f9276a 100644 --- a/docs/tutorial/beginning_decomp.md +++ b/docs/tutorial/beginning_decomp.md @@ -175,7 +175,7 @@ The Init function sets up the various components of the actor when it is first l The first stage of decompilation is done by a program called mips_to_c, often referred to as mips2c, which constructs a C interpretation of the assembly code based on reading it very literally. This means that considerable cleanup will be required to turn it into something that firstly compiles at all, and secondly looks like a human wrote it, let alone a Zelda developer from the late '90s. -The web version of mips2c can be found [here](https://simonsoftware.se/other/mips_to_c.py). This was [covered in the OoT tutorial](https://github.com/zeldaret/oot/blob/master/docs/tutorial/beginning_decomp.md). We shall instead use the repository. Clone [the mips_to_c repository](https://github.com/matt-kempster/mips_to_c) into a separate directory (we will assume on the same level as the `mm/` directory). Since it's Python, we don't have to do any compilation or anything in the mips_to_c directory. +The web version of mips2c can be found [here](https://simonsoftware.se/other/mips_to_c.py). This was [covered in the OoT tutorial](https://github.com/zeldaret/oot/blob/main/docs/tutorial/beginning_decomp.md). We shall instead use the repository. Clone [the mips_to_c repository](https://github.com/matt-kempster/mips_to_c) into a separate directory (we will assume on the same level as the `mm/` directory). Since it's Python, we don't have to do any compilation or anything in the mips_to_c directory. Since the actor depends on the rest of the codebase, we can't expect to get much intelligible out of mips2c without giving it some context. We make this using a Python script in the `tools` directory called `m2ctx.py`, so run @@ -686,7 +686,7 @@ as our first guess. This doesn't look unreasonable... the question is, does it m Once preliminary cleanup and struct filling is done, most time spent matching functions is done by comparing the original code with the code you have compiled. This is aided by a program called `diff.py`. -In order to use `diff.py` with the symbol names, we need a copy of the code to compare against. In MM this is done as part of `make init`, and you can regenerate the `expected` directory (which is simply a known-good copy of `build` directory) by running `make diff-init`, which will check for an OK ROM and copy the build directory over. (Of course you need an OK ROM to do this; worst-case, you can checkout master and do a complete rebuild to get it). (You need to remake `expected` if you want to diff a function you have renamed: `diff.py` looks in the mapfiles for the function name, which won't work if the name has changed!) +In order to use `diff.py` with the symbol names, we need a copy of the code to compare against. In MM this is done as part of `make init`, and you can regenerate the `expected` directory (which is simply a known-good copy of `build` directory) by running `make diff-init`, which will check for an OK ROM and copy the build directory over. (Of course you need an OK ROM to do this; worst-case, you can checkout main and do a complete rebuild to get it). (You need to remake `expected` if you want to diff a function you have renamed: `diff.py` looks in the mapfiles for the function name, which won't work if the name has changed!) Now, we run diff on the function name: in the main directory, diff --git a/docs/tutorial/data.md b/docs/tutorial/data.md index 6884ebb125..07ea8cfaca 100644 --- a/docs/tutorial/data.md +++ b/docs/tutorial/data.md @@ -27,7 +27,7 @@ Both approaches have their advantages and disadvantages. ## Data first -This way is good for smaller actors with little data. The OoT tutorial [covers this in plenty of detail](https://github.com/zeldaret/oot/blob/master/docs/tutorial/data.md), and the process in MM is essentially identical, so we won't go over it here. +This way is good for smaller actors with little data. The OoT tutorial [covers this in plenty of detail](https://github.com/zeldaret/oot/blob/main/docs/tutorial/data.md), and the process in MM is essentially identical, so we won't go over it here. ## Extern and data last diff --git a/docs/tutorial/diff_and_permuter.md b/docs/tutorial/diff_and_permuter.md index 2b5d41e307..e8d0f59f7c 100644 --- a/docs/tutorial/diff_and_permuter.md +++ b/docs/tutorial/diff_and_permuter.md @@ -2,7 +2,7 @@ This document is intended as a step-by-step demonstration of matching a reasonably complex function using the diff script `diff.py` and the decomp permuter, both included in the repo. For general information on both see [the tools documentation](../tools.md). -Until such time as someone finds a suitable function, you can look at the OoT tutorial: [here for diff.py](https://github.com/zeldaret/oot/blob/master/docs/tutorial/beginning_decomp.md#diff) and [here for the permuter](https://github.com/zeldaret/oot/blob/master/docs/tutorial/other_functions.md#the-permuter). +Until such time as someone finds a suitable function, you can look at the OoT tutorial: [here for diff.py](https://github.com/zeldaret/oot/blob/main/docs/tutorial/beginning_decomp.md#diff) and [here for the permuter](https://github.com/zeldaret/oot/blob/main/docs/tutorial/other_functions.md#the-permuter).