Getting involved / Helping

[Blipi]

Hello,

I've recently discovered this project while searching for a better alternative to Bukkit/Spigot and so on. I compiled the latest version and tried it out. I does work amazingly good, it barely uses resources and it's blazing fast.

I however saw it's lacking some features (no pun intended, really) and has some bugs. Therefore, I'd like to help with everything I could. I have a good level of C++ and I believe I could do something useful.

That said, the code base is quite big and I can't seem to find a general guide on where to start. I'd find it ideal to start by solving realtively easy issues (I've had a look on Github issues but know nothing of their difficulty) and getting used to the cody, style, standards and so on.

So, to sum up, would you please guide me on what I could do and where to look?

Thank ou!

PS: In case you need it: https://github.com/blipi

[LogicParrot]

Even though it does not answer your question, this could help you:
https://forum.cuberite.org/showthread.php?tid=499

[bearbin]

There's also this: https://github.com/mc-server/MCServer/bl...IBUTING.md

[sphinxc0re]

Even though it does not answer your question, this could help you:
https://forum.cuberite.org/showthread.php?tid=499

This is not really up-to-date though

[NiLSPACE]

Then comment what's new and I'll update it for you

[xoft]

Hello, welcome to the community.
Some issues on GitHub are marked with the "easy" label, those should be good for people starting to tinker in the server. See if there's anything you'd like to try: https://github.com/mc-server/MCServer/is...bel%3Aeasy (also note that some people have expressed interest in solving some of them, see the comments inside on whether someone's working on it or not)

When coding, try to observe the code style. I personally am very strict about it There's a script file, $/src/CheckBasicStyle.lua, that will help you by checking some of the easily-detected style violations. This script is being run as part of the integration tests, so your code needs to pass it.

As for commit granularity, the general rule of thumb is to make changes in reasonable "chunks", so that each chunk is one logical change that could be later viewed in the history and, if needed, reverse-merged to undo just the one change. We don't need you to squash your commits into one before submitting a PR, and we don't want a thousand of little commits pertaining to a single logical change. If in doubt, imagine yourself looking at a specific line in a file in the "git blame" viewer and whether your commit description would enlighten you as to why it was needed.