content can deny connection if desired 30 | S->>C: MsgLoginSuccess 31 | Note over C,S: Both sides enable encryption if necessary 32 | Note over C,S: Both sides create NetChannel 33 | end 34 | S->>C: MsgStringTableEntries 35 | rect 36 | Note over C,S: Serializer handshake 37 | S->>C: MsgMapStrServerHandshake 38 | C->>S: MsgMapStrClientHandshake 39 | opt Client needs strings 40 | S->>C: MsgMapStrStrings 41 | C->>S: MsgMapStrClientHandshake 42 | end 43 | end 44 | Note over S,C: NetManager.Connected event
Non-handshake messages are now allowed 45 | C-->>S: MsgConVars 46 | C-->>S: MsgConCmdReg 47 | par PlayerManager.NewSession 48 | Note over S: Server-side player session gets created,
PlayerStatusChanged gets ran for first time 49 | S->>C: MsgSyncTimeBase 50 | Note over S: NetConfigurationManager.SyncConnectingClient 51 | S->>C: MsgConVars 52 | Note over C: Client-side player session gets created 53 | C->>S: MsgPlayerListReq 54 | and UploadedContentManager 55 | loop Send uploaded resources 56 | S->>C: NetworkResourceUploadMessage 57 | end 58 | loop Send uploaded prototypes 59 | S->>C: GamePrototypeLoadMessage 60 | end 61 | end 62 | Note over S: Player session is set to Connected 63 | S->>C: MsgPlayerList
Contains Connected Status 64 | Note over C: Player session is set to Connected 65 | Note over S: Content sets client session to InGame 66 | S->>C: Starts sending game states 67 | Note over C: Player session is set to InGame 68 | ``` 69 | -------------------------------------------------------------------------------- /src/en/community/admin/admin-tooling/scripting.md: -------------------------------------------------------------------------------- 1 | # Scripting Tutorial 2 | 3 | Ever see those admins who spectate then immediately shorten or grow, get colored, and starts flying around real fast, all at the same time? We’re learning how to script, baby. 4 | 5 | A script is a series of commands that you tell the game to run. You can add as many commands as you want. There are multiple use cases for scripts, and are amazing for automating tasks that don’t require editing in-between uses. 6 | 7 | To get started, type %appdata% in your search bar and scroll down to find Space Station 14. In case you’re already lost, the directory’s location is \AppData\Roaming\Space Station 14\data. If you’re not on windows, you’ll have to find that folder yourself. Anyways, open the data folder, and create a text file (.txt). Literally any name works, but you’ll be typing that name in the console, so make sure you can recognize it. You can make as many scripts as you want. Put your script in that file. Once you have every command you want in your script, run exec with the /filename to run your script. exec has autocomplete. 8 | 9 | ## Examples 10 | ### Basic aGhost Script 11 | This script relies on toolshed to fill in the entity’s ID by running “self” first. Here’s nikthechampiongr’s “generic username agnostic script”: 12 | 13 | > self not prototyped AdminObserver do "aghost" 14 | > self do "vvwrite entity/$ID/MovementSpeedModifier/BaseSprintSpeed 25" 15 | > self do "vvwrite entity/$ID/MovementSpeedModifier/BaseWalkSpeed 6" 16 | > self do "vvwrite entity/$ID/Description \"GHOST GANG!\"" 17 | > self do "vvwrite entity/$ID/Eye/VisibilityMask 7" 18 | > self do "vvwrite entity/$ID/Ghost/color '#4D7AFF'" 19 | > self do "addcomp $ID ShowCriminalRecordIcons" 20 | > self do "addcomp $ID ShowJobIcons" 21 | > self do "addcomp $ID ShowMindShieldIcons" 22 | > self do "addcomp $ID ShowSyndicateIcons" 23 | 24 | ### Entity Itemization 25 | Here is a script by aquif that itemizes a marked entity (which you need to mark by right-clicking an entity > admin > mark): 26 | 27 | > marked comp:ensure Item 28 | > marked comp:ensure MultiHandedItem 29 | > marked comp:ensure CanEscapeInventory 30 | 31 | For this script, you should be adding an entity size. This command changes based on what kind of inventory your server has: 32 | 33 | Size for list inventory servers: > marked do "vvwrite /entity/$ID/Item/Size 120" 34 | Size for grid inventory servers: > marked do "vvwrite /entity/$ID/Item/Size Normal" for a 2x2 tiled item, or use Ginormous to be too big for bags. Inspect the item component of other items for more sizes. 35 | 36 | ### Make All Ghosts Rainbow 37 | 38 | This is a singular command, however making it into a script has us write a lot less words than writing the whole command (ex: exec /RGBALL.txt) 39 | 40 | > entities with Ghost comp:ensure RgbLightController comp:ensure PointLight do "vvwrite /entity/$ID/PointLight/Energy 0" -------------------------------------------------------------------------------- /src/en/space-station-14/art/displacement-maps.md: -------------------------------------------------------------------------------- 1 | # Displacement Maps 2 | 3 | People asked me for a quicky about how displacement maps work so uhhh... 4 | 5 | Ok so in [PR #26709](https://github.com/space-wizards/space-station-14/pull/26709) I added displacement maps. Yippee. This allows you to deform a sprite based on another, specially-crafted sprite. How do we make these specially crafted sprites? 6 | 7 | ## Displacement map format 8 | 9 | Displacement maps should work the same as [BYOND's](http://www.byond.com/docs/ref/index.html#/{notes}/filters/displace). I did not at all test BYOND's so there's a nonzero chance I misread their docs and they're like interpreted inversely or something. Whatever. 10 | 11 | The basic idea is that each pixel of the displacement map specifies how much to "shift" the pixels at a position. It should be noted that, due to how GPUs work, this may not work as you may anticipate. Instead of specifying "Pixel X displaces to position Y", it actually specifies "Pixel X reads from position Y". i.e. if you specify a displacement of +1 pixel horizontally, the sprite will visually shift to the **left**, because they get their color from the texture pixel +1 to the right. 12 | 13 | The red channel controls horizontal deviation, the green channels controls vertical deviation. A red and green value of 128 is "neutral", i.e. no difference. Greater red or green values cause displacements to be sampled to the bottom right, effectively meaning the sprite moves to the "top left". 14 | 15 | The actual displacement value can be changed with a "size" parameter on the shader. Basically this size parameter is "how many pixels are shifted at the maximal pixel value". With a "size" of 4, a value of 255 would shift by 4 pixels. With a size of 127, each value on the channel is a one pixel shift (129 -> +1, 130 -> +2). 16 | 17 | Oh yeah btw I decided to make it so that the alpha channel of the image is a simple mask. That means you can set alpha to 0 to completely cut out a pixel. 18 | 19 | The blue channel is ignored, I personally used it to mark off "modified" pixels to make it easier to see what a displacement map is doing in an image editor. 20 | 21 | ## Actual shader 22 | 23 | The actual displacement map shader in SS14 is located at `/Textures/Shaders/displacement.swsl`. It has three parameters: `displacementSize` is the size described above, and `displacementMap` and `displacementUV` are intended to be filled out with the `CopyToShaderParameters` system of a sprite component. See the PR I linked above as example. 24 | 25 | ## Displacement RSI load parameters 26 | 27 | Remember to set the following in your RSI's `meta.json` because otherwise sRGB will eat your face and none of the math will make sense: 28 | 29 | ```json 30 | "load": { 31 | "srgb": false 32 | } 33 | ``` 34 | 35 | ## Aseprite scripts 36 | 37 | I wrote some Aseprite scripts to help with authoring displacement maps. You can find them in the `Tools/` folder of SS14's repo. 38 | -------------------------------------------------------------------------------- /src/index.md: -------------------------------------------------------------------------------- 1 |
2 |
3 | ```admonish warning "Players beware"
4 | This is the developer's wiki. If you are a player, you are looking for [the player wiki](https://wiki.spacestation14.io/wiki/Main_Page).
5 | ```
6 |
7 | ```admonish question "Technical Issues"
8 | If you are having difficulties with logging into the game or building it, please try the following resources:
9 | [🔊 Discord](https://discord.gg/ss14). This is the most active community of developers for Space Station 14. Ask a question on the General or Help channel.
10 | [📲 FAQ](https://spacestation14.io/about/faq/)
11 | [🎮 Forums](https://forum.spacestation14.io/)
12 | ```
13 |
14 | This wiki is written in [Markdown](https://docs.requarks.io/en/editors/markdown) using `mdbook`. You can view our README.md for the docs site [here](https://github.com/space-wizards/docs/blob/master/README.md), which has useful information.
15 |
16 | ```admonish info "Making contributions"
17 | If you would like to make contributions to this documentation site, it's hosted fully open source on GitHub and you can make a webedit PR to any page using the button in the top right. Check out our [Guide to Editing Docs](en/meta/guide-to-editing-docs.md) page for more information.
18 | ```
19 |
20 | ## Getting Started
21 |
22 | - [:question: How do I code?](en/general-development/setup/howdoicode.md)
23 | - [:package: Setting up the Dev Environment](en/general-development/setup/setting-up-a-development-environment.md)
24 | - [:page_with_curl: Core Game Design](en/space-station-14/core-design.md)
25 | - [:world_map: Mapping](en/space-station-14/mapping.md)
26 | - [:chart_with_upwards_trend: Git for the SS14 Developer](en/general-development/setup/git-for-the-ss14-developer.md)
27 |
28 |
29 | ### What should I work on?
30 |
31 | * Talk to current developers in Discord.
32 | * Check [the list of issues](https://github.com/space-wizards/space-station-14/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc) for anything you can work on.
33 | * Reading through [Acronyms & Common Nomenclature](en/general-development/codebase-info/acronyms-and-nomenclature.md) as well as the other articles on this wiki in `Tips` or `Setup` will likely help you understand what is happening.
34 |
35 | ### What repositories are part of Space Station 14?
36 | * [Space Station 14](https://github.com/space-wizards/space-station-14) is the main codebase. It has the most priority issues. [Space Station 14 Issues](https://github.com/space-wizards/space-station-14/issues)
37 | * [Robust Toolbox](https://github.com/space-wizards/RobustToolbox) is the custom game engine. [Robust Toolbox Issues](https://github.com/space-wizards/RobustToolbox/issues)
38 |
39 | There are other repositories that do not have as many priority issues to work on. If you are still curious about them, they are here:
40 | - [Space-Wizards](https://github.com/space-wizards)
41 |
42 |
--------------------------------------------------------------------------------
/src/en/space-station-14/core-design.md:
--------------------------------------------------------------------------------
1 | # Core Game Design
2 | These documents contains the Spacestation 14's Core Game Design Princples and should be used to inform the design of any new designs or large balance changes.
3 |
4 | Questions around Core Game Design should be directed towards the Design Group on the Official Spacestation 14 Discord (Prefered) or if you do not use Discord by making a thread on the Spacestation 14 Forums.
5 |
6 | ### Caveats
7 | - These documents are living documents and will change overtime as the design of Spacestation 14 evolves.
8 | - These documents are one interpretation of what Spacestation 14 should be and only reflects the direction of Wizden (upstream) LRP and MRP servers.
9 | - Forks and other communities may have different ideas and directions which they want to take the game, which is fine and something we want to encourage!
10 | - This is primarily intended to serve as a direction for upstream Spacestation 14 development, but forks can use these design documents as a base if they so choose.
11 |
12 |
13 | # What is Spacestation 14?
14 | Spacestation 14 is a game where disasters, enemies, and incompetence conspire to make each shift aboard the station a unique and hellish experience.
15 |
16 | # Core Pillars
17 | These pillars serve as the guiding concepts for designing features for SS14. When creating features or changing balance you should be actively thinking about how these concepts relate to your design or change.
18 | The pillars serve as guideposts for creating a cohesive design for SS14. Further detail about each can be found in: [Design Principles](core-design/design-principles.md).
19 |
20 | ## Chaotic
21 | - No two rounds should play alike. The combination of antagonists, incompetence, and disasters should create situations where players have to deal with rapidly changing and escalating situations.
22 | ## Seriously Silly
23 | - aka "The clown has put space lube all over the halls, armed the station nuke and is throwing cream-pies filled with acid at security officers", a situation like this on its face is completely ludicrous but should be taken seriously by players.
24 | ## Dynamic Environment
25 | - The gameworld should be malleable, letting players build, deconstruct, or modify anything. It should be *possible* to build an entire separate station and continue the round there if players put in the effort.
26 | ## Intuitive and Inter-Connected Simulation
27 | - Simulated systems should be complex enough to create engaging gameplay/decisions while still being intuitive enough to learn without wiki-diving. Systems should interact with each other as much as feasible to create new emergent gameplay opportunities.
28 | ## Player Interaction/Agency
29 | - Players should be encouraged to interact with each other as much as possible to create opportunities for conflict or cooperation. Mechanics should reinforce the player's ability to make impactful decisions while mitigating those decisions' effects on the agency of other players.
--------------------------------------------------------------------------------
/src/en/space-station-14/core-tech/chemistry/solution-containers.md:
--------------------------------------------------------------------------------
1 | # Solution Containers
2 |
3 | To make an entity a solution container, give add a `SolutionContainerManager`. For example here is an empty stomach solution:
4 | ```yaml
5 | - type: SolutionContainerManager
6 | solutions:
7 | stomach:
8 | maxVol: 200
9 | ```
10 |
11 | and a full drink solution:
12 |
13 | ```yaml
14 | - type: SolutionContainerManager
15 | solutions:
16 | drink:
17 | maxVol: 20
18 | reagents:
19 | - ReagentId: Cola
20 | Quantity: 20
21 | ```
22 |
23 | `type`: The component type. Should always be `SolutionContainerManager`.
24 | `solutions`: A map of solution name and the `Solution` described below.
25 |
26 | Solutions have several fields, all of them optional.
27 | `maxVol`: The maximum volume of solution it can hold. Once reagent Quantity sum reaches `maxVol`, no more reagents can be added. It's full.
28 | `reagents`: List of `Reagent`s it should hold by default. Each `Reagent` has a string `ReagentId` and `Quantity` which is a FixedPoint2 (basically a float limited to two decimal places).
29 |
30 | ## Capabilities and specifying target solution
31 |
32 | With introduction of `SolutionContainerManager` there is no longer a simple 1:1 mapping of entity and list of reagents.
33 | Each `SolutionContainerManager` can contain any number of solutions. To solve this problem instead of Capabilities flag, a set of Capability-like components are introduced. Each such capability has a a string `solution` that tells `SolutionContainerManager` which solution it targets.
34 |
35 | Here is a list of them:
36 | - `DrainableSolutionComponent` for solutions that can be easily removed through any reagent container. E.g. draining water from a water tank
37 | - `DrawableSolutionComponent` for solutions that can be drawn with syringes. E.g. humans or syringe bottles with rubber caps.
38 | - `ExaminableSolutionComponent` for solutions that can be examined by hand.
39 | - `FitsInDispenserComponent` notes that the component fits in dispenser and tells ReagentDispenser/ChemMaster which solution to target.
40 | - `InjectableSolutionComponent` for solutions that can be injected into with syringes.
41 | - `RefillableSolutionComponent` for solutions that can be added easily.
42 |
43 | Other components like `DrinkComponent` or `FoodComponent` may have special predefined solutions they target and expect to see. For example a `DrinkComponent` will try to create `drink` solution if there isn't an easily accessed `DrainableSolutionComponent` already available.
44 |
45 | ## Example of Solution
46 | Here is a full example of an entity with some Solutions:
47 |
48 | ```yaml
49 | - type: entity
50 | id: DrinkColaCan
51 | name: space cola
52 | description: A refreshing beverage.
53 | components:
54 | - type: Sprite
55 | sprite: Objects/Consumable/Drinks/cola.rsi
56 | - type: SolutionContainerManager
57 | solutions:
58 | drink:
59 | reagents:
60 | - ReagentId: Cola
61 | Quantity: 20
62 | maxVol: 20
63 | - type: Drink
64 | ```
--------------------------------------------------------------------------------
/src/en/space-station-14/departments/science.md:
--------------------------------------------------------------------------------
1 | ```admonish warning "Attention: Placeholder!"
2 | This section is a placeholder, pending a design-doc being created by the related work-group
3 | ```
4 |
5 | # Science
6 | THE SCIENCE TEAM
7 |
8 | ## Concept
9 | Science is responsible for researching and prototyping new technologies that unlock benefits for the whole station. They perform experimentation on various strange phenomenon to find new discoveries that improve the station.
10 | - **Primary Goal**: Unlocking and providing technology(not necessarily as items) needed to upgrade the station and improve quality of life for other departments.
11 | - **Secondary Goal**: Utilizing in-house experiments & technology (i.e artifacts, xenobiology) to create benefits or risks to the station.
12 |
13 | ## Player Story
14 | > A short (1-2 paragraph) story from the perspective of someone playing a role in this department. This is effectively a story of the ideal experience of a player interacting with these mechanics/systems.
15 |
16 | ## Design Pillars
17 | > A group of simple high-level ideas that embody this department. These are usually expressed with singluar words or short phrases, but may also include a *short* one sentence explaination. Game pillars are what makes the *identity* of the department.
18 |
19 | > Pillars are there to act as guides when creating new mechanics or interactions, they serve as the measuring posts to make sure that what you are trying to do will fit in the department gameplay.
20 |
21 | > To acheive this you want pillars that are concrete enough to get your concept across but broad enough that there is some room of interpretation and discussion.
22 |
23 | ### Pillar_1:
24 | > Breif Pillar Description
25 |
26 | ### Pillar_2:
27 | > Breif Pillar Description
28 |
29 | ## Objectives
30 | > What is this department's objective when it comes to the round? Do they have a unique failure condition? If so, what is it? How does this department's objectives interact with the rest of the station?
31 |
32 | ## Progression
33 | > How does the *gameplay* of this department change over the course of a round? Are there unlocks? Are players collecting/spending resources? Is this progression tied/related to other departments? If so how?
34 |
35 | ## Flow
36 | > How does the *experience* of the player change over the course of a round? Are players constantly running around putting out fires or are there breaks in the action? Do players need to wait on other departments as pre-requisites for their own gameplay, or is this department fairly self-sufficent?
37 |
38 | ## Mechanics
39 | > What major mechanics does this department use and how are they connected to this department.
40 |
41 | ### Mechanic_Placeholder1
42 | > Each mechanic should have its own subheading and should contain a *short high-level* overview of the mechanic and how it is used by this department. Each mechanic should also link their associated design document as the subheading.
43 |
44 | ### Mechanic_Placeholder2 (Not Implemented Yet)
45 | > Mechanics that are unimplemented should be marked with (Not Implmented Yet) and should link the associated design proposal if it exists.
46 |
--------------------------------------------------------------------------------
/src/en/space-station-14/mapping/dungeons.md:
--------------------------------------------------------------------------------
1 | # Dungeons
2 |
3 | Dungeons are procedurally generated structures constructed from templates.
4 |
5 | ## Quickstart
6 |
7 | To generate a dungeon:
8 | 1. Have a map, either space or planet (via the `planet` command) ready
9 | 2. Have a preset in mind, then run the dungeon command. This has autocompletion to help. `dungen 11 | ## Template 12 |
13 | 14 | # Document Name 15 | 16 | ## Concept 17 | > 1-2 paragraphs acting as an abstract, condensing the information of the document into an easily readable format and setting expectations for what the other sections will contain. It should provide a brief overview of the game area, but avoid to include any information that isn't mentioned elsewhere in the document. 18 | 19 | ## Intended Experience 20 | > A collection of simple high-level ideas that embody this game area. These are usually expressed with singluar words or short punchy phrases, but may also include a short one sentence explanation. The goal is to convey the *feeling* a player should have when playing/interacting with the game area, such that other documents and PRs can align with that intended experience. 21 | 22 | ## Responsibilities 23 | > A collection of points regarding what the game area is responsible for in terms of gameplay, mechanics and/or station duties. This section should highlight what unique things the game area brings to the game and simulatione. If the game area is a resource provider to the station, this is highlighted here. 24 | 25 | ## Desired Gameplay 26 | > A list of high-level concepts, explaining the *kind* of gameplay and mechanics we want to see in the game area's design. Each list entry should be a short sentence summarizing the design pillar with a more detailed (1-2 paragraph) description underneath. 27 | 28 | > While the "Intended Experience" section focuses on how it *feels*, this section's entries should focus on what the player *does*. They should still be high-level, in that you are not providing instructions on specific gameplay mechanics; they are there to act as guides when creating new mechanics or interactions, serving as the measuring posts to make sure that what you are trying to do will fit in the boundaries of the game area. 29 | 30 | ## Undesired Gameplay 31 | > Similar to "Desired Gamplay", but instead listing easy pitfalls and directions we *don't* want the game area to move in. This sets boundaries and helps achieve cohesion when designing new aspects of an area. 32 | -------------------------------------------------------------------------------- /src/en/space-station-14/departments/engineering.md: -------------------------------------------------------------------------------- 1 | ```admonish warning "Attention: Placeholder!" 2 | This section is a placeholder, pending a design-doc being created by the related work-group 3 | ``` 4 | 5 | # Engineering 6 | The powerhouse of the ~~cell~~ station 7 | 8 | ## Concept 9 | Engineering is responsible for building, running, maintaining, and repairing life-critical station hardware. No matter what the situation is, engineering keeps the power on and the atmosphere breathable. 10 | - **Primary Goal**: Keep the station habitable and respond to life-support emergencies 11 | - **Secondary Goal**: *Perform* upgrades[1] the station and process raw resources into usable items/equipment. 12 | 13 | [1] The difference between engineering and science when it comes to upgrades is that Engineering focuses on the implementation/installation while Science researches/creates the upgrades or their components. 14 | 15 | ## Player Story 16 | > A short (1-2 paragraph) story from the perspective of someone playing a role in this department. This is effectively a story of the ideal experience of a player interacting with these mechanics/systems. 17 | 18 | ## Design Pillars 19 | > A group of simple high-level ideas that embody this department. These are usually expressed with singluar words or short phrases, but may also include a *short* one sentence explaination. Game pillars are what makes the *identity* of the department. 20 | 21 | > Pillars are there to act as guides when creating new mechanics or interactions, they serve as the measuring posts to make sure that what you are trying to do will fit in the department gameplay. 22 | 23 | > To acheive this you want pillars that are concrete enough to get your concept across but broad enough that there is some room of interpretation and discussion. 24 | 25 | ### Pillar_1: 26 | > Breif Pillar Description 27 | 28 | ### Pillar_2: 29 | > Breif Pillar Description 30 | 31 | ## Objectives 32 | > What is this department's objective when it comes to the round? Do they have a unique failure condition? If so, what is it? How does this department's objectives interact with the rest of the station? 33 | 34 | ## Progression 35 | > How does the *gameplay* of this department change over the course of a round? Are there unlocks? Are players collecting/spending resources? Is this progression tied/related to other departments? If so how? 36 | 37 | ## Flow 38 | > How does the *experience* of the player change over the course of a round? Are players constantly running around putting out fires or are there breaks in the action? Do players need to wait on other departments as pre-requisites for their own gameplay, or is this department fairly self-sufficent? 39 | 40 | ## Mechanics 41 | > What major mechanics does this department use and how are they connected to this department. 42 | 43 | ### Mechanic_Placeholder1 44 | > Each mechanic should have its own subheading and should contain a *short high-level* overview of the mechanic and how it is used by this department. Each mechanic should also link their associated design document as the subheading. 45 | 46 | ### Mechanic_Placeholder2 (Not Implemented Yet) 47 | > Mechanics that are unimplemented should be marked with (Not Implmented Yet) and should link the associated design proposal if it exists. 48 | -------------------------------------------------------------------------------- /src/en/space-station-14/departments/medical/guidelines.md: -------------------------------------------------------------------------------- 1 | # PR Guidelines 2 | 3 | ## Making a Medical PR 4 | 5 | Medical related PRs include anything covered by the Medical Workgroup document. PRs which touch BodySystem and related components, the Medical Department's round flow, and Reagents are medical related PRs and must adhere to the PR guidelines listed here. 6 | 7 | Medical related PRs should, in their description or title, state whether this change is meant to be for the current upstream medical system or for debodying/disco-med (See [Medical Workgroup Document](medical-workgroup.md)). A PR without clear intention may be subject to closure if it does not follow the guidelines for either current upstream medical, or disco-med. 8 | 9 | For any additional questions please consult the medical workgroup through the SS14 discord server. 10 | 11 | ### PRs for Current Medical 12 | A PR for current medical should typically be for fixing up or rebalancing current behavior. These PRs must justify their existence, the current medical system is extremely flawed so a portion of the PR description should be explaining why this should be merged instead of waiting for better medical implementation. Microbalance PRs will be closed at workgroup discretion. Common justifications may include: bugfixes, exploits, highly unbalanced/meta behavior, or small additions which do not greatly alter key systems. 13 | 14 | In addition these PRs cannot and should never reverse debodying or hardcode body system behavior into another system. If a PR is unable to meet these guidelines and cannot be changed to meet these guidelines, it must be refactored to adhere to disco-med guidelines or be closed. 15 | 16 | ### PRs for Disco-Med/Debodying 17 | A PR designed for debodying/disco-med must adhere to the [Medical Design Document](../medical.md). Disco-Med and Debodying PRs are expected to be of higher code quaity and will be more heavily scrutinized. These PRs should clearly explain how this advances the medical system or advances the destruction/reconstruction of BodySystem in their description. Disco-Med and debodying PRs should not be making code compromises. If a PR must make code compromises, then its description must explain both what those compromises are and what is needed to remove such compromises, as well as labeling these compromises in code with TODOs. 18 | 19 | PRs which have to be split into multiple parts may require a design document, this is particularly true if any of the following criteria are met: 20 | - PR is not covered by a previous design document 21 | - PR was not pre-approved by a medical workgroup member 22 | - PR strays from the Medical Design Document or Medical Workgroup Document 23 | - PR is of such large scope that it may need to be divided amongst multiple contributors 24 | - PR requires multiple other systems to be refactored first 25 | 26 | For more questions on Debodying and Disco-Med please see: [Medical Workgroup Document](medical-workgroup.md) 27 | 28 | ### PRs for Offmed 29 | PRs for offmed shouldn't be merged into master as offmed is a testing branch. These should instead be merged directly into the offmed branch themselves. Since offmed is a feature testing branch and completely under the control of the medical workgroup, any PR intended for offmed may be closed for any reason. 30 | -------------------------------------------------------------------------------- /src/en/wizden-staff/staff-policy.md: -------------------------------------------------------------------------------- 1 | # Staff Policy 2 | This document aims to create a safe and healthy environment while fostering positive interactions among members of the RobustToolbox and Space Station 14 Projects. 3 | ## Code of Conduct 4 | #### This policy applies to all project members, regardless of rank, and is effective only within the scope of the project. 5 | - Respect: Members are expected to interact respectfully with others. 6 | - Zero Tolerance: There is zero tolerance for harassment, discrimination, or victimization. While disagreements are normal, personal attacks and insults are unacceptable. 7 | - Illegal Activity: Engagement in illegal activities, including hacking, theft, or copyright infringement, is strictly prohibited and may lead to immediate disciplinary action. 8 | ## Conflict Policy 9 | ### Definitions: 10 | - Disagreements: Normal and healthy, indicating collaboration and communication; no intervention needed. 11 | - Conflicts: Occur when disagreements escalate into personal attacks or resentment, disrupting collaboration. 12 | - Escalation: If a disagreement escalates into a conflict that makes any member uncomfortable, those involved or witnessing should contact the Moderation Team or HR to initiate the conflict management procedure. 13 | ### Conflict Management Procedure 14 | - Reporting: Members can report conflicts to HR or the Moderation Team. 15 | - Investigation: HR will conduct a confidential investigation, interviewing involved parties as needed. 16 | - Resolution Meeting: A meeting will be arranged to discuss issues and seek resolution. 17 | - Follow-Up: A follow-up will ensure the resolution is upheld and address any ongoing concerns. 18 | ## Staff Conflict Resolution Policy 19 | For conflicts specifically involving staff members (Maintainers, Art Directors, Project Managers, or Wizards), refer to the detailed Staff Conflict Resolution Policy. This document outlines the specific procedures for addressing staff conflicts, including immediate reporting, mediation, resolution options, and documentation. 20 | ## Policy Violations 21 | Members found in breach—such as through harassment, discrimination, or personal attacks—will face disciplinary actions ranging from warnings to removal from the project. All reports will be taken seriously and investigated promptly, ensuring fairness and confidentiality. Our goal is to maintain a positive environment where all members feel safe and valued. 22 | ## Encouragement of Reporting 23 | We encourage all team members to promptly report any policy violations. It is essential to foster a culture of accountability where everyone feels safe to speak up. Reports can be made confidentially, and individuals who come forward will be protected against retaliation. 24 | ## Feedback Mechanism 25 | Members are encouraged to provide feedback on this policy to ensure it meets the project's needs. Suggestions for improvement can be submitted anonymously via forums or direct messages to HR members. The HR team will review regular feedback for necessary adjustments. 26 | ## Review Schedule 27 | This HR policy will be reviewed annually or sooner if significant issues arise. The HR team will assess its effectiveness and relevance, making updates as needed to reflect changes in team dynamics or project goals. All members will be notified of any revisions. 28 | -------------------------------------------------------------------------------- /src/en/space-station-14/round-flow/antagonists/exterminator.md: -------------------------------------------------------------------------------- 1 | # Exterminator 2 | ```admonish warning "Attention: Legacy Documentation!" 3 | This document is ported from before the game-area reorganization and has not been reviewed or updated. 4 | It may not fit with the new design requirements. 5 | ``` 6 | ```admonish warning "Possible Removal" 7 | This content is being considered for removal, and may no longer be in-game in the future. 8 | ``` 9 | | Designers | Implemented | GitHub Links | 10 | |---|---|---| 11 | | deltanedas | :white_check_mark: Yes | https://github.com/space-wizards/space-station-14/pull/19946 | 12 | 13 | ## Abstract 14 | 15 | Basically an offbrand version of the Terminator with everything fairly faithful to the original film. Spawns in naked with no gear and has to find equipment to kill their target, which is the main objective. They can be tasked with killing anyone on the station. 16 | 17 | ## Goals 18 | 19 | A midround antag focused on killing a single person then dying, with minimal crossfire. The exterminator comes in does the job and disposes of themselves. Security will have something to do once reported, but it won’t be a round ender. Security are expected to maybe try kill it with guns before realising they aren’t effective then switch to lasers or asking chemistry for bombs. 20 | 21 | 22 | ## Gameplay 23 | 24 | While the exterminator has no telecrystals or gear like syndies or ninjas, what they do have is the following: 25 | 26 | - Extreme strength, since its a cyborg from the future strong punches and takes little damage from conventional weapons. Their main weakness is that fire and explosions do huge damage so find an oil tanker or make a flamethrower. 27 | - After taking 200 of any damage or 100 burn damage, they are gibbed and become an endoskeleton. The endoskeleton has no hands and is slow but is immune to burns, stabbing and shooting as it is pure titanium. You have to gib it with blunt weapons to finish it off, like a hydraulic press. 28 | 29 | Since the exterminator’s target can be any human player, killing the chef will be easier than the captain. You’ll have to improvise with how you pull things off. 30 | 31 | As it only spawns without intervention through a midround event, it can never spawn or have multiple exterminators per round. 32 | 33 | The exterminator is not required to collaborate with anyone but can at the player’s leisure. For example, if it spawns when nukies are attacking the station it would be wise to help them since nuking all but guarantees the target’s death. 34 | 35 | As an antagonist you can kill whoever tries to stop you from killing your target, but you should not go out of your way to murderbone as per the game rules. 36 | 37 | ## Components 38 | ### Endoskeleton 39 | 40 | The biggest thing with the exterminator, replaces gibbing being a completely bad thing. The exterminator has one organ, the brain, which is what gets control after being gibbed. While you are less flexible as a player you do more damage, letting you pull of a desperate last attempt to kill the target. Once the endoskeleton is gibbed from blunt weaponry, it leaves behind a very valuable nt-800 skull, which looks cool and can be kept by the target or sold for big bucks. 41 | 42 | As the endoskeleton can’t hold guns and is slow, it is an easy target for tiders to finish off with bats and crowbars. 43 | 44 | 45 | ## Inspirations 46 | 47 | Obviously The Terminator (1984) it’s a classic. 48 | -------------------------------------------------------------------------------- /src/en/maintainer-meetings/maintainer-meeting-2023-05-06.md: -------------------------------------------------------------------------------- 1 | # Maintainer Meeting (6 May 2023) 2 | ```admonish info 3 | Any decisions taken in these notes may no longer be applicable. 4 | ``` 5 | 6 | **Time:** 6 May 2023 19:00 UTC 7 | 8 | **Attendees:** 9 | - DrSmugleaf 10 | - Visne 11 | - Flipp 12 | - KeronSHB 13 | - ShadowCommander 14 | - mirrorcult 15 | 16 | ## Dropping content support for disabling client-side prediction | ElectroSR 17 | - **Simply make the server aware of which clients have prediction disabled instead** 18 | - Might be annoying for the small amount of people that use it 19 | 20 | ## Jez talks about telemetry | Jezithyr 21 | 22 | ## Early Access Roadmap 23 | - gamemodes/antags 24 | - dynamic | mirror 25 | - lings? 26 | - needs DNA 27 | - blob | Remie 28 | - revolutionaries 29 | - we want a generic antag overlay system 30 | - loyalty implant 31 | - faction system 32 | - clock cult | keronshb 33 | - EL BODY SYSTEM | jez  34 | - some refactors were done by mirror, still some left 35 | - surgery died in the war of 1992 36 | - Mirror died in the war of 1993 37 | - limb damage..... 38 | - Salvage proc gen | moony [c#15120](https://github.com/space-wizards/space-station-14/pull/15120) 39 | - she did it go port it https://github.com/Citadel-Station-13/space-station-14/tree/master/Content.Server/_Citadel/Worldgen 40 | - body system but again 41 | - body system 42 | - __***ENGINE EDITOR***__ 43 | - could benefit from full state reload 44 | - movement refactor 45 | - Client side movement? 46 | - a smidgen 47 | - as a treat 48 | - acruid pls com bak 49 | - ghostrole/antag bans 50 | - State mandated Xonotic matches | PJB 51 | - Please I have severe withdrawal symptoms 52 | - Replaced by private SS14 playtests 53 | - Woman down 54 | - She added Miku to her server (real) now you can play as miku pls play with her 55 | - Implement Xonotic as a plugin to ss14 56 | - The game runs like shit how do people play this 57 | - still does | PJB 28/05/2022 58 | - people like shitty games 59 | - "how do people play this game" (high pitched scream) | PJB 28/05/2022 60 | - ex: SCREEEEEEEEE 61 | - Slightly better | PJB 11/06/2022 62 | - It's better but still not as good as I'd like it to be | PJB 25/06/2022 63 | - I haven't played the game since | PJB 16/07/2022 64 | - "Please read the last line of that subsection" | PJB 30/07/2022 65 | - "Please unread the last line of the previous subsection" | PJB 07/01/2023 66 | - "I spent the last two weeks coding Rain World" | PJB 21/01/2023 67 | - "I should've tried to run it from the AirBNB that I was staying over in my skiing trip but I didn't" | PJB 11/02/2023 68 | - "It still runs like shit" | PJB 05/03/2023 69 | - "Uh" | PJB 19/03/2023 70 | - "Smugleaf to answer the literal question posed, because its better than Byond I hope" | PJB 01/04/2023 71 | - "Well I have a sample size of 1 myself and I do believe people do not in fact play the game" | PJB 15/04/2023 72 | - A trailer for Steam 73 | - Also the screenshots for steam and the website 74 | 75 | Crashes / Critical bugs: (when are we moving these to GitHub) 76 | - admin player overlay broke 77 | => till next time 78 | like and subscribe 79 | smash that button 80 | did you know only 6% of contribs join this meeting? 81 | -------------------------------------------------------------------------------- /src/en/robust-toolbox/coordinate-systems.md: -------------------------------------------------------------------------------- 1 | # Coordinate Systems 2 | 3 | This document describes the measurement and coordinate systems inside the RobustToolbox engine. Any GamePacks should be using the same standards as RobustToolbox. 4 | 5 | ## 1 The World 6 | The world is the 2D space inside a Map. The 2D world exists on the X/Y plane, and the camera appears to be above the surface looking down at it from the sky. 7 | 8 | N/E/S/W cardinal directions can be used in the world, but be careful that you are not mixing them up with screen directions. "East" would be the +X axis, and "North" would be the +Y axis. Remember that the camera looking down at the world can rotate, so the "South" direction in the world is not always "Down" or "South" on the screen. 9 | 10 | ### 1.1 World Measurements 11 | All measurements and units are in the metric system. The sizes of objects and distances are measured in meters. For visual reference, 1 Grid tile is 1m². Space Station 13 sprites are designed where 1 tile is 32px², so this project will also use the 32 texels per meter for sprites. 12 | 13 | ### 1.2 World Coordinate System 14 | The game world is using 2D right-handed coordinates. This is all the Transform and Angle values you are working with in content. This is the math you learned in school, where the unit circle rotates counterclockwise as theta increases. The default camera is oriented so that it is looking down the -Z axis at the X/Y plane that all of the entities exist on. The local "Up" direction (forward face of the X/Y plane) of the world is +Z. All rotations rotate around the Z axis. 15 | 16 | You can press the `F3` key to enable debug overlays, which print out all of the coordinate info. 17 | 18 | ### 1.3 Entity Local Coordinates 19 | +Z should be local Up (away from gravity) so it can easily be ignored in 2D. The three basis vectors are +X (Forward), +Y (Left), +Z (Up). 20 | 21 | You can use the `showpos` debug command to display the local direction widget on entities. 22 | 23 | ### 1.4 View Matrix 24 | The default view matrix starts with no rotation, a scale of 0.5 (Zoom of 2), and centered on the client's attached entity. The View can be rotated around the Z axis, translated to a position in the world, and scaled to create a zoom effect. The view matrix is conceptually the inverse of the camera's world matrix (if the camera was an entity). 25 | 26 | Using this default view matrix with 0 rotation, the +X axis of the world is to the right, and the +Y axis is upwards on the screen. The +Z axis is coming out of the screen. 27 | 28 | If you want to manipulate the view matrix directly, you can open a VV window for your player, then on the client open the `EyeComponent`. 29 | 30 | ### 1.5 Projection Matrix 31 | This is a basic orthographic projection like any other top down 2D game. Distance from the camera on the Z axis does not change the size of entities, all parallel lines stay parallel, and the field of view is a rectangular prism. 32 | 33 | ## 2 The Screen 34 | The screen is the square box that the game is projected onto when rendered. This is what you look at, it's like a *window* that you can look at the World through. Some game effects and the UI are directly drawn onto the screen. 35 | 36 | ### 2.1 UI Coordinate System 37 | The UI uses 2D left-handed coordinates, with the origin at the top left, +X going to the right, and +Y going down. Rotations go clockwise. This is exactly like any other UI library. 38 | 39 | ### 2.2 Clyde and OpenGL Coordinates 40 | You do not need to worry about how Clyde works internally, or how Clyde works with OpenGL. -------------------------------------------------------------------------------- /src/en/robust-toolbox/transform/grids.md: -------------------------------------------------------------------------------- 1 | # Grids 2 | 3 | RobustToolbox has support for tilemaps in engine, called grids (ss14 players may also call them shuttles or stations). 4 | 5 | Internally these are stored via chunks so that whenever a tile updates it only updates that specific chunk rather than the entire grid. These are stored by the chunk's origin, the bottom-left corner, in a hashmap. This means that whenever the grid expands we don't need to copy a giant array over and only need to worry about creating or deleting a new chunk as necessary. 6 | 7 | ## Grid Collision 8 | Grids use the same physics code (box2d) as everything else. You should [read up on how box2d works](https://box2d.org/documentation/) first. 9 | 10 | We generate fixtures for each chunk and attach them to the grid's body. Whenever a tile updates we regenerate all of the fixtures for that chunk; we also prefer to generate fixtures as large as possible to reduce their overall count. For instance, if a 16x16 chunk had all of its tiles filled then it would have 1 fixture that's 16x16. In SS14 this looks as follows: 11 | 12 |  13 | *Red lines represent the bounds of the fixtures. An SS14 map may be comprised of hundreds of fixtures. 14 | *In the bottom-left you can see the seam between the neighbouring chunks. Fixtures are only generated on a per-chunk basis so won't be any larger. 15 | 16 | 17 | ## Grid Splitting 18 | Whenever tiles are detached from the rest of a grid we detect if we should split this off into a new grid. 19 | 20 | To do this, we are required to pathfind whenever the grid's fixtures update and determine whether any pieces are now detached. Instead of doing this per tile which would be prohibitively expensive we instead turn groups of tiles on the same chunk into "nodes" and pathfind over that instead. The entire process is as follows: 21 | 1. Whenever the chunk needs to regenerate fixtures we also regenerate its nodes. We do this by floodfilling every tile into the chunk and returning each individual node. 22 | 2. For each node we determine its neighbours. These can't be on the same chunk because if they were then they would've been part of the original floodfill so we only check tiles on the neighboring chunks for their nodes. 23 | 3. At this point we have constructed the graph of the grid. In the above steps we marked which nodes were dirty i.e. the new ones created and all of the neighbours. From here we start floodfilling the dirty nodes to determine if they all have connections to each other. If all of the dirty nodes still connect then there is no split possible, but if there are still nodes left over after floodfilling then we will continuously iterate until we have all individual groups of nodes. 24 | 4. From the above we take each group of nodes and turn these into new grids. To do this we: 25 | - Create the new grid and apply the position + physics data of the old grid (e.g. its velocity) 26 | - Set all of the tiles on the new grid 27 | - For each tile, check for any anchored entities and re-anchor them on the new grid. Because the new grid has the same position and rotation as the old parent we only need to worry about updating the parent. 28 | - For each tile, check for any non-anchored entities and re-parent them to the new grid. 29 | - Set all of the files on the old grid to empty. 30 | 31 | ## Debugging 32 | 33 | ### Commands 34 | 35 | `showchunkbb` 36 | Toggles showing all of the grid fixtures in the viewport. 37 | 38 | `showgridnodes` 39 | Toggles visibility of the grid nodes used to check splitting. Also includes connections between the nodes. --------------------------------------------------------------------------------