NOISSUE update README.md

It has not been touched in a long time. This brings it a bit more up to date.
This commit is contained in:
Petr Mrázek 2021-08-29 02:12:09 +02:00
parent d4a3fc5195
commit 1e1655bc4b

View File

@ -5,15 +5,14 @@
MultiMC 5 MultiMC 5
========= =========
MultiMC is a custom launcher for Minecraft that allows you to easily manage multiple installations of Minecraft at once. It also allows you to easily install and remove mods by simply dragging and dropping. Here are the current [features](https://github.com/MultiMC/MultiMC5/wiki#features) of MultiMC. MultiMC is a custom launcher for Minecraft that focuses on predictability, long term stability and simplicity.
## Development ## Development
The project uses C++ and Qt5 as the language and base framework. This might seem odd in the Minecraft community, but allows using 25MB of RAM, where other tools use an excessive amount of resources for no reason. If you want to contribute, talk to us on [Discord](https://discord.gg/multimc) first.
We can do more, with less, on worse hardware and leave more resources for the game while keeping the launcher running and providing extra features. While blindly submitting PRs is definitely possible, they're not necessarily going to get accepted.
If you want to contribute, either talk to us on [Discord](https://discord.gg/multimc), [IRC](http://webchat.esper.net/?nick=&channels=MultiMC)(esper.net/#MultiMC) or pick up some item from the github issues [workflowy](https://github.com/MultiMC/MultiMC5/issues) - there is always plenty of ideas around. We aren't looking for flashy features, but expanding upon the existing feature set without distruption or endangering future viability of the project is OK.
### Building ### Building
If you want to build MultiMC yourself, check [BUILD.md](BUILD.md) for build instructions. If you want to build MultiMC yourself, check [BUILD.md](BUILD.md) for build instructions.
@ -21,19 +20,21 @@ If you want to build MultiMC yourself, check [BUILD.md](BUILD.md) for build inst
### Code formatting ### Code formatting
Just follow the existing formatting. Just follow the existing formatting.
In general: In general, in order of importance:
* Indent with 4 space unless it's in a submodule * Make sure your IDE is not messing up line endings or whitespace and avoid using linters.
* Keep lists (of arguments, parameters, initializators...) as lists, not paragraphs.
* Prefer readability over dogma. * Prefer readability over dogma.
* Keep to the existing formatting.
* Indent with 4 space unless it's in a submodule.
* Keep lists (of arguments, parameters, initializers...) as lists, not paragraphs. It should either read from top to bottom, or left to right. Not both.
## Translations ## Translations
Translations can be done [on crowdin](https://translate.multimc.org). Translations can be done [on crowdin](https://translate.multimc.org). Please avoid making direct pull requests to the translations repository.
## Forking/Redistributing ## Forking/Redistributing/Custom builds policy
We keep MultiMC open source because we think it's important to be able to see the source code for a project like this, and we do so using the Apache license. We keep MultiMC open source because we think it's important to be able to see the source code for a project like this, and we do so using the Apache license.
Part of the reason for using the Apache license is we don't want people using the "MultiMC" name when redistributing the project. This means people must take the time to go through the source code and remove all references to "MultiMC", including but not limited to the project icon and the title of windows, (no *MultiMC-fork* in the title). Part of the reason for using the Apache license is that we don't want people using the "MultiMC" name when redistributing the project. This means people must take the time to go through the source code and remove all references to "MultiMC", including but not limited to the project icon and the title of windows, (no *MultiMC-fork* in the title).
Apache covers reasonable use for the name - a mention of the project's origins in the About dialog and the license is acceptable. However, it should be abundantly clear that the project is a fork *without* implying that you have our blessing. Apache covers reasonable use for the name - a mention of the project's origins in the About dialog and the license is acceptable. However, it should be abundantly clear that the project is a fork *without* implying that you have our blessing.