cyberpresidentvanellope/CHOMPStation2
1
0
Fork 0
mirror of https://github.com/CHOMPStation2/CHOMPStation2.git synced 2025-12-09 16:12:17 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update CONTRIBUTING.md

Browse Source
This commit is contained in:
Razgriz
2020-04-11 21:48:38 -07:00
committed by GitHub
parent 2fbc749229
commit 706764161b
1 changed files with 18 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
.github/CONTRIBUTING.md vendored
View File

@@ -1,8 +1,8 @@
# Contributing to Yawn-Wider
# Contributing to CHOMPStation
:+1::tada: First off, thanks for taking the time to contribute! :tada::+1:
The following is a set of guidelines for contributing to Yawn-Wider, which is hosted in the [Yawn-Wider](https://github.com/Yawn-Wider/YWPolarisVore) on GitHub.
The following is a set of guidelines for contributing to Yawn-Wider, which is hosted in the [Chomp Station](https://github.com/CHOMPStation2/CHOMPStation2) on GitHub.
These are just guidelines, not rules, use your best judgment and feel free to propose changes to this document in a pull request.
#### Table Of Contents
@@ -12,7 +12,7 @@ These are just guidelines, not rules, use your best judgment and feel free to pr
[How Can I Contribute?](#how-can-i-contribute)
* [Your First Code Contribution](#your-first-code-contribution)
* [Yawn-Wider Coding Standards](#Yawn-Wider-coding-standards)
* [Chomp Station Coding Standards](#Chomp Station-coding-standards)
* [Pull Requests](#pull-requests)
* [Git Commit Messages](#git-commit-messages)
@@ -30,33 +30,33 @@ By participating, you are expected to uphold this code.
### Your First Code Contribution
Unsure where to begin contributing to Yawn-Wider? You can start by looking through the issues tab.
Unsure where to begin contributing to Chomp Station? You can start by looking through the issues tab.
### Yawn-Wider Coding Standards
### Chomp Station Coding Standards
Any code submissions that do not meet our coding standards are likely to be rejected, or at the very least, have a maintainer request changes on your PR. Save time and follow these standards from the start.
* If it is something like a bugfix that VoreStation or Polaris would want (the codebases we use), code it in their code and make the PR to them. We regularly update from them. They would want any general gameplay bugfixes, and things that are obviously intended to work one way, but do not. They do not have any of our fluff species (vulp, akula, fenn, etc) so do not make PRs related to that, or any vore content to them.
* Never edit stock Polaris or Vore .DMI files. If you are confused about which .DMI files we have added and which were there originally, refer to their repository and and see if they exist (https://github.com/PolarisSS13/Polaris) (https://github.com/VOREStation/VOREStation). All PRs with edits to stock .DMI files might be rejected.
* If it is something like a bugfix that Yawn-Wider or VoreStation or Polaris would want (the codebases we use), code it in their code and make the PR to them. We regularly update from them. They would want any general gameplay bugfixes, and things that are obviously intended to work one way, but do not. They do not have any of our fluff species (vulp, akula, fenn, etc) so do not make PRs related to that, or any vore content to them.
* Never edit stock Polaris or Vore .DMI files. If you are confused about which .DMI files we have added and which were there originally, refer to their repository and and see if they exist (https://github.com/PolarisSS13/Polaris) (https://github.com/VOREStation/VOREStation) (https://github.com/Yawn-Wider/YWPolarisVore). All PRs with edits to stock .DMI files might be rejected.
* When changing any code in any stock Polaris .DM file, you must mark your changes:
* For single-line changes: //Yawn-Wider Edit - "Explanation" (Edit can also be Add for new lines or Removal if you are commenting the line out)
* For multi-line additions: //Yawn-Wider Edit - "Explanation" and then at the bottom of your changes, //Yawn-Wider Edit End
* For single-line changes: //CHOMPEdit - "Explanation" (Edit can also be Add for new lines or Removal if you are commenting the line out)
* For multi-line additions: //CHOMPEdit - "Explanation" and then at the bottom of your changes, //Yawn-Wider Edit End
* For multi-line removals: Use a block comment (/\* xxx \*/) to comment out the existing code block (do not modify whitespace more than necessary) and at the start, it should contain /\* Yawn-Wider Removal - "Reason"
* Change whitespace as little as possible. Do not randomly add/remove whitespace.
* Any new files should have "_yw" at the end. For example, "life_yw.dm". Just make them in the same location as the file they are related to.
* Any new files should have "_ch" at the end. For example, "life_ch.dm". Just make them in the same location as the file they are related to.
* Map changes must be in tgm format. See the [Mapmerge2 Readme] for details.
The `attempt_vr()` proc has been added for your convienence. It allows a many-line change to become a single-line change in the existing Polaris files, preserving mergeability and allowing better code separation while preventing your new code from causing runtimes that stop the original code from running. If you are wanting to inject new procedures into an existing proc, called `update_atoms()` for example, you would create `update_atoms_vr()` in a nearby `_vr.dm` file, and then call to it from a single line in the original `update_atoms()` with `attempt_vr()`.
The `attempt_ch()` proc has been added for your convienence. It allows a many-line change to become a single-line change in the existing Polaris files, preserving mergeability and allowing better code separation while preventing your new code from causing runtimes that stop the original code from running. If you are wanting to inject new procedures into an existing proc, called `update_atoms()` for example, you would create `update_atoms_ch()` in a nearby `_ch.dm` file, and then call to it from a single line in the original `update_atoms()` with `attempt_ch()`.
The syntax for `attempt_vr()` is: `attempt_vr(atom,"proc_name",list(arg1,arg2))`, where:
* `atom` should be replaced with what your extended proc is defined on (if you are in something like /obj/machine/scanner/proc/update_things() and you are calling your newly defined /obj/machine/scanner/proc/update_things_vr() you can just put `src` here)
* `proc_name` is a STRING that should be the name of your proc, such as "update_atoms_vr"
The syntax for `attempt_ch()` is: `attempt_ch(atom,"proc_name",list(arg1,arg2))`, where:
* `atom` should be replaced with what your extended proc is defined on (if you are in something like /obj/machine/scanner/proc/update_things() and you are calling your newly defined /obj/machine/scanner/proc/update_things_ch() you can just put `src` here)
* `proc_name` is a STRING that should be the name of your proc, such as "update_atoms_ch"
* `list(arg1,arg2)` should contain any args you wish to pass to the proc
As an example of something you can do with `attempt_vr()` in a single line, the grab and vore code is done with this in a single line. When a grab is clicked on someone, there is a line similar to:
`if(attempt_vr(src,"handle_grabs_vr",list(src,attacker))) return`
As an example of something you can do with `attempt_ch()` in a single line, the grab and vore code is done with this in a single line. When a grab is clicked on someone, there is a line similar to:
`if(attempt_ch(src,"handle_grabs_ch",list(src,attacker))) return`
Then in our `handle_grabs_vr()` proc, if we want to avoid performing the stock game actions and have handled the vore stuff ourselves, we return true, and the original proc returns since attempt_vr returns true.
Then in our `handle_grabs_ch()` proc, if we want to avoid performing the stock game actions and have handled the vore stuff ourselves, we return true, and the original proc returns since attempt_ch returns true.
### Pull Requests
@@ -72,7 +72,7 @@ Then in our `handle_grabs_vr()` proc, if we want to avoid performing the stock g
* Use the GitHub magic words "Fixed/Fixes/Fix, Resolved/Resolves/Resolve, Closed/Closes/Close", as in, "Closes #1928", as this will automatically close that issue when the PR is merged if it is a fix for that issue.
## Licensing
Yawn-Wider is licensed under the GNU Affero General Public License version 3, which can be found in full in LICENSE-AGPL3.txt.
CHOMPStation is licensed under the GNU Affero General Public License version 3, which can be found in full in LICENSE-AGPL3.txt.
Commits with a git authorship date prior to `1420675200 +0000` (2015/01/08 00:00) are licensed under the GNU General Public License version 3, which can be found in full in LICENSE-GPL3.txt.