Skip to content

Contributing

Jump to bottom
Lucas Resch edited this page Apr 17, 2020 · 1 revision

This section of the wiki is for those that wish to contribute to this project. It should detail all steps necessary to setup a working development environment, how to use it and how to get your contributions into upcoming releases. Please read the following carefully.

If you find any errors or encounter problems while following the instructions below let us know with an issue or pull request.

Development environment setup

Install an IDE of your choice

Get yourself an IDE made for .NET development. The obvious choice would either be Visual Studio or JetBrains Rider.

An important feature is the ability to decompile DLL files to look at the code of dependent modules, e.g. the official Bannerlord modules.

In order to get this functionality for Visual Studio you have to look into dotPeek or ReSharper.

JetBrains Rider is built around ReSharper so you will most likely not have to install any other software if you go with it.

Set up your local repository

  • Fork the repository
  • Clone the forked repository
  • Navigate to the repository on disk
  • Navigate to the Extension folder
  • Open the YetAnotherPartyOrganiser.props file with a text editor
  • Modify the <GameFolder> tag so it actually points to your installation of Bannerlord
  • Open a console within the Extension folder and run following command
git update-index --skip-worktree YetAnotherPartyOrganiser.props

Now open the YetAnotherPartyOrganiser.sln with your IDE and check that all dependencies are resolved and there are no build errors.

Development workflow

This section gives a few pointers regarding how to use the solution setup above and how to contribute changes to the project.

Building, running and debugging the solution

When building the solution from within the IDE the build artifacts are written to your Bannerlord modules folder. That way you can simply start the launcher and select the mod in order to test your changes. Be aware that this will overwrite any other version of this mod that was already installed.

It is also possible to run the Game right out of your IDE. It will then start the game with all official modules and required dependencies preselected. This way you are also able to debug our code by setting breakpoints within the code. For this you must select the Debug mode though.

Git workflow

We know everyone is doing it a little differently but since branches and especially commits, if done right, are some of the most important bits of a projects documentation the following will give some basic guidelines.

Working with branches

If you are working on an issue it is usually best to create a new branch to aggregate your development progress relating to this change. In order to do so first checkout the master branch and get the newest version of this branch. Then create a new branch titled with <type>/<name>, where <type> should either be feature or bug depending on the nature of your change. The <name> of your branch should be a concise summary of what you are working on. If this relates to a specific issue its a good practice to include its number in the name.

Commit messages

Writing good commit messages isn't always easy but they serve essential tasks when developing software in a team:

  • Easily convey why something was done
  • Speed up the review process
  • Enable the continued maintenance of the mod.
  • Act as a critical part of a projects documentation

The following guidelines shall serve as best practices to be applied when ever possible. We are mostly basing them on this wiki entry from the Erlang language.

Short (50 chars or less) summary of changes

More detailed explanatory text, if necessary.  Wrap it to about 72
characters or so.  In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body.  The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.

Further paragraphs come after blank lines.

  - Bullet points are okay, too

  - Typically a hyphen or asterisk is used for the bullet, preceded by a
    single space, with blank lines in between, but conventions vary here

DO

  • Keep the title short and concise
  • Always leave the second line blank, except when omitting the body
  • Wrap all other lines around 72 characters to prevent horizontal scrolling

DON'T

  • Do not end the title with a period

Tips

  • If it is hard to summarize your changes, it may be a sign that you should split them up into multiple commits
Clone this wiki locally