Skip to content

Commit

Permalink
Merge branch 'master' of https://github.com/567Turtle/cmss13
Browse files Browse the repository at this point in the history
  • Loading branch information
567Turtle committed Sep 18, 2023
2 parents 6c983f3 + ed2dd26 commit 868a9bb
Show file tree
Hide file tree
Showing 3,911 changed files with 523,165 additions and 315,883 deletions.
The diff you're trying to view is too large. We only load the first 3000 changed files.
52 changes: 40 additions & 12 deletions .gitattributes
Original file line number Diff line number Diff line change
@@ -1,18 +1,46 @@
# dmm map merger hook
# needs additional setup, see tools/mapmerge/install.txt
*.dmm merge=merge-dmm
* text=auto

# dmi icon merger hook
# needs additional setup, see tools/dmitool/merging.txt
*.dmi merge=merge-dmi

# force changelog merging to use union
html/changelog.html merge=union

# Declare files that will always have LF line endings on checkout.
## Enforce text mode and LF line breaks
*.bat text eol=lf
*.cjs text eol=lf
*.css text eol=lf
*.dm text eol=lf
*.dmm text eol=lf
*.dme text eol=lf
*.dmf text eol=lf
*.htm text eol=lf
*.html text eol=lf
*.js text eol=lf
*.json text eol=lf
*.jsx text eol=lf
*.md text eol=lf
*.ps1 text eol=lf
*.py text eol=lf
*.scss text eol=lf
*.sql text eol=lf
*.svg text eol=lf
*.ts text eol=lf
*.tsx text eol=lf
*.txt text eol=lf
*.yaml text eol=lf
*.yml text eol=lf
*.sh text eol=lf
Dockerfile eol=lf

## Enforce binary mode
*.bmp binary
*.dll binary
*.dmb binary
*.exe binary
*.gif binary
*.jpg binary
*.png binary
*.so binary

## Merger hooks, run tools/hooks/install.bat or install.sh to set up
*.dmm text eol=lf merge=dmm
*.dmi binary merge=dmi

## Force tab indents on dm files
*.dm whitespace=indent-with-non-tab


9 changes: 3 additions & 6 deletions .github/CODEOWNERS
Validating CODEOWNERS rules …
Original file line number Diff line number Diff line change
Expand Up @@ -24,12 +24,9 @@
/tools/docker/ @Fira
/Dockerfile @Fira

# Stan_Albatross
# MorrowWolf

/code/modules/projectiles/guns/lever_action.dm @stanalbatross
/code/game/objects/items/backpack_sprayers.dm @stanalbatross
/code/game/objects/items/tools/experimental_tools.dm @stanalbatross
/maps/map_files/LV522_Chances_Claim/LV522_Chances_Claim.dmm @morrowwolf
/code/modules/gear_presets/survivors.dm @morrowwolf

# MULTIPLE OWNERS
/icons/ @Agameofscones @Monkeysfist101 @nauticall
/maps/ @Agameofscones @nauticall @Nanu308
114 changes: 96 additions & 18 deletions .github/CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,8 +5,9 @@
- [Introduction](#introduction)
- [Getting Started](#getting-started)
- [Meet the Team](#meet-the-team)
- [Head Developer and Project Manager](#head-developer-and-project-manager)
- [Head Maintainer and Maintainer Managers](#head-maintainer-and-maintainer-managers)
- [Maintainers](#maintainers)
- [Staff Tools and Major Rule changing PR’s](#staff-tools-and-major-rule-changing-prs)
- [Issue Managers](#issue-managers)
- [Issues Tracker](#issues-tracker)
- [Development Guides](#development-guides)
Expand All @@ -15,8 +16,17 @@
- [Writing understandable code](#writing-understandable-code)
- [Misc](#misc)
- [Pull Request Process](#pull-request-process)
- [A note on balance impacting PRs](#a-note-on-balance-impacting-prs)
- [Good Boy Points](#good-boy-points)
- [Porting features/sprites/sounds/tools from other codebases](#porting-featuresspritessoundstools-from-other-codebases)
- [Things you can work on](#things-you-can-work-on)
- [Spriting](#spriting)
- [Mapping](#mapping)
- [Coding](#coding)
- [What we don't want](#what-we-dont-want)
- [Spriting](#spriting-1)
- [Mapping](#mapping-1)
- [Coding](#coding-1)
- [Banned content](#banned-content)

## Reporting Issues
Expand All @@ -43,9 +53,9 @@ You can of course, as always, ask for help on the Discord channels or the forums

## Meet the Team

### Head Developer and Project Manager
### Head Maintainer and Maintainer Managers

The Head Developer and Project Manager are responsible for controlling, adding, and removing maintainers from the project. In addition to filling the role of a normal maintainer, they have sole authority on who becomes a maintainer, as well as who remains a maintainer and who does not.
The Head Maintainer and Maintainer Managers are responsible for controlling, adding, and removing maintainers from the project. In addition to filling the role of a normal maintainer, they have sole authority on who becomes a maintainer, as well as who remains a maintainer and who does not.

### Maintainers

Expand All @@ -64,13 +74,21 @@ These are the few directives we have for project maintainers.
- Try to get secondary maintainer approval before merging if you are able to.
- PRs with empty commits intended to generate a changelog.
- Do not merge PRs that contain content from the [banned content list](./CONTRIBUTING.md#banned-content).
- Do not merge PRs that contain balance changes without Maintainer Manager approval. Exceptions include:
- Any PR that has been un-reviewed by a Maintainer Manager for 7 days.
- Do not remove the DNM label that another Maintainer has applied. Exceptions include:
- Maintainer Managers removing a DNM label placed by a Maintainer for Balance/Design reasons

These are not steadfast rules as maintainers are expected to use their best judgement when operating.

Our team is entirely voluntary, as such we extend our thanks to maintainers, issue managers, and contributors alike for helping keep the project alive.

</details>

### Staff Tools and Major Rule changing PR’s

PR’s that affect staff tools/major rules rewrite (adding/removing/editing etc.) requires certain Head Staff oversight and can be blocked from being merged. The Head Maintainer must be informed about why so a discussion can be had. The Host makes a final decision if the PR is to be merged after changes have been implemented stemming from the discussion.

### Issue Managers

Issue Managers help out the project by labelling bug reports and PRs and closing bug reports which are duplicates or are no longer applicable.
Expand All @@ -81,12 +99,12 @@ Issue Managers help out the project by labelling bug reports and PRs and closing
This should help you understand what you can and can't do with your newfound github permissions.

Things you **CAN** do:
* Label issues appropriately
* Close issues when appropriate
- Label issues appropriately
- Close issues when appropriate

Things you **CAN'T** do:
* Close PRs: Only maintainers are allowed to close PRs. Do not hit that button.
* Label PRs, leave that for maintainers to handle.
- Close PRs: Only maintainers are allowed to close PRs. Do not hit that button.
- Label PRs, leave that for maintainers to handle.

</details>

Expand Down Expand Up @@ -139,29 +157,89 @@ There is no strict process when it comes to merging pull requests. Pull requests

* While we have no issue helping contributors (and especially new contributors) bring reasonably sized contributions up to standards via the pull request review process, larger contributions are expected to pass a higher bar of completeness and code quality *before* you open a pull request. Maintainers may close such pull requests that are deemed to be substantially flawed. You should take some time to discuss with maintainers or other contributors on how to improve the changes.

* After leaving reviews on an open pull request, maintainers may convert it to a draft. Once you have addressed all their comments to the best of your ability, feel free to mark the pull as `Ready for Review` again.

## Good Boy Points

Each GitHub account has a score known as Good Boy Points, or GBP. This is a system we use to ensure that the codebase stays maintained and that contributors fix bugs as well as add features.

The GBP gain or loss for a PR depends on the type of changes the PR makes, represented by the tags assigned to the PR by the CM-SS13 github bot or maintainers. Generally speaking, fixing bugs, updating sprites, or improving maps increases your GBP score, while adding mechanics, or rebalancing things will cost you GBP.
* After leaving reviews on an open pull request, maintainers should convert it to a draft. Once you have addressed all their comments to the best of your ability, feel free to mark the pull as `Ready for Review` again.

The GBP change of a PR is the sum of greatest positive and lowest negative values it has. For example, a PR that has tags worth +10, +4, -1, -7, will net 3 GBP (10 - 7).
### A note on balance impacting PRs

Negative GBP increases the likelihood of a maintainer closing your PR. With that chance being higher the lower your GBP is. Be sure to use the proper tags in the changelog to prevent unnecessary GBP loss. Maintainers reserve the right to change tags as they deem appropriate.
Certain PRs, such as those which directly change number values (i.e. health, recoil, damage) or add large pieces of content to the game (i.e. a new gun, a new dropship weapon, or a new xeno structure) can have the potential to highly impact game balance or gameflow.

There is no benefit to having a higher positive GBP score, since GBP only comes into consideration when it is negative.
* If a Maintainer Manager or Head Maintainer has not reviewed a pull request that impacts balance in 7 days, maintainers may review and merge the PR themselves.

You can see each tag and their GBP values [Here](https://github.com/cmss13-devs/cmss13/blob/master/.github/gbp.toml).
* We understand that having something you have worked on for quite some time being denied can be frustrating. Therefore, it is recommended that you check with a maintainer before beginning to code your PR if you have any doubts that it will be accepted. This will save everyone's time and energy.

## Porting features/sprites/sounds/tools from other codebases

If you are porting features/tools from other codebases, you must give them credit where it's due. Typically, crediting them in your pull request and the changelog is the recommended way of doing it. Take note of what license they use though, porting stuff from AGPLv3 and GPLv3 codebases are allowed.

Regarding sprites & sounds, you must credit the artist and possibly the codebase.

## Things you can work on
The following list is non-exhaustive, but should give you a good idea of what the dev team would like to see in Pull Requests.

### Spriting

- Replacements of legacy Bay12 sprites
- Strain specific designs for Aliens for ones that lack them
- Alternative Alien sprite sets
- Icon sheet sorting styled after firearms sheets
- New cosmetic loadout items, such as additional helmet garb
- Custom tilesets for maps that don’t have them
- Map specific props and details
- Map specific Colonist uniforms and equipment
- Additional HUD styles
- Bug fixes and inconsistency fixes


### Mapping
- Nightmare inserts
- Object placement quality of life improvements (such as widening hallways and combat lanes cluttered with props)
- Extra map detailing (so long as it doesn’t negatively impact performance)
- Removal of dead-ends or gameplay dead-space on existing maps
- New maps*
- Bug fixes and inconsistency fixes

**A note on new maps.**
Entirely new maps are generally considered to be stepping stones into the Development team’s mapping dept. proper. However, making a new map is a months long process that requires dedication and constant communication and oversight from mappers on the Maintainer team. Mapping, like spriting and coding is an acquired skill, and it is highly likely your first map is going to suck. Maps are fluid entities that are never absolutely complete, don’t wed yourself to your initial layout, always be prepared to remap half the project when going in.


### Coding
- Quality of life improvements that don’t impact gameplay, but improve it
- Latency optimizations and improvements
- Backend system refactors that improve server stability or performance
- Minor features that don’t impact the overall round loop
- Content for jobs currently lacking in it
- Anything on the public task-board
- New Alien strains
- Bay12 legacy feature removal (such as wizard backend, laser eyes, etc)
- Map specific survivor loadouts
- Bug fixes and inconsistency fixes
- New TGUI

## What we don't want
The following list is non-exhaustive, but should give you a good idea of what the dev team don't want to see in Pull Requests.

### Spriting
- Resprites of recently updated content, such as uniforms, guns, marine armor
- Donor item adjustments or changes
- Joke sprites
- Tacticool equipment and gear. We’re retro-future (or cassette punk if you will).

### Mapping
- Nightmare inserts with ridiculous loot or ones that are out of place (don’t put snow on LV, for example)
- Additional detailing that degrades arena space or hinders gameplay in any sort of way
- Event or unused maps

### Coding
- No additional species or races, even Arcturians
- No new whitelists
- NanoUI
- Player-facing HTML UIs
- Prior denied content/PRs (without approval)

Remember that the following lists are not exhaustive. And you can freely contribute an PR with content that can be shuffled into the “What we don’t want” category, and still get it merged. It is just unlikely without prior talk/approval from a maintainer.

## Banned content
Do not add any of the following in a Pull Request or risk getting the PR closed:
* Any content that adds a specific character played by or reference to a single player, contributor, staff member, or maintainer.
For example, a PR that adds a blue crab named after a staff member’s username is not permitted, as it directly references a specific individual.
* Code which violates GitHub's [terms of service](https://github.com/site/terms).
27 changes: 0 additions & 27 deletions .github/ISSUE_TEMPLATE/bug_report.md

This file was deleted.

48 changes: 48 additions & 0 deletions .github/ISSUE_TEMPLATE/bug_report.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
name: Bug Report
description: File a bug report
labels: ["Bug"]
body:
- type: input
id: current-tms
attributes:
label: Testmerges
description: Are there any current TMs on the server? You can see this from the message when you join, or via using the OOC -> Show Revision Info verb. If you're certain the issue is to be caused by a test merge, report it in the pull request's comment section rather than on the tracker.
placeholder: "#1, #2, #3, etc"
validations:
required: true
- type: textarea
id: what-happened
attributes:
label: Description of the bug
description: What went wrong? Give us a 1-2 sentence summary.
placeholder: Maintainers hate this one simple trick...
validations:
required: true
- type: textarea
id: what-should-have-happened
attributes:
label: What's the difference with what should have happened?
description: What's the expected behaviour?
placeholder: Not this. Never this...
validations:
required: true
- type: textarea
id: reproduction
attributes:
label: How do we reproduce this bug?
description: Using as much detail as necessary, give us the steps to reproducing this error.
value: |
1.
2.
3.
...
validations:
required: true
- type: checkboxes
id: issue-bingo
attributes:
label: Issue Bingo
options:
- label: Issue could be reproduced at least once
- label: Issue happened in a recent (less than 7 days ago) round
- label: Couldn't find an existing issue about this (https://github.com/cmss13-devs/cmss13/issues)
5 changes: 5 additions & 0 deletions .github/ISSUE_TEMPLATE/config.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
blank_issues_enabled: false
contact_links:
- name: Game Breaking Exploits
url: https://discord.gg/cmss13
about: Securely disclose high priority issues to a member of the Maintainer Team here.
11 changes: 0 additions & 11 deletions .github/ISSUE_TEMPLATE/feature_request.md

This file was deleted.

Loading

0 comments on commit 868a9bb

Please sign in to comment.