|
|
|
# Which branch do I use?
|
|
|
|
|
|
|
|
There are two main development branches, `master` and `next`. What do they mean?
|
|
|
|
|
|
|
|
* `master` is netcode-compatible with the latest release tag of SRB2. That means you can compile it and play with anyone using the latest release.
|
|
|
|
* `next` is **netcode-incompatible** with the latest release tag.
|
|
|
|
|
|
|
|
When making your contributions and making Merge Requests, you need to consider the following. Base your code on the correct branch for your change, and things will go smoothly for you.
|
|
|
|
|
|
|
|
## Does my code change game behavior in any way?
|
|
|
|
|
|
|
|
If it does, it must go into `next`. This includes things that might seem like they wouldn't affect consistency in netplay, like cosmetic map object scaling. Even cosmetic changes to things is included in this. Why? Modders can modify most thing behaviors, so your object that is normally cosmetic in vanilla might suddenly not be cosmetic and very significantly impact player behavior.
|
|
|
|
|
|
|
|
## Does my code fix a bug that changes gameplay semantics?
|
|
|
|
|
|
|
|
If it does, it must go into `next`. A bug that changes gameplay would be the conveyer movement issue, for example. In older versions of SRB2, you could spin on a conveyer belt to gain a significant amount of acceleration. This was fixed, but the change breaks netplay compatibility (and time attack demos too, naturally).
|
|
|
|
|
|
|
|
## Does my code cause demos previously recorded to have inconsistency issues?
|
|
|
|
|
|
|
|
If it does, it must go into `next`. Demos rely on the same system as netplay to synchronize the game state.
|
|
|
|
|
|
|
|
## Does my code affect the underlying networking behavior?
|
|
|
|
|
|
|
|
Goes in `next` if it does. This may include things like switching to TCP transfer or modifying the rate of player commands, for example. |
|
|
|
\ No newline at end of file |
