-
Notifications
You must be signed in to change notification settings - Fork 429
Home
Welcome to the VOREStation code wiki! There's a lot that needs to be added here, but for now, this page will just explain what the labels mean on different issues. Eventually this will be moved to another page.
If you are seeking information on how to start your own SS13 server, create a server with the intent of testing, or any other of the various reasons you would need a private server environment then this guide will walk you step by step through the process:
How to make your own private/test server!
The guide has been tested and is still accurate as of 23-8-2022. In the event of an error, starting from step one and repeating the process will generally fix any issues ran in during testing.
All labels are defined below:
All issues and pull requests must be labeled with a type tag. The types are defined as follows:
- An existing functionality is not behaving as desired. If the bug is known to affect Polaris code too, ensure you report it there as well, and leave a link to the Polaris Github issue in the issue posted here.
- Either an existing functionality is behaving as desired but is being changed, or a new functionality is being added. If this is a change to the map, use the "Map" tag instead.
- The issue regards a specific player, such as custom items, or a changes to an existing whitelist.
- The issue regards a change to a .dmi file.
- The issue regards a change to the map. If the change is to correct an error, use the "Bug" label instead.
- Functionality in-game is not changed, but the code is being reorganized to be more easily read, optimized, modularized, etc.
- Desired changes do not affect the code at all, such as changes to the README.md file, or licensing information.
- The issue is directly relevant to vore.
All issues are to be given a severity rating. Some pull requests are given severity, but this is not required. Note that severity does not always correlate to how urgent a change needs to be done. A minor bug fix might be done before a moderate feature suggestion, for example, as bug fixes generally take priority. Severity defined as the impact that the bug or change has on the game. These levels of severity are defined as follows from most to least substantial:
- (As a bug) The entire game cannot be started or cannot run to the end of a round because of this bug.
Example: The server crashes after 10 minutes of gameplay. - (As a feature) The feature must be added as a requirement for why players come to play on the server.
Example: Adding the ability to eat people.
- (As a bug) A certain job or feature becomes unusable when the bug occurs.
Example: Stun batons do not stun people. - (As a feature) An existing functionality is being reworked to behave distinctly differently than before.
Example: Replacing cloning with re-sleeving.
- (As a bug) A certain job or feature becomes temporarily unusable, or disrupts the feature from working as desired.
Example: Guns unload from the bottom of the magazine instead of the top. - (As a feature) An existing functionality is improved or changed to better perform its original purpose.
Example: Making it so guns can be held in two hands for better accuracy.
- (As a feature or bug) The issue is purely cosmetic, or the issue has no impact on any feature, or the issue describes a bug that requires such extensive and elaborate steps to reproduce that no sane person would stumble on it by accident. This also includes bugs that don't appear without admin abuse.
Example: Alien blood is red instead of green.
Some issues and pull requests must have certain tasks finished before they can be completed. These tasks are defined as follows:
- The issue is explained poorly, and will be closed if it is not explained better soon.
- As an issue, the code must be tested to confirm a bug's existence, or how to reproduce it.
- As a pull request, the code being showcased in the pull request must be tested to ensure it functions as desired before being merged.
- Admin and community input is required on Github before the issue or pull request can be finalized.
Issues and pull requests may be assigned certain status tags. These statuses are defined as follows:
- Awaiting approval by admins.
- Only appears in pull requests. The code cannot be merged due to conflicts or game-breaking bugs. If the problems are not resolved, pull requests with this tag should be closed after at least a week of inactivity.
- Only appears in bug issues. The bug cannot be seen following the currently given steps to reproduce. Issues with this tag should be closed.
- Only appears in pull requests. Do not merge the code until the tag is removed by the same person who added it, or by an overriding developer.
- The issue or pull request was already handled previously. When assigning this tag, link in the comments to the prior issue/pull request and close the newer one. In the case of bugs, if the old issue has been closed, re-open it and remove the "Resolved" or "Works In Latest Build" tag.
- Only appears in bug issues. The aformentioned bug was fixed, but the fix is temporary, and should be replaced with a better solution as soon as possible.
- Only appears in issues. The aformentioned issue either talks about a bug that has already been solved, or a feature that already exists.
- Only appears in issues. The aformentioned issue is satisfied by an upcoming pull request or commit. When the changes are merged, the resolved issue should be closed. (To do this automatically, include "Fixes" or "Resolves" followed by the issue # in the description of the PR/commit.)
- Only appears in pull requests. The code shown in the pull request has been tested to ensure quality.
- Only appears on features. The changes suggested by the aforementioned issue or PR will not be merged due to the feature being undesired.
- Only appears on bugs. The aforementioned bug, while acknowledged as a bug, will not be fixed due to the bug not being worth fixing, or not possible to fix.
- Only appears in issues. Similar to the Resolved tag, the aformentioned issue is satisfied by a prior pull request or commit, but the point at which the issue was satisfied is unknown, except that it is currently satisfied.